From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4xnj-0005Wg-09 for qemu-devel@nongnu.org; Tue, 06 Mar 2012 12:04:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4xnY-00069x-Px for qemu-devel@nongnu.org; Tue, 06 Mar 2012 12:03:50 -0500 Received: from mail-pz0-f46.google.com ([209.85.210.46]:50281) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4xnY-00069Y-JF for qemu-devel@nongnu.org; Tue, 06 Mar 2012 12:03:40 -0500 Received: by dajr28 with SMTP id r28so8225257daj.33 for ; Tue, 06 Mar 2012 09:03:38 -0800 (PST) Message-ID: <4F564365.2000009@codemonkey.ws> Date: Tue, 06 Mar 2012 11:03:33 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1331036527-7651-1-git-send-email-pbonzini@redhat.com> <1331036527-7651-4-git-send-email-pbonzini@redhat.com> In-Reply-To: <1331036527-7651-4-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] virtio-blk: note optional features List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: mst@redhat.com, uobergfe@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, owasserm@redhat.com, amit.shah@redhat.com On 03/06/2012 06:22 AM, Paolo Bonzini wrote: > The guest must already be prepared to see SG_IO support > disappear from under its feet, for example if migration > refers to a block device on the source and file-based > storage on the destination; or more likely, if the source > kernel allows (gasp) SG_IO on a partition and the destination > does not. So, we can migrate safely even if the source > had VIRTIO_BLK_F_SCSI and the destination does not. I don't know how comfortable I feel about this. You can't just remove a feature in flight. The guest is going to behave differently in such a way that the host isn't expecting. Yes, it should fail gracefully, but nonetheless it will fail. Aren't you just delaying the inevitable? Instead of having migration fail, the guest workload is going to fail. How is this an improvement? Regards, Anthony Liguorig > > Signed-off-by: Paolo Bonzini > --- > hw/virtio-blk.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c > index c95f8fc..9a4158a 100644 > --- a/hw/virtio-blk.c > +++ b/hw/virtio-blk.c > @@ -542,7 +542,7 @@ static int virtio_blk_load(QEMUFile *f, void *opaque, int version_id) > if (version_id != 2) > return -EINVAL; > > - ret = virtio_load(&s->vdev, f, 0); > + ret = virtio_load(&s->vdev, f, VIRTIO_BLK_F_SCSI); > if (ret) { > return ret; > }