Bug 473154 - Virtual machine fails to start without cdom - qemu: could not open disk image /dev/sr0
Virtual machine fails to start without cdom - qemu: could not open disk image...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
13
All Linux
medium Severity medium
: ---
: ---
Assigned To: Justin M. Forbes
Fedora Extras Quality Assurance
: Reopened
: 490206 494044 508671 516692 (view as bug list)
Depends On:
Blocks: F11VirtTarget
  Show dependency treegraph
 
Reported: 2008-11-26 15:23 EST by Russell Doty
Modified: 2010-04-26 08:16 EDT (History)
16 users (show)

See Also:
Fixed In Version: qemu-0.12.3-6.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 505090 (view as bug list)
Environment:
Last Closed: 2010-03-16 19:20:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Guess host device type from requested guest device type (1018 bytes, text/plain)
2009-04-06 21:10 EDT, Cole Robinson
no flags Details

  None (edit)
Description Russell Doty 2008-11-26 15:23:29 EST
Description of problem:

Installed Windows 2000 guest. After shutting down Windows 2000, can't run virtual machine.


Version-Release number of selected component (if applicable):


How reproducible:

Every time.


Steps to Reproduce:
1. Install F10 with virtualization
2. Create connection using QEMU as the hypervisor
3. Create guest
4. Install Windows 2000 in guest
5. Shut down windows 2000
6. Run shutdown power in vm
7. Select "run" in virtual machine
  
Actual results:

Error starting domain: internal error QEMU quit during console startup
qemu: could not open disk image /dev/sr0

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 532, in run_domain
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 380, in startup
    self.vm.create()
  File "/usr/lib64/python2.5/site-packages/libvirt.py", line 262, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error QEMU quit during console startup
qemu: could not open disk image /dev/sr0


Expected results:

Guest starts.


Additional info:

AMD Phenom 9600 processor. Fresh installation of released F10. SELinux in permissive mode.
Comment 1 Cole Robinson 2008-12-01 16:50:13 EST
Did you eject the physical CD before at some point before trying to start the VM (the failed start)? This would cause that error. If not, please post ~/.virt-manager/virt-manager.log
Comment 2 Russell Doty 2008-12-01 19:46:46 EST
Windows installed and ran with no problems - I ran a number of tests, including installing service packs and networking, and Windows was fully functional. 

The problem shows up when I shutdown Windows and close the guest. When I open and run the guest I get this error. Yes, I had removed the CD after completing the installation and installing Service Packs.

Based on your suggestion, I inserted the XP CD and started the guest. Windows then came up and ran! It timed out the first time I selected "run", and then started normally the second time I selected "run".

I then tried it with a Fedora 10 CD in the drive, and that worked. It appears that a CD - any CD - must be in the drive for Windows to start. Is this a known condition?

I now have both Windows 2000 and Windows XP running as guests.


On a separate note, I don't seem to have a .virt-manager directory or a virt-manager.log file. I searched the entire system and can't find either of these. Is this a problem?
Comment 3 Cole Robinson 2008-12-01 23:05:27 EST
virt-manager should create .virt-manager in your home directory: if you are running as root, it should pop up in /root/.virt-manager

This isn't really a bug per-say. If installing linux, the VM only needs the installation media for one stage of the install. Once the guest reboots, we detach the cdrom media.

Windows on the other hand has a two stage install, with a reboot in between. So if the user chooses windows, we keep the cdrom connected after the initial install. The upside is you don't get a 'cdrom empty' message for the second stage of the install. The downside is you can hit a situation like you are facing.

The solution is to go to the VM details section, find the 'hdc' cdrom drive, and eject '/dev/sr0'. There is a button that will do this for you.

Since we had people reporting bugs for not keeping the cdrom attached for windows post install, we will be keeping that behavior. So i'm closing as NOTABUG since this intended. Please reopen if you have any other issues.
Comment 4 Russell Doty 2008-12-02 09:28:13 EST
I would like to have this bug reopened.

The situation is that, following what I would consider to be normal practices, Windows guests fail. This will result in numerous customer issues.

Following the procedure:

1. Install Windows guest. Guest is running - no problems.

2. Reboot system - without a CD in the drive. I normally remove CDs after I'm through using them, and always remove a CD before rebooting a system.

3. Start Windows guest - fails with an obscure error message. Can't find problem after extensive Googling.

I have no issue with keeping the cdrom connected for second stage install. The problem comes up because the cdrom is connected after installation is completed. From my perspective, this is a system failure. I've been fighting this problem for over a month, with no idea how to proceed until your suggestion in a previous comment.

