qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections
Date: Mon, 20 Oct 2014 15:59:57 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

* Paolo Bonzini (address@hidden) 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 / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]