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

[Martin Kletzander]

On Mon, Jan 27, 2014 at 10:37:44AM -0500, Cole Robinson wrote:
> 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?
>

Short answer: Yes, see Bug 1036716 [1].  However, such simplification
would miss some important points.  Sorry for the confusion in the
first mail, I'll try to be more clear this time.

At first, there was a problem with multiple VirtIO-SCSI disks (Bug
950330 [2]).  When Virtio-SCSI disk was added, we added a virtio-scsi
controller, but if there was a default-scsi controller in the XML and
virt-manager specified 'index=0', those two clashed and the XML
couldn't be defined.  When fixing this fairly simple issue, I tried to
foresee the future a little bit and apart from only specifying the
index, I also modified the address of the disk to point at that exact
controller (since, in libvirt, by default the disks are being attached
to controllers sequentially or depending on it's 'target' value) which
resulted into this address:

<address type='scsi' controller='X'/>

where 'X' is the virtio-scsi controller index.  But what I didn't know
was that if you add this address to libvirt, it takes the address as
granted and all unspecified parameters (bus, target, unit) default to
zeroes.  That makes all disks assigned to the same address, which is,
of course, invalid.

So when this issue was discovered with multiple VirtIO-SCSI disks (Bug
1036716 [1]), I started investigating again.  I came to conclusion
that we can do two things:

 a) Start tracking all the addresses for SCSI disks, check what
    controllers they are assigned to and if there is new one added,
    we'd either change the address or re-calculate the 'target'.  We'd
    also have to check what scsi controllers the underlying qemu
    supports and what libvirt will select as default.  OT: Depending
    on the address we could pretty-print the disk properly as
    VirtIO-SCSI disk (which we currently do not).

 b) Remove the differences between these disks and let libvirt and
    qemu do their job of selecting the best option.

To explain point (b) a bit more; if the controller model is 'default',
it can be either some legacy SCSI controller or virtio-scsi.  That
depends on what qemu supports and what libvirt chooses.  Newer
upstream x86 qemu has only virtio-scsi IIRC (I had to fix this in
libvirt commit b7f1c0c3 [3]), so with such qemu all SCSI disks are
virtio-scsi anyway.  Also some qemu versions might not have
virtio-scsi at all.

Sorry to waste your time with such silliness, but it's something
that's been worrying me for a while there.

Martin

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1036716
[2] https://bugzilla.redhat.com/show_bug.cgi?id=950330
[3] http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=b7f1c0c3

> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20140128/0347aead/attachment.sig>