* Paolo Bonzini (pbonz...@redhat.com) wrote: > Il 15/10/2014 17:59, Juan Quintela ha scritto: > > My idea here is that, if you don't use libvirt, you just start without > > -S. > > If you don't use libvirt or any other QEMU management layer, you're not > going to do migration except for debugging purposes. There's just too > much state going on to be able to do it reliably.
I'm not sure that's entirely true - while I agree that most users will use libvirt, migration with shared disk is pretty easy; the only thing that you need to do is bring up the tap on the destination, and I'm not sure libvirt gets the timing ideal for it. Dave > > > If you use libvirt, and you *don't* need to do anything special to run > > after migration, you shouldn't use -S. > > Is this a real requirement, or just "it sounds nicer that way"? How > much time really passes between the end of migration and the issuing of > the "-cont" command? > > And the $1,000,000 questionL.aAre you _absolutely_ sure that an > automatic restart is entirely robust against a failure of the connection > between the two libvirtd instances? Could you end up with the VM > running on two hosts? Using -S gets QEMU completely out of the > equation, which is nice. > > By the way, some of the states (I can think of io-error, guest-panicked, > watchdog) can be detected on the destination and restored. Migrating a > machine with io-error state is definitely something that you want to do > no matter what versions of QEMU you have. It may be the only way to > recover for a network partition like this: > > DISK > / \ > | \ > X | > | | > SRC --- DEST > > (not impossible: e.g. the SRC->DISK is fibre channel, but the SRC->DEST > link is Ethernet. Or you have a replicated disk setup, some daemon > fails in SRC's replica but not DEST's). > > > And I would emit an event saying > > "migration was finished". > > The event should be emitted nevertheless. :) > > Paolo > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
