[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [libvirt] feature suggestion: migration network
- From: Dan Kenigsberg <danken redhat com>
- To: Mark Wu <wudxw linux vnet ibm com>, libvir-list redhat com
- Cc: Yuval M <yuvalme gmail com>, Yaniv Kaul <ykaul redhat com>, Limor Gavish <lgavish gmail com>, Simon Grinberg <sgrinber redhat com>, arch ovirt org
- Subject: Re: [libvirt] feature suggestion: migration network
- Date: Thu, 10 Jan 2013 14:00:57 +0200
On Thu, Jan 10, 2013 at 10:45:42AM +0800, Mark Wu wrote:
> On 01/08/2013 10:46 PM, Yaniv Kaul wrote:
> >On 08/01/13 15:04, Dan Kenigsberg wrote:
> >>There's talk about this for ages, so it's time to have proper discussion
> >>and a feature page about it: let us have a "migration" network role, and
> >>use such networks to carry migration data
> >>When Engine requests to migrate a VM from one node to another, the VM
> >>state (Bios, IO devices, RAM) is transferred over a TCP/IP connection
> >>that is opened from the source qemu process to the destination qemu.
> >>Currently, destination qemu listens for the incoming connection on the
> >>management IP address of the destination host. This has serious
> >>downsides: a "migration storm" may choke the destination's management
> >>interface; migration is plaintext and ovirtmgmt includes Engine which
> >>sits may sit the node cluster.
> >>With this feature, a cluster administrator may grant the "migration"
> >>role to one of the cluster networks. Engine would use that network's IP
> >>address on the destination host when it requests a migration of a VM.
> >>With proper network setup, migration data would be separated to that
> >>=== Benefit to oVirt ===
> >>* Users would be able to define and dedicate a separate network for
> >> migration. Users that need quick migration would use nics with high
> >> bandwidth. Users who want to cap the bandwidth consumed by migration
> >> could define a migration network over nics with bandwidth limitation.
> >>* Migration data can be limited to a separate network, that has no
> >> layer-2 access from Engine
> >>=== Vdsm ===
> >>The "migrate" verb should be extended with an additional parameter,
> >>specifying the address that the remote qemu process should listen on. A
> >>new argument is to be added to the currently-defined migration
> >>* vmId: UUID
> >>* dst: management address of destination host
> >>* dstparams: hibernation volumes definition
> >>* mode: migration/hibernation
> >>* method: rotten legacy
> >>* ''New'': migration uri, according to
> >>such as tcp://<ip of migration network on remote node>
> >>=== Engine ===
> >>As usual, complexity lies here, and several changes are required:
> >>1. Network definition.
> >>1.1 A new network role - not unlike "display network" should be
> >> added.Only one migration network should be defined on a cluster.
> >>1.2 If none is defined, the legacy "use ovirtmgmt for migration"
> >> behavior would apply.
> >>1.3 A migration network is more likely to be a ''required'' network, but
> >> a user may opt for non-required. He may face unpleasant
> >>surprises if he
> >> wants to migrate his machine, but no candidate host has the network
> >> available.
> >>1.4 The "migration" role can be granted or taken on-the-fly, when hosts
> >> are active, as long as there are no currently-migrating VMs.
> >>2. Scheduler
> >>2.1 when deciding which host should be used for automatic
> >> migration, take into account the existence and availability of the
> >> migration network on the destination host.
> >>2.2 For manual migration, let user migrate a VM to a host with no
> >> migration network - if the admin wants to keep jamming the
> >> management network with migration traffic, let her.
> >>3. VdsBroker migration verb.
> >>3.1 For the a modern cluster level, with migration network defined on
> >> the destination host, an additional ''miguri'' parameter
> >>should be added
> >> to the "migrate" command
> >>Arch mailing list
> >>Arch ovirt org
> >How is the authentication of the peers handled? Do we need a cert
> >per each source/destination logical interface?
> In my understanding, using a separate migration network doesn't
> change the current peers authentication. We still use the URI
> ''qemu+tls://remoeHost/system' to connect the target libvirt service
> if ssl enabled, and the remote host should be the ip address of
> management interface. But we can choose other interfaces except the
> manage interface to transport the migration data. We just change the
> migrateURI, so the current authentication mechanism should still
> work for this new feature.
vdsm-vdsm and libvirt-libvirt communication is authenticated, but I am
not sure at all that qemu-qemu communication is.
After qemu is sprung up on the destination with
-incoming <some ip>:<some port> , anything with access to that
address could hijack the process. Our migrateURI starts with "tcp://"
with all the consequences of this. That a good reason to make sure
<some ip> has as limited access as possible.
But maybe I'm wrong here, and libvir-list can show me the light.
[Date Prev][Date Next] [Thread Prev][Thread Next]