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 607083 - virtinst disconnects CDROM drive during XP install, preventing stage 2 of install to complete
Summary: virtinst disconnects CDROM drive during XP install, preventing stage 2 of ins...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: python-virtinst
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Cole Robinson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 607409 (view as bug list)
Depends On:
Blocks: 599016
TreeView+ depends on / blocked
 
Reported: 2010-06-23 07:34 UTC by Jes Sorensen
Modified: 2010-11-10 21:23 UTC (History)
7 users (show)

Fixed In Version: python-virtinst-0.500.3-5.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-10 21:23:55 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Backport of upstream fix (1.07 KB, text/plain)
2010-06-28 14:39 UTC, Cole Robinson 		no flags Details
virt-manager --debug output when install win xp without choosing the type and version (9.07 KB, application/octet-stream)
2010-07-02 01:55 UTC, Wayne Sun 		no flags Details
View All

Description Jes Sorensen 2010-06-23 07:34:20 UTC 
Description of problem:
libvirt disconnects CDROM drive after first stage of XP install,
preventing stage 2 of install to complete. XP comes up asking 
for the user to insert the CDROM, but according to virt-manager
the drive _is_ connected.

Version-Release number of selected component (if applicable):
virt-manager-0.8.4-3.el6.noarch
libvirt-0.8.1-7.el6.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Install XP using virt-install --prompt --os-type=windows --os-variant=winxp
2. Kill the VNC window that pops up and connect via VNC running on local system or virt-manager
3. Follow the install, wait for stage two
  
Actual results:
XP install fails at the point where it asks for CD #3.

Expected results:


Additional info:
I cannot say if the killing of the VNC window is related. I am installing on a machine located in Brno, and I am in France, so I need to run a local VNC client to make the VNC window usable.

I am unable to launch the install directly from virt-manager due to BZ#526952

Here is the log from /var/lib/libvirt/qemu/arm4.log. As you can see the cdrom argument is only present in the first launch, not when XP restarts for stage2. The hd0 output data is debugging output from qemu-kvm for the bug I was testing for, it should have zero impact on this specific problem as bburns was able to reproduce the problem with a version of qemu-kvm that doesn't have this output.

LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qem
u-kvm -S -M rhel6.0.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -na
me arm4 -uuid 0efa5cb9-c75d-8527-2c13-e370910ed0a7 -nodefaults -chardev socket,i
d=monitor,path=/var/lib/libvirt/qemu/arm4.monitor,server,nowait -mon chardev=mon
itor,mode=control -rtc base=localtime -no-reboot -boot d -drive file=/var/lib/li
bvirt/images/arm4.img,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus
=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/home/isos/en_windows
_xp_professional_with_service_pack_3_x86_cd_x14-80428.iso,if=none,media=cdrom,id
=drive-ide0-1-0,readonly=on -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-
1-0,id=ide0-1-0 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id
=net0,mac=52:54:00:3e:49:8e,bus=pci.0,addr=0x4 -chardev pty,id=serial0 -device i
sa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -k 
en-us -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 
char device redirected to /dev/pts/5
*** if_none#0 drive-ide0-0-0
*** if_none#1 drive-ide0-1-0
*** looking for drive-ide0-0-0
*** hd#0 seen 16383 16 63 drive-ide0-0-0
*** looking for drive-ide0-0-1
*** looking for drive-ide0-1-0
*** hd#2 seen 1196 16 63 drive-ide0-1-0
*** looking for drive-ide0-1-1
*** hd#0 geom 16383 16 63
*** hd#0 drive-ide0-0-0
*** hd#0 xlat 0
*** hd#1 <not present>
*** hd#2 drive-ide0-1-0
*** hd#2 xlat 0
*** hd#3 <not present>
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name arm4 -uuid 0efa5cb9-c75d-8527-2c13-e370910ed0a7 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/arm4.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=localtime -no-reboot -boot c -drive file=/var/lib/libvirt/images/arm4.img,if=none,id=drive-ide0-0-0,boot=on,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,fd=21,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:3e:49:8e,bus=pci.0,addr=0x4 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 -k en-us -vga std -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 
char device redirected to /dev/pts/2
*** if_none#0 drive-ide0-0-0
*** looking for drive-ide0-0-0
*** hd#0 seen 16383 16 63 drive-ide0-0-0
*** looking for drive-ide0-0-1
*** looking for drive-ide0-1-0
*** looking for drive-ide0-1-1
*** hd#0 geom 16383 16 63
*** hd#0 drive-ide0-0-0
*** hd#0 xlat 2
*** hd#1 <not present>
*** hd#2 <not present>
*** hd#3 <not present>
Comment 2 RHEL Program Management 2010-06-23 08:03:00 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Cole Robinson 2010-06-23 15:35:08 UTC 
Argh, crap, you are right. This regressed with the rebase. We have tests attempting to cover this, but due to some unfortunate code complication we weren't actually testing the correct pieces. Fixed upstream now:

