Hide Forgot
Libvirt forces user's to manually allocate a disk <target dev=XXX/> value when adding new disks to the XML. There's really no good reason we can't allocate one automatically, just giving the first free value, like we do for address allocation. It's needless pain for users and apps to handle.
*** Bug 1455814 has been marked as a duplicate of this bug. ***
Thanks Cole. Here was my description from the other bug: --- I'm trying to create a guest with 500 disks for testing, writing the XML by hand. I got to: <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/home/rjones/disk1.img'/> <target bus='scsi'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/home/rjones/disk2.img'/> <target bus='scsi'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> (etc) but then libvirt complains: error: missing target information for device /home/rjones/disk1.img which is technically true, but honestly couldn't libvirt just generate those target device names? Writing 500 of them by hand is impossible. Version-Release number of selected component (if applicable): libvirt-3.2.0-3.el7.x86_64
Not sure why I hadn't noticed this BZ before Rich's bug was marked as a duplicate, but I agree 100% that mandatory <target dev='blah'> is just a really bad idea in most cases. It's not just that libvirt could automatically generate the names, but in at least the case of qemu, the target dev name is *never even used*. There is no way for libvirt to even *suggest* that a particular name be used for a device in the guest - that's all determined by the guest kernel when it probes the device. So libvirt goes to all the trouble to require the target dev name, stores it in the config, passes it around internally to wherever, but never informs qemu (or the guest) of the name *because there is no way to do that*. It's just pointless bookkeeping. Beyond that, having this unused target dev name in the XML can mislead admins into believing that they actually do have control over the name of the device node in the disk, and they could end up assigning a name to one device in the XML that ends up being used for a completely different device in the guest, then get confused/annoyed when reality doesn't match their expectations. (I believe the origin of target dev name was from the xen driver where it probably *is* used. I think it also is used for lxc). I wonder if there is any management software which would barf if target dev was missing from the XML. If not, then I would even go so far as to suggest we not only make it optional in the input XML, but also only auto-generate it for those drivers that actually use it.
I largely agree with your points, but in practice the target dev name is basically the unique ID for a <disk> device, so it's explicitly used in APIs like fetching block stats. Apps like virt-manager that do device hotplug currently need to consume the target dev for existing VMs to make sure the XML we add has a non-conflicting target dev, so if it disappeared we would need to adjust. I don't think we can realistically make it disappear...
(In reply to Cole Robinson from comment #4) > I largely agree with your points, but in practice the target dev name is > basically the unique ID for a <disk> device, so it's explicitly used in APIs > like fetching block stats. Right, as Cole says, virt-top (for one) will break if the dev attribute is not present. We'll have to generate something there.