RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 693372 - [RHEL6.0] "virsh attach-device" doesn't attach a device with a specified name.
Summary: [RHEL6.0] "virsh attach-device" doesn't attach a device with a specified name.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Libvirt Maintainers
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: GSS_6_2_PROPOSED
TreeView+ depends on / blocked
 
Reported: 2011-04-04 13:20 UTC by asilva
Modified: 2018-11-14 14:40 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-02 21:12:22 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description asilva 2011-04-04 13:20:48 UTC 
> 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
Comment 1 asilva 2011-04-04 13:30:32 UTC 
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"}}
Comment 2 Shinji Kito 2011-04-05 02:06:23 UTC 
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?
Comment 3 Dave Allan 2011-04-05 03:25:22 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.