On Mon, Jul 16, 2007 at 01:47:38PM +0100, Richard W.M. Jones wrote: > To cut to the chase, this is the proposed additional libvirt call to > support migration. Please also read my explanation below. > > /** > * virDomainMigrate: > * @domain: a domain object > * @dconn: destination host (a connection object) > * @flags: flags > * @dname: (optional) rename domain to this at destination > * @hostname: (optional) remote hostname as seen from the source host > * @params: linked list of hypervisor-specific parameters > * > * 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. I don't see the point in this. Libvirt already knows both hostnames of the source & destination. > * Params is a linked list of hypervisor-specific parameters. Each > * element is a virMigrateParamPtr containing the following fields: > * name Parameter name being set. > * value A union expressing the value. > * value.strv A string value. > * value.longv A long value. > * next Next in linked list (or NULL for end of list). > * > * Parameter names for Xen are: > * VIR_MIGRATE_XEN_PORT (long) Override the default port number. 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. > * VIR_MIGRATE_XEN_RESOURCE (long) Set maximum resource usage (Mbps). This doesn't have to be Xen specific - any app implementing migration can have ability to throttle bandwidth. > What I think will be common features are: > * live migration Probably need one of the 'flags' to indicate whether to do live vs offline migration. > * direct host<->host connections > * renaming domains during migration Should we return a new 'virDomainPtr' object for the newly migrated domain, associated with the destination virConnectPtr object ? > The explicit parameters include a general "flags" parameter, which we > can extend with other boolean flags later. For host<->host connections > you'll want some way to specify the hostname / IP address of the > destination host as seen at the source. In the remote management case > it's not always so easy to work this out. We can try using > virConnectGetHostname, but we also allow the caller to override. I really don't like the idea of a hostname - if libvirt is unable to work it out under some circumstances, how does the app know what those circumstances are ? ie, how does it know whether it needs to specify the hostname or not ? I'd rather do without this & make it 'just work', even if we need more hardwork in the underlying driver impls. > On the other hand, there will be some hypervisor-specific features, and > these are enabled through a linked list of parameters. For Xen these > include setting port and resource usage. I guess other hypervisors will > have their own parameters -- eg. security settings. I don't like exposing hypervisor specific requirements here - rather defeats the purpose of having a hypervisor agnositic API. Dan -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list