On Thu, Nov 10, 2011 at 12:27:30PM -0600, Anthony Liguori wrote:
> What does libvirt actually do in the monitor prior to migration
> completing on the destination? The least invasive way of doing
> delayed open of block devices is probably to make -incoming create a
> monitor and run a main loop before the block devices (and full
> device model) is initialized. Since this isolates the changes
> strictly to migration, I'd feel okay doing this for 1.0 (although it
> might need to be in the stable branch).
The way migration works with libvirt wrt QEMU interactions is now
as follows
1. Destination.
Run qemu -incoming ...args...
Query chardevs via monitor
Query vCPU threads via monitor
Set disk / vnc passwords
Set netdev link states
Set balloon target
2. Source
Set migration speed
Set migration max downtime
Run migrate command (detached)
while 1
Query migration status
if status is failed or success
break;
3. Destination
If final status was success
Run 'cont' in monitor
else
kill QEMU process
4. Source
If final status was success and 'cont' on dest succeeded
kill QEMU process
else
Run 'cont' in monitor
In older libvirt, the bits from step 4, would actually take place
at the end of step 2. This meant we could end up with no QEMU
on either the source or dest, if starting CPUs on the dest QEMU
failed for some reason.
We would still really like to have a 'query-migrate' command for
the destination, so that we can confirm that the destination has
consumed all incoming migrate data successfully, rather than just
blindly starting CPUs and hoping for the best.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
