Description of problem: It is impossible to block attach a cdrom device to a PV guest domain if the dom0 is running RHEL 5.6. This problem can be easily and consistently reproduced. Version-Release number of selected component (if applicable): kernel-xen-2.6.18-238.el5.x86_64.rpm How reproducible: Steps to Reproduce: 1. Install RHEL 5.6 with Xen Hypervisor. 2. Install a PV guest domain named "domu" using virt-manager (could be RHEL 5.6 or RHEL 5.5) 3. Put a CD/DVD into DVD/CD drive 4. Try following command, # virsh attach-disk domu /dev/cdrom xvde or # xm block-attach domu /dev/cdrom /dev/xvde Actual results: Although the attach-disk or block-attach command returns without error. The device /dev/xvde isn't created in guest domain. Expected results: The device /dev/xvde should be created in guest domain. Additional info: a) RHEL 5.5 doesn't have this issue. b) Block attach ISO file and LV doesn't have this issue. c) Downgrade the kernel-xen from 5.6 (kernel-xen-2.6.18-238.el5.x86_64.rpm ) to 5.5 (kernel-xen-2.6.18-194.el5.x86_64.rpm) will solve the problem.
Summary of tests ---------------- (For patch in attachment 518866 [details].) The following test cases (taken and amended from comment 18 and comment 19) describe the configurations that make sense. (Other cases above explore behavior under invalid or useless configuration.) The T1, T2, and T3 tests are described in comment 18 in detail. nr g.type g.ver. disk specifier atch.time T1 T2 T3 -- ------ ------ -------------------------- --------- ---- ---- ---- 05 HVM RHEL-5 phy:/dev/cdrom,hdc:cdrom,r boot OK OK OK 06 HVM RHEL-5 phy:/dev/cdrom,hdc:cdrom,r dynamic OK OK OK 21 HVM RHEL-6 phy:/dev/cdrom,hdc:cdrom,r boot [04] 22 HVM RHEL-6 phy:/dev/cdrom,hdc:cdrom,r dynamic [04] 33 PV RHEL-5 phy:/dev/cdrom,xvdb,r boot OK OK n/a 34 PV RHEL-5 phy:/dev/cdrom,xvdb,r dynamic OK OK n/a Test cases #05, #06, #21 and #22 check with {RHEL-5, RHEL-6} HVM guests whether the host CD-ROM can be attached to them as an emulated device {at boot time, dynamically}. The checks focus on initial reading (T1), on correct refusal of write attempts to the block device (T2), and on reading a second, bigger media / vbd reconfiguration with xm (T3 -- see bug 221676). RHEL-5 passes. RHEL-6 seems to have problems with basic functionality (T1): [04] The emulated /dev/hdc drive never appeared in the guest, not even when I added "xen_emul_unplug=nics" or "xen_emul_unplug=never". This is probably a bug, but not one that the current patch introduces. See the end of comment 18 for more. As justified in comment 16, the host CD-ROM is not supported as a PV-on-HVM block device (otherwise planned to be covered by test cases #13-16 and #29-32, see comment 19). Test cases #33 and #34 are the topic of this bug. As mentioned separately in comment 19, the virsh command in comment 0 works with the patch applied, when the "--mode readonly" option is appended as well. The T3 tests are not supported. (I actually attempted to detach the original host CD-ROM and then attach & read a bigger one. When the first CD-ROM was attached at boot time (test case #33), netback reported "attempt to access beyond end of device" on the second, bigger CD-ROM -- see bug 221676 and commit 0ceaa9b9 for explanation. When the first CD-ROM was attached dynamically instead, ie. after boot time (test case #34), then the media change with virsh attach-disk / detach-disk, and consequently reading the bigger media *seemed* to work. Nonetheless, this usage is unsupported as well. What can be reasonably expected to work is to attach the host CD-ROM to the PV guest once (at boot or dinamycally), and then sticking to it until the lifetime of the guest.) For PV tests only a RHEL-5 guest was employed, because the difference in unplugging support between RHEL-5 and RHEL-6 should play no role under PV. See also comment 17 about the VDISK_CDROM flag.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Will the problem showed in test case 21 and 22 be fixed? Regards
(In reply to comment #34) > Will the problem showed in test case 21 and 22 be fixed? A different BZ should be filed for those cases -- the problem is unrelated to this patch. Earlier I checked with pristine -279 and -235 (because 518866 was added to -236 first), and retested #21 (RHEL-6.1 HVM guest, phy:/dev/cdrom,hdc:cdrom,r attached persistently in the config file). I tried with "xen_emul_unplug=never" and also without it. In any case, I could not see the host's CD-ROM in the RHEL-6.1 guest.
Patch(es) available in kernel-2.6.18-284.el5 You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5 Detailed testing feedback is always welcomed.
Agreed. (In reply to comment #35) > (In reply to comment #34) > > Will the problem showed in test case 21 and 22 be fixed? > A different BZ should be filed for those cases -- the problem is unrelated to > this patch. Earlier I checked with pristine -279 and -235 (because 518866 was > added to -236 first), and retested #21 (RHEL-6.1 HVM guest, > phy:/dev/cdrom,hdc:cdrom,r attached persistently in the config file). I tried > with "xen_emul_unplug=never" and also without it. In any case, I could not see > the host's CD-ROM in the RHEL-6.1 guest.
I tested the 6 cases in the comment 20, with kernel-xen -300. For the PV cases 33 and 34, I verified that the Xen virtual block device, either attached at boot time or dynamically, is present and can be correctly read and refuse to write. I also tested RHEL6 PV cases, the results are the same as RHEL5. But for the case 06, after block-attach I cannot see the hdc in the RHEL5 guest. (Attach at boot time works). There's no output from the guest dmesg. It's the same with -274 or -300 kernel. That's different from what you described in comment 20, can you check that?
nr g.type g.ver. disk specifier atch.time T1 T2 T3 -- ------ ------ -------------------------- --------- ---- ---- ---- 06 HVM RHEL-5 phy:/dev/cdrom,hdc:cdrom,r dynamic ? ? ? (1) After creating the VM, verify the presence of the ",hdc:cdrom,r" element in the disk = [...] array in the VM config. (It should have been added by the installer (virt-install or virt-manager) automatically.) Boot the guest. (2) In the guest, the /dev/hdc node should exist immediately after boot. (3) Insert a CD-ROM into the host drive with only a 4 MB file on it. (4) Issue the following commands in the host: # GUEST_NAME=... # xm block-configure $GUEST_NAME phy:/dev/cdrom hdc:cdrom r (5) T1 -- Issue the following commands in the guest: # mount /dev/hdc /media mount: block device /dev/hdc is write-protected, mounting read-only # cat /media/4m | wc -c 4194304 (6) T2 -- Issue the following commands in the guest: # umount /media # head -c 10k /dev/zero >/dev/hdc -bash: /dev/hdc: Read-only file system (7) T3 -- Issue the following commands in the guest: # eject /dev/hdc (8) T3 -- replace the CD-ROM in the host drive with a bigger one: one that has an 8 MB file on it. (9) T3 -- issue the following command in the host: # xm block-configure $GUEST_NAME phy:/dev/cdrom hdc:cdrom r (10) T3 -- Issue the following commands in the guest: # mount /dev/hdc /media mount: block device /dev/hdc is write-protected, mounting read-only # cat /media/8m | wc -c 8388608 (11) Issue the following command in the guest: # eject /dev/hdc (12) Remove the CD-ROM from the host drive. Summary: for test case 06, "xm block-configure" is always used, and "xm block-attach" never.
I re-checked the case 06 following your advice, using xm block-configure, instead of xm block-attach. At the first time T1 fails because the mount failed as "No medium found". But I found this is solved by first executing 'eject /dev/hdc' in guest. Then all T1,T2,T3 tests past for this case. As a complement to the comment 41, this could be put to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0150.html