From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qeqd5-0004p8-GZ for qemu-devel@nongnu.org; Thu, 07 Jul 2011 11:36:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qeqd2-0001Pq-8j for qemu-devel@nongnu.org; Thu, 07 Jul 2011 11:36:39 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:47595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qeqd1-0001PV-SY for qemu-devel@nongnu.org; Thu, 07 Jul 2011 11:36:35 -0400 Received: by gyf2 with SMTP id 2so508432gyf.4 for ; Thu, 07 Jul 2011 08:36:35 -0700 (PDT) Message-ID: <4E15D280.8030508@codemonkey.ws> Date: Thu, 07 Jul 2011 10:36:32 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4E148776.4000805@redhat.com> <4E1497C6.4060505@codemonkey.ws> <4E155DEA.5020703@redhat.com> In-Reply-To: <4E155DEA.5020703@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 , "qemu-devel@nongnu.org" , Markus Armbruster , Juan Quintela On 07/07/2011 02:19 AM, Gerd Hoffmann wrote: > On 07/06/11 19:13, Anthony Liguori wrote: >> On 07/06/2011 11:04 AM, 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. >> >> Because if you did migrate, you would actively break the guest during >> migration. So why is this a problem? > > Well, in case of usb hid devices breaking the guest isn't that a big > issue for at least some guests because they manage to reset the device > and continue nevertheless ... In a situation like this, I think our responsibility is to let the user know that there could be a problem, and provide the ability to the user to force the migration. So for instance, you could have a "(qemu) migrate_ignore_section usb" command or something like that. But we shouldn't enable things that may sometimes work by default. Regards, Anthony Liguori > > I think this is a case-by-case thing. In some cases we want break > migration because critical state is missing. In other cases we might > want allow it nevertheless. > > cheers, > Gerd >