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 HVwhat 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 migrationAbsolutely 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list