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 _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
