From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xf7mW-0003RQ-L1 for qemu-devel@nongnu.org; Fri, 17 Oct 2014 09:41:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xf7mN-0000HM-KA for qemu-devel@nongnu.org; Fri, 17 Oct 2014 09:41:24 -0400 Received: from mail-qc0-x230.google.com ([2607:f8b0:400d:c01::230]:62145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xf7mN-0000HH-Fx for qemu-devel@nongnu.org; Fri, 17 Oct 2014 09:41:15 -0400 Received: by mail-qc0-f176.google.com with SMTP id r5so555349qcx.7 for ; Fri, 17 Oct 2014 06:41:14 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <54411C74.2010407@redhat.com> Date: Fri, 17 Oct 2014 15:41:08 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1413359710-2799-1-git-send-email-quintela@redhat.com> <543E8B45.3040809@redhat.com> <877g01fhob.fsf@elfo.elfo> In-Reply-To: <877g01fhob.fsf@elfo.elfo> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC 0/7] Optional toplevel sections List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: quintela@redhat.com, Eric Blake Cc: kwolf@redhat.com, qemu-devel@nongnu.org, laine@redhat.com, lcapitulino@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