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