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

Daniel P. Berrange berrange at redhat.com
Mon Jul 16 14:55:06 UTC 2007


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  -=| 




More information about the libvir-list mailing list