I may be unusually dense, but encountering this problem after using all defaults is what I would consider a significant bug.
Comment 5 Cole Robinson 2008-12-02 09:51:16 EST
We are in a lose-lose situation here. We either error when installing the guest, or we error post install when someone ejects the physical cd.

By removing the physical cd, it is essentially the same thing as deleting the hard disk image and trying to boot the VM: kvm won't find what you are telling it to use.

I sympathize with what you are saying, but I can't think of a solution offhand for this issue. I suppose we could try owning the install through multiple reboots or something like that, but it might not even be feasible. Either way, we can reopen this bug, but I don't know the proper solution (if there is one. The answer might just be to clearly document it somewhere).
Comment 6 Russell Doty 2008-12-02 10:02:35 EST
Cole,

The problem I'm seeing is that Windows guests are installed and working, and then completely fail after you restart the system, with no (usable) explanation. To me, this is a major problem.

The problem isn't installation, it is post installation.

The real fix would seem to be allowing the guest to boot if there is no CD in the drive.

At a minimum, can we add an explanation to the error message telling people that the problem may be no cd in the drive, and recommending disconnecting the cd?
Comment 7 Cole Robinson 2008-12-02 11:52:36 EST
(In reply to comment #6)
> Cole,
> 
> The problem I'm seeing is that Windows guests are installed and working, and
> then completely fail after you restart the system, with no (usable)
> explanation. To me, this is a major problem.
> 
> The problem isn't installation, it is post installation.
> 

Yes, I explicitly said this in my last comment:

We are in a lose-lose situation here. We either error when installing the
guest (disconnecting the cdrom after the initial install), or we risk erroring post install when someone ejects the physical cd (keeping the cdrom attached after initial install).

> The real fix would seem to be allowing the guest to boot if there is no CD in
> the drive.

This isn't our call, it's kvm's call. And as I mentioned above, it's analogous to saying 'please boot off this hard disk' and pointing to a non-existent file.
That said, it could be reasonable that qemu detects it as an empty cdrom and passes that through to the guest, but you'd have to file a bug against kvm and see what they say.

> 
> At a minimum, can we add an explanation to the error message telling people
> that the problem may be no cd in the drive, and recommending disconnecting the
> cd?

The error message comes straight from kvm, so there isn't a simple way for virt-manager to spruce it up. Libvirt tries to start the VM, notices it fails, and returns the error message up to the user.

I'll poke around and see if there is something clean we can do to avoid this situation.
Comment 8 Russell Doty 2008-12-02 13:17:18 EST
Ahh - I think I understand what is behind what you are saying: this is a kvm issue, not a virt-manager issue.

Can we just change the component for this bug to kvm?

From my perspective, this is a "virtualization in Fedora" issue, and it doesn't really matter which component it is assigned to as long as it gets resolved.

(And, thanks for taking the time to explain things!)
Comment 9 Johnray Fuller 2008-12-31 14:55:55 EST
This issue is caused by the installation CD-ROM being listed as a device in the /etc/libvirt/qemu/<virtual machine name>.xml file.

If you remove the CD-ROM stanza, the virtual machine will boot.

Ideally, this "device" could be auto-removed after the second boot (the first reboot, it needs to be there for the installation).

Johnray
Comment 10 Ari Tilli 2009-01-14 03:58:31 EST
I had never used virt-manager until yesterday and installed W2k quite quickly.
I run into the same message, but from the "error-print" I figured out what to do in about 1 minute, since it actually reports the problem IMHO.

As a fix I suggest that one could add to the "Add New"-wizard a short message when installing Windows OSs to explain how install CD is used.

For example, on top of last dialog before booting to virtual machine:

"NOTE: Remove install CD only after first boot and remember to disconnect mapping after removing the CD"  

P.S. virt-manager is awesome ;);)
Comment 11 Cole Robinson 2009-04-04 18:09:37 EDT
*** Bug 494044 has been marked as a duplicate of this bug. ***
Comment 12 Cole Robinson 2009-04-04 18:10:23 EDT
*** Bug 490206 has been marked as a duplicate of this bug. ***
Comment 13 Mark McLoughlin 2009-04-06 04:40:21 EDT
Okay, to summarise:

  1) Install a windows guest using an iso or cdrom in host drive

  2) virtinst leaves the cdrom attached to the guest after the install
     completes because Windows has a multi-stage install procedure

  3) At some point in the future, if you delete the iso or eject the cdrom
     and start the guest, it fails with an obscure error

