Hide Forgot
> Description of Problem: "virsh attach-disk" doesn't attach a disk with a specified name. The name of the virtual device attached by the command run according to "Step to Reproduce" is an unexpected one. We believe that this unexpected behavior is due to a bug of the said command. Could you please fix it so that a device name can be specified as expected? Architecture: x86_64 Kernel Version: kernel-2.6.32-71.el6.x86_64 Related Package Version: libvirt-client-0.8.1-27.el6.x86_64 > How reproducible: Always > Step to Reproduce: 1) Start a guest OS. # virsh start <domain-id> 2) Confirm that there is neither "vdb" nor "vdd" on the guest domain. $ ls /dev/vd* /dev/vda /dev/vda1 /dev/vda2 /dev/vda3 3) Run "virsh attach-disk" with the above xml file. # virsh attach-disk <domain-id> /dev/sdb2 vdd Disk attached successfully 4) Confirm what name the virtual device on the guest domain is. guest$ ls /dev/vd* /dev/vda /dev/vda1 /dev/vda2 /dev/vda3 /dev/vdb ~~~~~~~~~ <The virtual device's name is not the specified "vdd" but "vdb".> > Actual Results: "virsh attach-disk" doesn't attach a disk with a specified name. > Expected Results: "virsh attach-disk" attaches a disk with a specified name. > Hardware configuration: Model: Fujitsu PRIMEQUEST 1800 CPU Info: Intel(R) Xeon(R) CPU E7540 2.00GHz Memory Info: 16GB
Step1: host# virsh attach-disk rhel6-x86-64 /dev/sdb1 vdd Disk attached successfully Step2: > additional information guest# ls /dev/vd* /dev/vda Log: 10:21:00.139: debug : qemuDomainPCIAddressSetNextAddr:2278 : PCI addr 0:0:0 already in use 10:21:00.139: debug : qemuDomainPCIAddressSetNextAddr:2278 : PCI addr 0:0:1 already in use 10:21:00.139: debug : qemuDomainPCIAddressSetNextAddr:2278 : PCI addr 0:0:2 already in use 10:21:00.139: debug : qemuDomainPCIAddressSetNextAddr:2278 : PCI addr 0:0:3 already in use 10:21:00.139: debug : qemuDomainPCIAddressSetNextAddr:2278 : PCI addr 0:0:4 already in use 10:21:00.139: debug : qemuDomainPCIAddressSetNextAddr:2278 : PCI addr 0:0:5 already in use 10:21:00.139: debug : qemuDomainPCIAddressSetNextAddr:2283 : Allocating PCI addr 0:0:6 10:21:00.139: debug : qemuMonitorAddDrive:1897 : mon=0x7ff5ec0015f0 drive=file=/dev/sdb1,if=none,id=drive-virtio-disk3,format=raw ... 10:21:00.147: debug : virJSONValueToString:1059 : result={"execute":"device_add","arguments":{"driver":"virtio-blk-pci","bus":"pci.0","addr":"0x6","drive":"drive-virtio-disk3","id":"virtio-disk3"}}
Additional Note: 1. When a device is detached, index of vd* is not decremented. This causes vd* keeps incremented when you attach a device. BZ: https://bugzilla.redhat.com/show_bug.cgi?id=692767 I already verified the fix with an attached patch. 2. When <target> is specified in virsh, for example, virsh attach-disk <domain> <source> <target>, simply gets omitted. We see the same result with "attach-device". http://libvirt.org/formatdomain.html#elementsDisks [target] The target element controls the bus / device under which the disk is exposed to the guest OS. The dev attribute indicates the "logical" device name. The actual device name specified is not guaranteed to map to the device name in the guest OS. Treat it as a device ordering hint. The optional bus attribute specifies the type of disk device to emulate; possible values are driver specific, with typical values being "ide", "scsi", "virtio", "xen" or "usb". If omitted, the bus type is inferred from the style of the device name. eg, a device named 'sda' will typically be exported using a SCSI bus. Since 0.0.3; bus attribute since 0.4.3; "usb" attribute value since after 0.4.4 As you can see from the above link, "target" is used just as a hint, assigning specific device names in kernel layer is not a common approach, and it would be better to assign names via userland such as udev. Engineering, please let us know how you are going to fix this issue. Updating man page, and/or, disabling target option, or something else?
Per the documentation you quoted, this functionality is working as designed: "The actual device name specified is not guaranteed to map to the device name in the guest OS." Given that we've already documented that it's not guaranteed to be honored, there's nothing more we can do here. Device naming in the guest is dependent on the guest OS.