+++ This bug was initially created as a clone of Bug #473154 +++

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.

--- Additional comment from crobinso on 2008-12-01 16:50:13 EDT ---

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

--- Additional comment from rdoty on 2008-12-01 19:46:46 EDT ---

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?

--- Additional comment from crobinso on 2008-12-01 23:05:27 EDT ---

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.

--- Additional comment from rdoty on 2008-12-02 09:28:13 EDT ---

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.

--- Additional comment from crobinso on 2008-12-02 09:51:16 EDT ---

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).

--- Additional comment from rdoty on 2008-12-02 10:02:35 EDT ---

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?

--- Additional comment from crobinso on 2008-12-02 11:52:36 EDT ---

(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.

--- Additional comment from rdoty on 2008-12-02 13:17:18 EDT ---

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!)

--- Additional comment from jrfuller on 2008-12-31 14:55:55 EDT ---

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

--- Additional comment from ari.tilli on 2009-01-14 03:58:31 EDT ---

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 ;);)

--- Additional comment from crobinso on 2009-04-04 18:09:37 EDT ---

*** Bug 494044 has been marked as a duplicate of this bug. ***

--- Additional comment from crobinso on 2009-04-04 18:10:23 EDT ---

*** Bug 490206 has been marked as a duplicate of this bug. ***

--- Additional comment from markmc on 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?

--- Additional comment from michael.monreal on 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?

--- Additional comment from crobinso on 2009-04-06 21:10:11 EDT ---

Created an attachment (id=338421)
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.

--- Additional comment from markmc on 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.

--- Additional comment from crobinso on 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.

--- Additional comment from fedora-admin-xmlrpc on 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.

--- Additional comment from fedora-admin-xmlrpc on 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.

--- Additional comment from fedora-admin-xmlrpc on 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.

--- Additional comment from fedora-admin-xmlrpc on 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.

--- Additional comment from markmc on 2009-06-03 09:40:11 EDT ---

Cole: still planning to send this upstream?

--- Additional comment from crobinso on 2009-06-03 15:51:15 EDT ---

Ahh, yeah I forgot,s orry. I'll do that soon.

--- Additional comment from fedora-triage-list on 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

--- Additional comment from daahern on 2009-06-10 11:44:10 EDT ---

Can Cole's patch get applied to the KVM tree used for RHEL5.4?