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

[Daniel P. Berrange]

On Mon, Jul 16, 2007 at 03:43:48PM +0100, Richard W.M. Jones wrote:
> Dan Smith wrote:
> >RJ>  * Params is a linked list of hypervisor-specific parameters.  Each
> >RJ>  * element is a virMigrateParamPtr containing the following fields:
> >RJ>  *   name               Parameter name being set.
> >RJ>  *   value              A union expressing the value.
> >RJ>  *     value.strv         A string value.
> >RJ>  *     value.longv        A long value.
> >RJ>  *   next               Next in linked list (or NULL for end of list).
> >
> >This should allow us to pass URIs to qemu, as well.  I like it :)
> 
> Can you give us some idea of how QEMU migration works?
> 
> KVM added a "migrate" function to the qemu console ("migrate <URI>"). 
> For example: "migrate tcp://hostname:4444" and "migrate ssh://hostname". 
>  I'm not sure if that is in qemu upstream, or whether qemu upstream is 
> doing something else.
> 
> I think that we shouldn't pass URIs, but instead we should construct the 
> URI from the hostname and port number, and something like an optional 
> "VIR_KVM_TRANSPORT" virMigrateParamPtr.
> 
> (This implies that port number, like hostname, becomes a main argument 
> to virDomainMigrate).
> 
> Incidentally, KVM also supports cancelling migrations (this interface 
> doesn't), getting the status of migrations (this interface assumes the 
> migration is synchronous and is supposed to only return when the 
> migration is done), and setting resource limits.  The latter implies 
> that resource limits should be a non-Xen-specific parameter.

This is an interesting point. This gets onto the more general question of
being able to provide incremental feedback / async notifications / querying
progress of ongoing ops. One could make use of the flags param by allowing
the app to specify 'VIR_MIGRATE_ASYNC'   so it returned immediately. Apps
would then either need to poll to find out when an operation had completed
or failed, or register a callback to be invoked upon completion / failure.
The latter would obviously entail adding making the event loop stuff public
instead of driver internal.

One can say the same of the existing save / restore methods too - it would
be desriable to be able to run those in backend, and/or cancel them. The
way virt-manager deals with now is to just spawn a thread to let us run them
in the BG without blocking the UI. This doesn't deal with cancellation though.

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