From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeYIP-0002ot-0x for qemu-devel@nongnu.org; Wed, 06 Jul 2011 16:02:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QeYIM-0006qM-RJ for qemu-devel@nongnu.org; Wed, 06 Jul 2011 16:02:04 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:50284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeYIM-0006pl-7x for qemu-devel@nongnu.org; Wed, 06 Jul 2011 16:02:02 -0400 Received: by ywb3 with SMTP id 3so136212ywb.4 for ; Wed, 06 Jul 2011 13:02:00 -0700 (PDT) Message-ID: <4E14BF36.3080803@codemonkey.ws> Date: Wed, 06 Jul 2011 15:01:58 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E148776.4000805@redhat.com> <4E149B3F.2010709@redhat.com> In-Reply-To: <4E149B3F.2010709@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: Avi Kivity Cc: "qemu-devel@nongnu.org" , jes sorensen , Gerd Hoffmann , Markus Armbruster , Juan Quintela On 07/06/2011 12:28 PM, Avi Kivity wrote: > 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? We don't have a hard policy about not merging devices that don't support migration. Since migration must be supported forever, I'd rather see a device get some solid testing before it starts doing live migration. That said, we should probably do this consciously by explicitly marking the device non-migrateable. Regards, Anthony Liguori >