[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