From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ND0UY-0005UF-Rv for qemu-devel@nongnu.org; Tue, 24 Nov 2009 13:51:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ND0UT-0005TJ-4m for qemu-devel@nongnu.org; Tue, 24 Nov 2009 13:51:57 -0500 Received: from [199.232.76.173] (port=56024 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ND0US-0005TF-VK for qemu-devel@nongnu.org; Tue, 24 Nov 2009 13:51:52 -0500 Received: from ey-out-1920.google.com ([74.125.78.145]:50833) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ND0US-00034P-JA for qemu-devel@nongnu.org; Tue, 24 Nov 2009 13:51:52 -0500 Received: by ey-out-1920.google.com with SMTP id 26so1593822eyw.2 for ; Tue, 24 Nov 2009 10:51:50 -0800 (PST) Message-ID: <4B0C2B40.4040803@codemonkey.ws> Date: Tue, 24 Nov 2009 12:51:44 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts References: <4B0952C9.9010803@redhat.com> <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> In-Reply-To: <4B0C1B46.90504@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Blue Swirl , qemu-devel@nongnu.org, Paul Brook , "Michael S. Tsirkin" Paolo Bonzini wrote: > On 11/24/2009 06:08 PM, Michael S. Tsirkin wrote: >>> > The external version translator tool could support arbitrary >>> > conversion between the whole NxN matrix of versions (including >>> distro >>> > hacks), or just those that RHEL happens to use. The tool would >>> not be >>> > limited to QEMU development environment, it could use databases, >>> XSLT, >>> > SOA or be written in C#. >> Yea, maybe cross-hypervisor migration could be made to work:) >> All that would be possible if the migration protocol would >> be specified at some level. As it is, the protocol >> really dumps out internal infromation about current >> qemu implementation, and it seems that making >> it a separate project would just slow us down. > > We have Juan's VMState work to start from. If we can take it a step > further and use anything (including CPP) to make the primary > representation of state an XML document 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. Sorry, I couldn't help myself :-) Regards, Anthony Liguori