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

Dan Berrange wrote: 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. The port would only be there to override the default, which would indeed be supplied by the driver / hypervisor. I didn't really understand this. Isn't live vs. offline mutually exclusive? Dan Smith wrote: 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). I would add a transport parameter, see below. I said and Anthony Liguori replied: 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