From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:51632)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1QgeIF-0001RI-AB
	for qemu-devel@nongnu.org; Tue, 12 Jul 2011 10:50:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1QgeID-00008j-B0
	for qemu-devel@nongnu.org; Tue, 12 Jul 2011 10:50:35 -0400
Received: from mx1.redhat.com ([209.132.183.28]:59801)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1QgeIC-000084-Me
	for qemu-devel@nongnu.org; Tue, 12 Jul 2011 10:50:33 -0400
Message-ID: <4E1C5F30.2010502@redhat.com>
Date: Tue, 12 Jul 2011 16:50:24 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
References: <4E148776.4000805@redhat.com> <4E1497C6.4060505@codemonkey.ws>
	<4E155DEA.5020703@redhat.com> <4E15D280.8030508@codemonkey.ws>
In-Reply-To: <4E15D280.8030508@codemonkey.ws>
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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: jes sorensen <jes.sorensen@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Markus Armbruster <armbru@redhat.com>, Juan Quintela <quintela@redhat.com>

   Hi,

>> 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.

Isn't that a bit overkill?

> But we shouldn't enable things that may sometimes work by default.

I certainly agree on that for the future, thats why there is the patch 
series which starts tagging devices without migration support.

This is about bug compatibility with old qemu versions though.  They 
used to migrate usb devices without saving any state, with surprisingly 
few issues.

cheers,
   Gerd