From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCwPw-0001TH-LW for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:30:56 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCwPr-0001Rw-6o for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:30:55 -0500 Received: from [199.232.76.173] (port=42731 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCwPq-0001Rt-P0 for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:30:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59979) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCwPq-0004eD-BM for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:30:50 -0500 Date: Tue, 24 Nov 2009 16:28:11 +0200 From: "Michael S. Tsirkin" Message-ID: <20091124142811.GP2405@redhat.com> References: <4B0952C9.9010803@redhat.com> <4B095D86.700@codemonkey.ws> <4B09F0CA.3060705@codemonkey.ws> <1258983457-sup-5031@blackpad.lan.raisama.net> <4B0AA202.2050001@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B0AA202.2050001@codemonkey.ws> Subject: [Qemu-devel] Re: Re: Live migration protocol, device features, ABIs and other beasts List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paolo Bonzini , Eduardo Habkost , qemu-devel On Mon, Nov 23, 2009 at 08:53:54AM -0600, Anthony Liguori wrote: > Eduardo Habkost wrote: >>>>> Migration needs to be conservative. There should be only two possible >>>>> outcomes: 1) a successful live migration or 2) graceful failure with the >>>>> source VM still running correctly. Silently ignoring things that could >>>>> affect the guests behavior means that it's possible that after failure, >>>>> the guest will fail in an unexpected way. >>>>> >>>> It's up to the source to decide what information is extra. For >>>> example, the state of a RNG emulation is nice-to-have, but as long >>>> as it is initialized from another random source on the destination >>>> you shouldn't care. >>>> >>> We only migrate things that are guest visible. Everything else is >>> left to the user to configure. We wouldn't migrate the state of a >>> RNG emulation provided that it doesn't have an impact on the guest. >>> >>> By definition, anything that is guest visible is important because it >>> affects the guest's behavior. >>> >> >> Right, but I wouldn't be surprised if a user complains that "I know that >> my guest don't use that VM feature, so I want to be able to migrate to >> an older version anyway". >> > > This could be addressed with a "force" migration feature. That said, I > don't believe that the overwhelming majority of users are in a position > to determine whether they can safely migrate to an older version. > > Regards, > > Anthony Liguori It's very easy: if their guest runs fine on the old qemu, it should be safe to migrate there. -- MST