Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections

[Paolo Bonzini <pbonzini@redhat.com>]

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.

> 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