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 -=|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list