6:46 a.m.
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 :|
6:53 a.m.
New subject: [libvirt] [PATCH V3 2/3] virtio-blk: fail get_features when both scsi and 1.0 were set
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
9:56 a.m.
New subject: [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: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
3413
days inactive
3413
days old
2 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Michael S. Tsirkin -
Paolo Bonzini