Description of problem: when boot up guest with both 'xvdx' and 'hdx' disks attached, the disk which has the 'xvdx' specified will not be recognized. Version-Release number of selected component (if applicable): xen-3.0.3-126.el5 How reproducible: 100% Steps to Reproduce: 1. boot up guest with 2 disks attached, one has 'xvdx' specified for VDEV, and the other has 'hdx' specified for VDEV: disk = ['file:/path/to/guest_disk,xvda,w','file:/path/to/empty_disk.raw,hda,w'] Actual results: The disk which has 'xvdx' specified will not be recognized, so guest will report no bootable disk available during booting. Expected results: All the disks should be recognized. Additional info: [1] the disk which has 'hdx' specified can be recognized. [2] the defect also exist with xen-3.0.3-120.el5
Created attachment 488702 [details] xend log
Created attachment 488703 [details] xm dmesg log
Created attachment 488705 [details] xend log
Can you please try with different letters (>e). xvd{a|b} are shared with hd{a|b} for booting reasons. In case this is not problem for higher letters, close this as not a bug.
I tried with different letters(>e). The disk which has 'xvdx' specified is still not recognized.
Problem is in disk order in guest. hd(x) disk are ordered before xvd(x) so in your case empty_disk.raw is the one guest trying to boot from.
Reopening again as problem clarified with reporter. xvda is not accessible during guest installation from hdc cdrom device. Also strange device renaming (hdb -> xvde) is observed in post-install boot.
Created attachment 489106 [details] patch to fix this issue The problem lies in qemu. It tries to change all xvd* devices to hd* devices. However, only one flag(is_hdN) would bypass such scheme when the disks are configured as description. The patch fixes this problem via an array, so that all xvd* devices can be changed to hd* devices.
Fix built into xen-3.0.3-128.el5
This caused a regression when both hda and xvda are present in the same guest. Huang Wenlong should open a BZ soon.
(In reply to comment #13) > This caused a regression when both hda and xvda are present in the same guest. > Huang Wenlong should open a BZ soon. Hi, this is not regression. xvd{a,b} and hd{a,b} are mapped to same device and can't be used in one guest. This is know behavior of guest.
> This is not regression. xvd{a,b} and hd{a,b} are mapped to same device and > can't be used in one guest. This is know behavior of guest. Sorry, I should have been clearer - the problem is with Windows guests. See bug 697455.
*** Bug 697455 has been marked as a duplicate of this bug. ***
QA verified this bug with xen-3.0.3-129.el5: 1) rhel5 and rhel6 pv guest: The following configurations have been tested: disk = ['tap:aio:/path/to/RHEL-Server-5.5-32-pv.raw,hda,w', 'file:/path/to/RHEL-Server-5.5-32-hvm.raw,xvdb,w'] disk = ['tap:aio:/path/to/RHEL-Server-5.5-32-pv.raw,hda,w', 'file:/path/to/RHEL-Server-5.5-32-hvm.raw,hdb,w'] disk = ['tap:aio:/path/to/RHEL-Server-5.5-32-pv.raw,xvda,w', 'file:/path/to/RHEL-Server-5.5-32-hvm.raw,xvdb,w'] disk = ['tap:aio:/path/to/RHEL-Server-5.5-32-pv.raw,xvda,w', 'file:/path/to/RHEL-Server-5.5-32-hvm.raw,hdb,w'] disk = ['tap:aio:/path/to/RHEL-Server-5.5-32-pv.raw,xvda,w', 'tap:aio:/path/to/RHEL-Server-5.5-32-hvm.raw,hdb,w'] disk = ['file:/path/to/RHEL-Server-5.5-32-pv.raw,xvda,w', 'tap:aio:/path/to/RHEL-Server-5.5-32-hvm.raw,hdb,w'] All scenarios work well. fdisk -l shows that the disks are there. 2) rhel5 and rhel hvm guest: The following confiurgations have been tested: disk = ['file:/path/to/RHEL-Server-5.5-32-hvm.raw,hda,w', 'file:/root/boot.iso,hdc:cdrom,r'] disk = ['file:/path/to/RHEL-Server-5.5-32-hvm.raw,xvda,w', 'file:/root/boot.iso,hdc:cdrom,r'] disk = ['file:/path/to/RHEL-Server-5.5-32-hvm.raw,hda,w', 'file:/root/boot.iso,xvdc:cdrom,r'] disk = ['file:/path/to/RHEL-Server-5.5-32-hvm.raw,xvda,w', 'file:/root/boot.iso,xvdc:cdrom,r'] All scenarios work well. Both disk and iso could be accessed during os installation. 3) Windows guest, a) start with hda + xvda, the guest could boot successfully; the second disk would show up as an pv device after pv driver is installed within the guest, otherwise only the first disk shows up. b) start with hda + xvdb, the guest could boot successfully; the second disk would show up as an qemu emulated disk when pv driver is not installed, otherwise both the first and the second disk show up as pv device. 4) Linux HVM guest, a) start with hda + xvda, the guest could boot successfully; hda and xvda show up within the guest. b) start with hda + xvdb, the guest could boot succsssfully; had, hdb and xvdb show up within the guest. So we could move this bug to VERIFIED.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: When a guest was configured with both xvd[x] and hd[x] disks attached (where [x] is a sequential identifying letter), the disk, for which xvd[x] was specified, was not recognized, and the guest reported no available bootable disk during boot. With this update, the qemu-dm device model accesses all xvd[x] disks as though they were IDE devices, and all guests now boot properly in the described scenario.
Removed reference to qemu-dm, it is an internal detail. What is important is that the guest sees the disks as IDE devices.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -When a guest was configured with both xvd[x] and hd[x] disks attached (where [x] is a sequential identifying letter), the disk, for which xvd[x] was specified, was not recognized, and the guest reported no available bootable disk during boot. With this update, the qemu-dm device model accesses all xvd[x] disks as though they were IDE devices, and all guests now boot properly in the described scenario.+When a guest was configured with both xvd[x] and hd[x] disks attached (where [x] is a sequential identifying letter), the disk configured as xvd[x] was not recognized. The guest then could fail to boot, reporting no available bootable disk. With this update, Xen fully-virtualized guests will show xvd[x] disks also as IDE devices, letting guests boot properly in the described scenario.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -When a guest was configured with both xvd[x] and hd[x] disks attached (where [x] is a sequential identifying letter), the disk configured as xvd[x] was not recognized. The guest then could fail to boot, reporting no available bootable disk. With this update, Xen fully-virtualized guests will show xvd[x] disks also as IDE devices, letting guests boot properly in the described scenario.+When a guest was configured with both xvd[x] and hd[x] disks attached (where [x] is a sequential identifying letter), the disk configured as xvd[x] was not recognized. The guest then could fail to boot, reporting no available bootable disk. With this update, Xen fully-virtualized guests show xvd[x] disks also as IDE devices, letting guests boot properly in the described scenario.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1070.html