http://hg.fedorahosted.org/hg/python-virtinst/rev/e5ab15cd4c24
Comment 4 Cole Robinson 2010-06-25 15:59:31 UTC 
*** Bug 607409 has been marked as a duplicate of this bug. ***
Comment 5 Cole Robinson 2010-06-28 14:39:51 UTC 
Created attachment 427433 [details]
Backport of upstream fix
Comment 6 dyuan 2010-06-30 06:57:51 UTC 
guest os is win2003_x86_64. Verified PASSED with python-virtinst-0.500.3-5.el6.
Comment 7 Wayne Sun 2010-06-30 08:29:04 UTC 
install with windows xp guest still failed with this problem under python-virtinst-0.500.3-5.el6.
Comment 8 dyuan 2010-06-30 10:08:00 UTC 
guest os is win2003_i386. Verified PASSED with python-virtinst-0.500.3-5.el6.
Comment 9 Cole Robinson 2010-06-30 14:30:25 UTC 
Wayne, how did you reproduce the failure? Did you make sure to indicate to either virt-install or virt-manager that you were installing a windows guest? If not, the CDROM won't remain attached.
Comment 10 Wayne Sun 2010-07-01 03:06:11 UTC 
Cole, funny thing happen. I always specify guest type and version in virt-manager, and it failed always. But when i did not set the type and version, leave it both as Generic, the cdrom is show in hardware details but not connected, so i need to click the connect button to proceed the installation. It's better than the cdrom even not show up, but the bug still here.

packages:
libvirt-0.8.1-12.el6.x86_64
qemu-kvm-0.12.1.2-2.90.el6.x86_64
kernel: 2.6.32-37.el6.x86_64
virt-manager-0.8.4-6.el6.noarch
python-virtinst-0.500.3-5.el6.noarch
seabios-0.5.1-1.el6.x86_64

Here is the log:
#cat /var/log/libvirt/qemu/winxp-again-notype
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name winxp-again-notype -uuid d8c10e45-8cdb-6930-c682-ac894ebc7e77 -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/winxp-again-notype.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -no-reboot -boot d -drive file=/var/lib/libvirt/images/winxp-again-notype.img,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/home/wayne/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=20,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:3e:5e:76,bus=pci.0,addr=0x4 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -vnc 127.0.0.1:0 -k en-us -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
char device redirected to /dev/pts/1
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name winxp-again-notype -uuid d8c10e45-8cdb-6930-c682-ac894ebc7e77 -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/winxp-again-notype.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/winxp-again-notype.img,if=none,id=drive-ide0-0-0,boot=on,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=20,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:3e:5e:76,bus=pci.0,addr=0x4 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -vnc 127.0.0.1:0 -k en-us -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3
char device redirected to /dev/pts/1
Comment 11 Cole Robinson 2010-07-01 15:42:48 UTC 
I am seeing correct behavior. The command line you posted in Comment #10 indicates you did NOT select windows as the OS in virt-manager.

Please provide the output of virt-manager --debug while reproducing.
Comment 12 Wayne Sun 2010-07-02 01:55:53 UTC 
Created attachment 428595 [details]
virt-manager --debug output when install win xp without choosing the type and version

virt-manager --debug output when install win xp without choosing the type and version. This output just stopped at when after reboot the disc needed window pop out.
Comment 13 Cole Robinson 2010-07-02 13:25:43 UTC 
I think we miscommunicated here. You need to select 'windows' in order for the install media to remain attached. Not selecting 'windows' is expected to eject the install media, and require a manual insert step in the second stage of the install.

I think this bug should be marked VERIFIED.
Comment 14 Wayne Sun 2010-07-05 06:15:12 UTC 
python-virtinst-0.500.3-5.el6.noarch
virt-manager-0.8.4-6.el6.noarch
libvirt-0.8.1-13.el6.x86_64 

Problem fixed, now after reboot, the cdrom still be connected to the guest.
Comment 15 Yan Tian 2010-07-07 14:30:05 UTC 
Changed status to VERIFIED refer to Comment 14.
Comment 16 releng-rhel@redhat.com 2010-11-10 21:23:55 UTC 
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.
Note You need to log in before you can comment on or make changes to this bug.