Bug 473154
| Summary: | Virtual machine fails to start without cdom - qemu: could not open disk image /dev/sr0 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Russell Doty <rdoty> | ||||
| Component: | qemu | Assignee: | Justin M. Forbes <jforbes> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 13 | CC: | ari.tilli, berrange, bugzilla, crobinso, daahern, dwmw2, ehabkost, gcosta, hbrock, jrfuller, markmc, michael.monreal, pbrobinson, timothy.mcconnell, vedran, virt-maint | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| 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 23:20:09 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 480594 | ||||||
| Attachments: |
|
||||||
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 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? 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. 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. 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). 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? (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. 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!) 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 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 ;);) *** Bug 494044 has been marked as a duplicate of this bug. *** *** Bug 490206 has been marked as a duplicate of this bug. *** 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?
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?
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.
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. 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. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Cole: still planning to send this upstream? Ahh, yeah I forgot,s orry. I'll do that soon. 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 Can Cole's patch get applied to the KVM tree used for RHEL5.4? New version of the fix sent upstream: http://marc.info/?l=qemu-devel&m=124527065932608 Anthony's response: http://marc.info/?l=qemu-devel&m=124527707711710 *** Bug 508671 has been marked as a duplicate of this bug. *** *** Bug 516692 has been marked as a duplicate of this bug. *** 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. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This has been added to the git tree, and will make the next package releases for F-12 and F-13. 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 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 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 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 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. 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 |
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.