From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeVtv-0002Lp-4Q for qemu-devel@nongnu.org; Wed, 06 Jul 2011 13:28:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QeVtt-0000TC-Iu for qemu-devel@nongnu.org; Wed, 06 Jul 2011 13:28:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42177) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeVtt-0000T4-4d for qemu-devel@nongnu.org; Wed, 06 Jul 2011 13:28:37 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p66HSZen019282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Jul 2011 13:28:35 -0400 Message-ID: <4E149B3F.2010709@redhat.com> Date: Wed, 06 Jul 2011 20:28:31 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E148776.4000805@redhat.com> In-Reply-To: <4E148776.4000805@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] migration: new sections and backward compatibility. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: jes sorensen , Juan Quintela , "qemu-devel@nongnu.org" , Markus Armbruster On 07/06/2011 07:04 PM, Gerd Hoffmann wrote: > Hi folks, > > We'll need to figure a sane way to handle migration to older versions > with new sections, i.e. devices which used to not save state before do > now. > > We already have one case in tree: usb. qemu 0.14 saves state for > usb-hid devices and the usb-hub, whereas qemu 0.13 and older don't. > You can't migrate a vm with a usb-tablet from 0.14 to 0.13 because of > that even if you use -M pc-0.13. > > More cases are lurking. AHCI doesn't support migration today but > probably will some day. Markus mentioned that scsi-disk will face > that issue too. And that list probably isn't complete. > > Subsections don't help here as there is no toplevel section in the > first place. > > Ideas anyone? Maybe allow test functions like we have for subsections > for toplevel sections too, so we have a way to skip the section > altogether on savevm? > > We probably also want a way to fail the migration in case the target > machine doesn't support migration for $device, especially for $device > == ahci to avoid data loss. For the usb-tablet it isn't that > problematic, in the best case the guest just resets the device and > goes on, in the worst case the mouse is dead. > How did AHCI get in without migration? It's relatively new, is it not? -- error compiling committee.c: too many arguments to function