From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeqZt-0003wI-W1 for qemu-devel@nongnu.org; Thu, 07 Jul 2011 11:33:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QeqZs-0000jK-45 for qemu-devel@nongnu.org; Thu, 07 Jul 2011 11:33:21 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:41829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeqZr-0000j0-So for qemu-devel@nongnu.org; Thu, 07 Jul 2011 11:33:20 -0400 Received: by yia25 with SMTP id 25so512381yia.4 for ; Thu, 07 Jul 2011 08:33:19 -0700 (PDT) Message-ID: <4E15D1BC.3010306@codemonkey.ws> Date: Thu, 07 Jul 2011 10:33:16 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E148776.4000805@redhat.com> <4E149B3F.2010709@redhat.com> <4E14BF36.3080803@codemonkey.ws> <6E6E2CFC-B5BB-4E1D-945D-1F13C604330B@suse.de> In-Reply-To: <6E6E2CFC-B5BB-4E1D-945D-1F13C604330B@suse.de> 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: Alexander Graf Cc: Juan Quintela , jes sorensen , "qemu-devel@nongnu.org" , Markus Armbruster , Avi Kivity , Gerd Hoffmann On 07/06/2011 06:32 PM, Alexander Graf wrote: > > On 06.07.2011, at 22:01, Anthony Liguori wrote: > >> 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. > > Can't we just implicitly fail migration whenever there's a device in the tree that doesn't have VMSTATE? Not all devices currently implement VMSTATE. Regards, Anthony Liguori > > > Alex > >