[virt-tools-list] [virt-manager PATCH RFC] Remove the difference between VirtIO-SCSI and pure SCSI disks

Cole Robinson crobinso at redhat.com
Mon Jan 27 15:37:44 UTC 2014


On 01/27/2014 09:01 AM, Martin Kletzander wrote:
> These disk types are differentiated by the *model* of the controller
> they are connected to.  I added a patch that ensures the controller
> which these disk are connected to has model='virtio-scsi', but that is
> breaking libvirt's address generation; having <address
> type='whatever'/> specified makes all unspecified values to fallback
> to zeroes.  Libvirt's address generation is very deterministic (values
> are taken from the disk's target), but will be reliable for an unknown
> period and it's dependant on the order of the controllers.  Other
> thing we can do is not to differentiate between those two and let the
> user decide since the controller model can now be changed using in UI.
> 

I'm having trouble following this exactly: is there currently a problem that
can be reproduced with virt-manager?

> There's bunch of differences between these two approaches, but mainly,
> from code POV I think it is not desirable to show all the disk types
> to the user.  That would mean lots of changes which might not last
> long.  Also we might not be able to guarantee the disk won't be VirtIO
> if the user doesn't select it, e.g. it's the only scsi controller
> available in qemu.  The machine may not start if virtio-scsi
> controller is not available in such qemu OTOH.  My suggestion would be
> to get rid of the differences.  And to see how "huge" the patch would
> be in that case, have a look yourself below (I hope it's correct, it
> works for me at least).
> 

I see the virtio-scsi bit as a UI convenience option for a qemu feature that
people commonly ask about. Like how controller model USB2 in the UI maps to 4
distinct controllers in the XML.

Indeed to list all scsi models exhaustively in the bus combobox would be
insane and overkill, but then again none of the other scsi models are
anywhere near as high visibility.

Without this option we'd have to force users to understand that 'oh well
virtio-scsi isn't really a bus type in the way virtio-blk is, it's really just
plain scsi with a virtio-scsi _controller_, so you have to add a controller
blah blah etc." No thanks :)

So unless there's an intractable issue or nasty side effect (I may have missed
it in the first paragraph), I'd like to keep the virtio-scsi behavior. But I'm
open to alternate UI suggestions.

- Cole




More information about the virt-tools-list mailing list