Re: [libvirt] [PATCH V3 2/3] virtio-blk: fail get_features when both scsi and 1.0 were set
On Wed, Jul 22, 2015 at 01:40:25PM +0200, Paolo Bonzini wrote:
On 22/07/2015 12:19, Michael S. Tsirkin wrote:
SCSI passthrough was no longer supported in virtio 1.0, so this patch fail the get_features() when both 1.0 and scsi is set. And also only advertise VIRTIO_BLK_F_SCSI for legacy virtio-blk device.
Why is SCSI passthrough support not available in virtio 1.0 ? This will cause a regression for any users of that as & when QEMU changes to use virtio 1.0 by default. Can we not fix this regression instead.
If we wanted to, we might be able to fix this but not for 2.4: we'd have to extend the spec and guest drivers, in some way TBD.
Paolo would be best placed to answer whether this feature is desirable in the future, I think the argument made when the spec was written was that the feature is not widely used, and virtio scsi is available as a replacement for people who need it.
No, the feature is not desirable in the future. There is no reason really not to use virtio-scsi passthrough instead, since virtio-scsi has been out for about 3 years now and is stable.
In addition, the implementation would either not be compatible with virtio 0.9, or would be different from everything else in the spec because it requires a particular framing for the buffers.
IIUC, the SCSI passthrough feature for virtio-blk is enabled by setting the 'scsi=on' property on the virtio-blk device, which is exposed by libvirt with XML: <disk type='block' device='lun'> <driver name='qemu' type='raw'/> <source dev='/dev/sda'/> <target dev='vda' bus='virtio'/> </disk> (For use with virtio-scsi you'd just change the <target> element) So if the guest is using virtio-1.0, then this will now fail to boot, or cause an error from monitor hotplug. This is not too bad, but I'm just wondering if there's anything else we ought to think about doing in libvirt in this situation. Normally we'd try to detect unsupported things upfront so we can report VIR_ERR_CONFIG_UNSUPPORTED, instead of the generic error code VIR_ERR_INTERNAL_ERROR, but perhaps this is sufficiently niche to not worry about it and its fine to just delegate error reporting to QEMU ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 22/07/2015 13:46, Daniel P. Berrange wrote:
IIUC, the SCSI passthrough feature for virtio-blk is enabled by setting the 'scsi=on' property on the virtio-blk device, which is exposed by libvirt with XML:
<disk type='block' device='lun'> <driver name='qemu' type='raw'/> <source dev='/dev/sda'/> <target dev='vda' bus='virtio'/> </disk>
(For use with virtio-scsi you'd just change the <target> element)
So if the guest is using virtio-1.0, then this will now fail to boot, or cause an error from monitor hotplug. This is not too bad, but I'm just wondering if there's anything else we ought to think about doing in libvirt in this situation. Normally we'd try to detect unsupported things upfront so we can report VIR_ERR_CONFIG_UNSUPPORTED, instead of the generic error code VIR_ERR_INTERNAL_ERROR, but perhaps this is sufficiently niche to not worry about it and its fine to just delegate error reporting to QEMU ?
Probably. Note that it will be a long time before the default is changed to 1.0 (if it ever will). Perhaps you can start warning now about <disk type='block' device='lun'>, and suggest using virtio-scsi instead? Paolo
On Wed, Jul 22, 2015 at 01:53:14PM +0200, Paolo Bonzini wrote:
On 22/07/2015 13:46, Daniel P. Berrange wrote:
IIUC, the SCSI passthrough feature for virtio-blk is enabled by setting the 'scsi=on' property on the virtio-blk device, which is exposed by libvirt with XML:
<disk type='block' device='lun'> <driver name='qemu' type='raw'/> <source dev='/dev/sda'/> <target dev='vda' bus='virtio'/> </disk>
(For use with virtio-scsi you'd just change the <target> element)
So if the guest is using virtio-1.0, then this will now fail to boot, or cause an error from monitor hotplug. This is not too bad, but I'm just wondering if there's anything else we ought to think about doing in libvirt in this situation. Normally we'd try to detect unsupported things upfront so we can report VIR_ERR_CONFIG_UNSUPPORTED, instead of the generic error code VIR_ERR_INTERNAL_ERROR, but perhaps this is sufficiently niche to not worry about it and its fine to just delegate error reporting to QEMU ?
Probably. Note that it will be a long time before the default is changed to 1.0 (if it ever will).
I fully expect we'll enable modern by default in 2.5. We'll also disable legacy if the bus used is pcie. We can disable modern if bus is pci and scsi passthrough was requested.
Perhaps you can start warning now about <disk type='block' device='lun'>, and suggest using virtio-scsi instead?
Paolo
participants (3)
-
Daniel P. Berrange -
Michael S. Tsirkin -
Paolo Bonzini