From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NE1j4-00044S-1I
	for qemu-devel@nongnu.org; Fri, 27 Nov 2009 09:23:10 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NE1iz-0003xZ-9R
	for qemu-devel@nongnu.org; Fri, 27 Nov 2009 09:23:09 -0500
Received: from [199.232.76.173] (port=42086 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NE1iz-0003xK-3Y
	for qemu-devel@nongnu.org; Fri, 27 Nov 2009 09:23:05 -0500
Received: from mx1.redhat.com ([209.132.183.28]:54327)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1NE1iy-0001Rt-Pt
	for qemu-devel@nongnu.org; Fri, 27 Nov 2009 09:23:05 -0500
Received: from int-mx08.intmail.prod.int.phx2.redhat.com
	(int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAREN30f016593
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Fri, 27 Nov 2009 09:23:03 -0500
Message-ID: <4B0FE0C4.5080007@redhat.com>
Date: Fri, 27 Nov 2009 15:23:00 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Migration issues and possible solutions (Very long)
References: <m3k4xc5fp3.fsf@neno.neno>
In-Reply-To: <m3k4xc5fp3.fsf@neno.neno>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Juan Quintela <quintela@redhat.com>
Cc: qemu-devel@nongnu.org

   Hi,

> - Dor/mst proposal of optional features
>
>    This came from previous discussions, Dor want to put optional fields
>    in the savevm protocol that target can just discard.

Taking that one to the next level:  Simply save all fields with name and 
size.  qemu can skip and ignore unknown fields load time.  No version 
numbers are needed any more (except for loading old images), and all the 
issues with non-linear version numbering of devices are suddenly gone.

The big drawback: it only helps for 0.12+ because that pretty much 
depends on having vmstate on both sending and receiving side.

If qemu-0.12 should be able to save qemu-0.11 too, we could go for 
something simple, like a static list of device+savevm versions, without 
creating a maintainance nightmare because it has to handle only the 
single migrate-to-0.11 special case.

cheers,
   Gerd