Red Hat Bugzilla – Bug 244802
Newly-created VMs should keep initial CDROM image setting
Last modified: 2009-02-27 00:50:12 EST
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):
Install Windows XP.
Steps to Reproduce:
Error - Windows can not find the cd-rom device.
Continue installing Windows XP
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
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?
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:
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:
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:
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!