Re: [Libvir] [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)
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 -=|