From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ND1cp-0001Sn-0x for qemu-devel@nongnu.org; Tue, 24 Nov 2009 15:04:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ND1ck-0001LX-3S for qemu-devel@nongnu.org; Tue, 24 Nov 2009 15:04:34 -0500 Received: from [199.232.76.173] (port=36260 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ND1cj-0001LO-Tc for qemu-devel@nongnu.org; Tue, 24 Nov 2009 15:04:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:63167) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ND1ci-0001NH-Qd for qemu-devel@nongnu.org; Tue, 24 Nov 2009 15:04:29 -0500 Date: Tue, 24 Nov 2009 22:01:41 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts Message-ID: <20091124200141.GB4290@redhat.com> References: <200911241335.35334.paul@codesourcery.com> <20091124134910.GH2405@redhat.com> <200911241359.49321.paul@codesourcery.com> <20091124142152.GN2405@redhat.com> <20091124170809.GC3397@redhat.com> <4B0C1B46.90504@redhat.com> <4B0C2B40.4040803@codemonkey.ws> <4B0C2CA9.7060407@redhat.com> <4B0C3405.7030207@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B0C3405.7030207@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , Paolo Bonzini , Paul Brook , qemu-devel@nongnu.org On Tue, Nov 24, 2009 at 01:29:09PM -0600, Anthony Liguori wrote: > Paolo Bonzini wrote: >> On 11/24/2009 07:51 PM, Anthony Liguori wrote: >>>> to make the primary representation of state an XML document >> >> Since my brain is not working well today, I'll just point out that of >> course I meant "the primary representation of _schemas_ an XML >> document" or anything like that. >> >>>> or anything like that (and convert it back to VMState structs at build >>>> time), it would not be a huge work, and it would give important >>>> benefits. >>> >>> Like adding tremendous complexity for little to no gain. >> >> Anything that could result in a libqemustate or something like that >> would be complex, but would have gain. (Yes, I've seen the smiley >> despite aforementioned problems with the brain). > > Which would be...? > > "Increased flexibility" is not a quantifiable gain. If there's a > particular feature we need to support, let's try to support the feature. > > There are bigger fish to fry with live migration than the protocol > format. For instance, we need to do a fair bit of work to build an > infrastructure that will let us test this stuff in a sane way so we can > avoid introducing things like the pvclock regression. BTW, I think that the ability to save in old format will help in this respect: it makes it possible to do some unit testing without having old qemu lying around. -- MST