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