On 03/06/2012 11:12 AM, Paolo Bonzini wrote:
Il 06/03/2012 18:03, Anthony Liguori ha scritto:
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?
VIRTIO_BLK_F_SCSI feature was almost never used but was always marked as
available. Because of possible security problems connected to it,
libvirt started making it an opt-in feature.
In practice, you need to configure your host specially if you want to
use SCSI passthrough (e.g. you must not use labels and UUIDs in your
/etc/fstab), so it's safe to assume that guests that have SG_IO disabled
under their feet will keep working.
That said, instead of this hack we can just decouple scsi=on/off from
VIRTIO_BLK_F_SCSI, and just report the feature. After all we do not
clear VIRTIO_BLK_F_SCSI just because the device is backed by a file or
partition, yet SG_IO is still unavailable in those cases. I'll send
patches for this tomorrow.
Okay, that makes more sense to me. I think this is an exceptional circumstance
so handling it as a one-off verses a generic mechanism would be preferred.
Regards,
Anthony Liguori
Paolo
