Description of problem: I was trying to install Windows XP x86. Both QEMU and Xen could not map the cd-rom after the first restart. I tried to add it manually as new storage device as /dev/scd0 , but Windows continued to report that it can not locate the CD-ROM. Version-Release number of selected component (if applicable): virt-manager 0.4.0 How reproducible: Install Windows XP. Steps to Reproduce: 1. 2. 3. Actual results: Error - Windows can not find the cd-rom device. Expected results: Continue installing Windows XP Additional info:
I have this problem also. It is not specific to Windows XP though. Anytime the OS asks for a reboot during the installation process, the install medium is lost after the reboot (ISO or physical disc). I have this problem installing Windows, FreeDOS, and any other OS which requires a reboot in the middle of the installation process. Basically, the install medium needs to remain persistent until the user specifies otherwise. Maybe the GUI should have a "load/eject" media button to allow you to change discs or specify a new ISO image. Also, since this makes installation difficult for most operating systems, I would suggest changing the issue from low severity to medium (at minimum).
change QA contact
I too have this problem, however this does sound like a duplicate of Bug 242291 which I believe has been fixed. Is that assumption correct?
I am having a similar issue with Feodora core 8 adding windows server 2003 using a new instance of QEMO. The media is a DVD iso image. Everything is working fine until the server OS needs to reboot that causes me to run the VM. After the systems restarts the Windows OS can't find the CD because its no longer there. This happen consistently. I copied down what the CD configuration looks like during pre-reboot. I add the CD as a simple file /dev/sc0, but it still can't find it.
I fixed my issue. It took a while, but I did get the CD to work. Thanks, Paul
Changing subject line. Note: this bug has not been taken by the component owner since June ?
Newly created VMs *do* now have the CDROM device permanently attached. It will not, however, have any media loaded. Media can be inserted via the Hardware tab in the VM Details dialog.
My mistake, the summary I wrote was a bit inaccurate. The problem is that some OSes from Microsoft requires rebooting as part of the installation process. As of the latest virt-manager in Rawhide (0.5.3-2), after the first reboot, the ISO image used when the VM was created is no longer attached to the guest OS. The GUI is also incorrect in that it does not list 'hdc' at all, even though when booting the machine, it does indeed have a CDROM device. (ps: rename it to Optical?)
Hi, in response to comment #9: The iso image or physical media not being accessible to the guest after the first reboot is intentional. The cd device should still exist for the guest, however it should have no media attached. Reason being: we don't want a guest tying up a physical device (cdrom) indefinitely. That being said, the cd device SHOULD be attached after the first reboot, but for a kvm test I just did this is not the case.
Well at least you've seen the problem--and I agree with the premise of not persistently attaching the media. However, will the virt manager have a feature to add removable media during run-time?
Cole, When you have a patched/updated version can you make it available in updates-testing for Fedora 8 so that I can try it?
Okay so there are a few issues here. For xen guests, the cdrom device is kept around after install, _empty_ as expected. For qemu based guests though this was specifically disabled to accommodate a long standing libvirt bug which prevented a qemu guest from having an empty cdrom. This is now fixed in libvirt upstream (see bug 435966). This bug also prevented eject/insert of media to an existing qemu cdrom device from working in virt-manager. This now also works, with better error reporting (see bug 434928). FINALLY the actual fix, which will keep the cd device around after the first stage of the install for a qemu guest, I have just committed: http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=9d72e4722c7f So this fix is contingent on the libvirt change, but I'll see if I can get both backported to f8. This fix will most likely be in f9 as well.
This is all good news. If there is a release for f8, let me know and I will "kick the tires" on it.
FYI, this is in rawhide and will be in f9 but hasn't been backported to f8 yet.
Will it be backported to F8?
It's not entirely my say, but I don't know any reason it can't be backported, it will just take some coordination between libvirt and virtinst packages. I'll talk to the libvirt maintainer.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Moving to F8.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This won't be fixed for F8, but is already fixed in F9, so closing as CURRENTRELEASE.
Ugh, wrong bug. Moving back to ASSIGNED.
This fix is for python-virtinst, so moving to that component.
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
This works quite well in Fedora 10 (and probably did in Fedora 9). Thanks!