[Libvir] [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)

[Richard W.M. Jones]

Dan Berrange wrote:
> I don't see the point in this. Libvirt already knows both hostnames
> of the source & destination.

It's really very hard for libvirt to accurately determine the hostname 
of the destination as seen from the source.  Consider the case where you 
have a multi-homed host with a generic hostname (eg. 
"localhost.localdomain" which for some reason is the default on all my 
F7 installs).  If you have a specific suggestion for how to solve this, 
I'd like to hear it.

> libvirt should either know this, or be able to ask the underlying HV
> what port to use. I don't think we need to, or should put that burden 
> on the app using the API.

The port would only be there to override the default, which would indeed 
be supplied by the driver / hypervisor.

> Probably need one of the 'flags' to indicate whether to do live vs offline
> migration.

I didn't really understand this.  Isn't live vs. offline mutually exclusive?

Dan Smith wrote:
> In that case, haven't we already failed with virDomainCreate() since
> it takes hypervisor-specific XML?  Doesn't the presence of
> VIR_DEVICE_RW_FORCE imply knowledge of Xen-specific behavior?

The virConnectGetCapabilities call is supposed to allow you to generate 
the XML in a hypervisor-independent way.  (It doesn't quite supply 
enough information yet, but that is the aim).

> How would you handle someone wanting to use tcp:// or ssh:// with
> qemu?

I would add a transport parameter, see below.

I said and Anthony Liguori replied:
>>  * renaming domains during migration
> 
> Absolutely not!  The issue only exists if you allow the guests to exist on both systems during the migration.  In KVM, this shouldn't be the case.  The domain on the target should only ever be visible after the domain has successfully completed. 

I may be missing something here, but the domain name isn't really 
unique.  So it would be possible to have two different domains called 
(say) "database" running on two hosts.  The two domains are different 
databases with different purposes.  Now for some reason the 
administrator wants to migrate one "database" on to the other host, 
perhaps to get better load balancing or to take a host out of service. 
But this is impossible simply because of the name clash.

			- * * *	- * * *	-

Updated proposal:

/**
  * virDomainMigrate:
  * @domain: a domain object
  * @dconn: destination host (a connection object)
  * @flags: flags
  * @dname: (optional) rename domain to this at destination
  * @hostname: (optional) dest hostname as seen from the source host
  * @port: (optional) override default port number
  * @transport: (optional) specify a transport
  * @resource: (optional) specify resource limit in Mbps
  *
  * Migrate the domain object from its current host to the destination
  * host given by dconn (a connection to the destination host).
  *
  * Flags may be one of more of the following:
  *   VIR_MIGRATE_LIVE   Attempt a live migration.
  *
  * If a hypervisor supports renaming domains during migration,
  * then you may set the dname parameter to the new name (otherwise
  * it keeps the same name).  If this is not supported by the
  * hypervisor, dname must be NULL or else you will get an error.
  *
  * Since typically the two hypervisors connect directly to each
  * other in order to perform the migration, you may need to specify
  * a hostname, which is the hostname or IP address of the destination
  * host as seen from the source host.  If in doubt, leave this as
  * NULL and libvirt will attempt to work out the correct hostname.
  *
  * Specify a port number to override the default migration port.
  * If set to 0, libvirt will try to choose the right port.
  *
  * Specify a transport to override the default transport (for
  * example: "ssh").  If set to NULL, libvirt will try to choose the
  * best transport.  If non-NULL but the transport is not supported
  * by the hypervisor, then you will get an error.
  *
  * The maximum bandwidth (in Mbps) that will be used to do migration
  * can be specified with the resource parameter.  If set to 0,
  * libvirt will choose a suitable default.  Some hypervisors do
  * not support this feature and will return an error if resource
  * is not 0.
  *
  * Returns the new domain object if the migration was successful,
  *   or NULL in case of error.
  */

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070716/8404028b/attachment-0001.bin>