Could it be fixed in virt-manager by sanity checking all storage before starting a guest and offering to dettach the cdrom if it isn't available?
Comment 14 Michael Monreal 2009-04-06 11:21:10 EDT
I was originally thinking about the case where you did not complete the installation yet but what you describe is probably an even better use case.

>> Could it be fixed in virt-manager by sanity checking all storage 
>> before starting a guest and offering to dettach the cdrom if it 
>> isn't available? 
Maybe it could ask to re-insert the medium or remove it from the configuration?
Comment 15 Cole Robinson 2009-04-06 21:10:11 EDT
Created attachment 338421 [details]
Guess host device type from requested guest device type

I just went digging through the qemu code, and I think the fix should really be at that level.

The code is already capable of being launched with an empty cdrom device attached to it. Unfortunately qemu only enables this mode for cdrom devices if the passed path starts with '/dev/cd': in the above case, we are using /dev/sr0 :( Yay robustness.

Patch basically says "If the user requests a cdrom/floppy device, and the passed path is a block or char device, assume the path is a host cdrom/floppy device." This would change some existing behavior: for example, a host block device that is passed to a qemu guest as a cdrom is now assumed to be a host cdrom, even when it isn't. My guess is this won't yield any real functional change, since the only differences between floppy/cdrom and everything else (in this case) is in the ejectable media commands.

I haven't done much testing besides verifying that qemu no longer complains about accessing the empty /dev/sr0.
Comment 16 Mark McLoughlin 2009-04-09 11:23:19 EDT
Nice one Cole - I think you should go ahead and post this to qemu-devel. At first glance, it looks reasonable to me.

Re-assigning to qemu.
Comment 17 Cole Robinson 2009-04-09 12:22:37 EDT
I'm going to do some additional testing over the weekend and make sure I'm not breaking anything, then send to qemu-devel next week.
Comment 18 Fedora Admin XMLRPC Client 2009-05-07 08:12:24 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 19 Fedora Admin XMLRPC Client 2009-05-07 08:13:31 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 20 Fedora Admin XMLRPC Client 2009-05-07 08:13:58 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 21 Fedora Admin XMLRPC Client 2009-05-07 13:58:20 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 22 Mark McLoughlin 2009-06-03 09:40:11 EDT
Cole: still planning to send this upstream?
Comment 23 Cole Robinson 2009-06-03 15:51:15 EDT
Ahh, yeah I forgot,s orry. I'll do that soon.
Comment 24 Bug Zapper 2009-06-09 05:56:53 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 25 david ahern 2009-06-10 11:44:10 EDT
Can Cole's patch get applied to the KVM tree used for RHEL5.4?
Comment 26 Eduardo Habkost 2009-06-17 16:48:16 EDT
New version of the fix sent upstream:
http://marc.info/?l=qemu-devel&m=124527065932608
Comment 27 Mark McLoughlin 2009-06-19 03:56:43 EDT
Anthony's response:

http://marc.info/?l=qemu-devel&m=124527707711710
Comment 28 Mark McLoughlin 2009-07-03 10:04:39 EDT
*** Bug 508671 has been marked as a duplicate of this bug. ***
Comment 29 Mark McLoughlin 2009-08-14 13:49:16 EDT
*** Bug 516692 has been marked as a duplicate of this bug. ***
Comment 30 Cole Robinson 2010-01-20 17:14:18 EST
A fix for this is now applied upstream:

http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=3baf720e6b920d583ce2834d05e5a4e9603a1d56

It's a pretty simple fix, would be nice to backport to F12 at least.
Comment 31 Fedora Admin XMLRPC Client 2010-03-09 11:54:12 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 32 Fedora Admin XMLRPC Client 2010-03-09 12:19:58 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 33 Justin M. Forbes 2010-03-11 13:15:49 EST
This has been added to the git tree, and will make the next package releases for F-12 and F-13.
Comment 34 Bug Zapper 2010-03-15 08:11:01 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 35 Fedora Update System 2010-03-16 00:09:43 EDT
qemu-0.12.3-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/qemu-0.12.3-2.fc12
Comment 36 Fedora Update System 2010-03-16 00:23:43 EDT
qemu-0.12.3-6.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/qemu-0.12.3-6.fc13
Comment 37 Fedora Update System 2010-03-16 19:14:47 EDT
qemu-0.12.3-2.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update qemu'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/qemu-0.12.3-2.fc12
Comment 38 Fedora Update System 2010-03-16 19:19:59 EDT
qemu-0.12.3-6.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 39 Fedora Update System 2010-04-26 08:16:50 EDT
qemu-0.12.3-4.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/qemu-0.12.3-4.fc12

Note You need to log in before you can comment on or make changes to this bug.