Bug 464829 - Virtual Machine CD-ROM disappears on its own - kvm virt-manager
Summary: Virtual Machine CD-ROM disappears on its own - kvm virt-manager
Alias: None
Product: Fedora
Classification: Fedora
Component: python-virtinst
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
URL: https://bugs.launchpad.net/ubuntu/+so...
Depends On:
TreeView+ depends on / blocked
Reported: 2008-09-30 18:20 UTC by David Bensimon
Modified: 2008-10-27 17:47 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2008-10-14 19:52:57 UTC

Attachments (Terms of Use)
virt-manager log (121.40 KB, application/octet-stream)
2008-10-23 18:58 UTC, David Bensimon
no flags Details
SELinux log (11.98 KB, text/plain)
2008-10-23 19:02 UTC, David Bensimon
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 238692 None None None Never

Description David Bensimon 2008-09-30 18:20:56 UTC
Bug originally reported on launchpad against virt manager 0.5.3:

I have tested the following on Ubuntu 8.04. I am using kvm and virt-manager. I beleive this bug to be related to the libvirt-manager package. What happens is that virt-manager disconnects the CD-ROM without user intervention and does not allow the user to reconnected through the virt-manager GUI.

Steps to reproduce:
$ sudo apt-get install kvm libvirt-bin ubuntu-vm-builder virt-manager
$ sudo adduser ubuntu kvm
# reboot
$ virt-manager
# double click on the localhost (User) to make status "Active"
# new (button)
# create a new VM using an XP CD
# after first reboot, installer asks for CD, CD disappears from VM device list


When creating a virtual machine you get the following options:

-Network PXE Boot

On a VM with no CD-ROM these are the options you get when attempting to add a device:

-Normal Disk Partition (Grayed Out)
-Simple File (Works fine for ISO/Image but not for physical CD drive device)
-Device Type (Selected CD-ROM)

I would recommend that the CD-ROM or DVD option be the same in "Creating a VM" and "Add Device" so that a physical CD-ROM can be bound to a VM in a few clicks. Can the developers please try to find out why the CD drive is there (bound from host to guest) when the machine is created, but disapears after a reboot of the VM.

Comment 1 Cole Robinson 2008-09-30 18:43:57 UTC
What version of virtinst are you using? This is where the issue will be.

Originally we would keep the CDROM device attached to the guest after install, but remove the _media_. That should be what's happening to you, but I could be wrong.

This has been fixed upstream and in virtinst-0.400.0 if you specify you are installing a windows VM, since it needs the install media to remain inserted for the second stage of the install.

The commit is here, if you guys want to pull it in.:


Comment 2 Cole Robinson 2008-10-14 19:52:57 UTC
Hmm, as stated the fix is upstream. If you are using ubuntu, file this bug with them, and provide the link to the upstream commit I gave in Comment #1. You'll want to file it against whatever package virt-install is a part of.

Closing as UPSTREAM. Thanks for the report. Please reopen if I got it wrong.

Comment 3 David Bensimon 2008-10-21 15:51:57 UTC
I attempted to get the latest copy of the code on the development version of Fedora. I believe that I am running virtinst >0.400.0 but I am not sure how to check this. When testing, I run into an error creating a VM. I have added the versions of the packages in the new bug. 

Cannot create virtual machine in virt-manager 0.6.0-2

Comment 4 David Bensimon 2008-10-21 21:44:38 UTC
I am still experiencing the disappearance of the CD-ROM after a reboot, even after testing in Rawhide. As well SELinux blocks the creation of a VM.

Description of problem:

I have reported a few bugs over the use of virt-manager.

1) Bug 464829 -  Virtual Machine CD-ROM disappears on its own - kvm virt-manager
Solution: Upgrade to virtinst-0.400.0

2)  Bug 467896 -  Cannot create virtual machine in virt-manager 0.6.0-2
Solution: Upgrade to python-virtinst-0.400.0-3.fc10

Now I am experiencing an issue where SELinux is not allowing me to create a VM unless it is turned off.

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

Fedora release 9.92 (Rawhide)
Linux Kernel


Steps to Reproduce:
$ virt-manager
(Enter Password)
New VM - Default/ WinXP/4G HDD/512RAM/1CPU
OK -> Error: SELinux blocks the VM from being created
Actual results:

SELinux interrupts the creation of the VM. Turning off the SELinux enforcement by running the following command:

# setenforce Permissive

Afterwards, the installation of XP from the CD-ROM works until the second portion of the installation where the CD-ROM disconnected itself and is no longer able to reconnect.

Expected results:

-SELinux should not block the action of creating a VM

-CD-ROM should be statically set to the machine. This is still a bug.

Comment 5 Cole Robinson 2008-10-23 16:54:56 UTC
Definitely sure you specified you are installing a windows VM? Otherwise the media won't remain attached.

If so, can you attach ~/.virt-manager/virt-manager.log? Thanks.

Comment 6 David Bensimon 2008-10-23 18:49:20 UTC
You are correct. I am trying to create a windows VM.

The file you specified does not exist in my user's home directory.

Comment 7 David Bensimon 2008-10-23 18:57:33 UTC
My mistake, it was in /root/.virt-manager/virt-manager.log

Comment 8 David Bensimon 2008-10-23 18:58:28 UTC
Created attachment 321328 [details]
virt-manager log

Comment 9 David Bensimon 2008-10-23 19:02:38 UTC
Created attachment 321329 [details]
SELinux log

As well, here is an export of the SELinux alerts, if it can be helpful.

Comment 10 Cole Robinson 2008-10-23 19:10:53 UTC
Hmm, according to the log, you had a VM named 'xxxxppppp' which was specified as windows, and appeared to keep the media around after reboot. (Bug fixed)

Later you created a guest called 'expeefromceedee' which _wasn't_ specified as windows (OS type was left as 'Generic') so the media wasn't kept connected after the first reboot, which is expected behavior. Granted there could be a bug between here and there but to me it looks like the issue was fixed.

Could you try again and make sure a windows OS is specified in the 'Choose Install Method' screen? If that doesn't work, please post the log after that attempt. Thanks.

Comment 11 David Bensimon 2008-10-23 20:36:55 UTC
OK, you are correct, I selected Windows and it didn't disconnect the drive in the second part of the install. Although after the first part, I tried to start the machine again and got the following error:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 532, in run_domain
  File "/usr/share/virt-manager/virtManager/domain.py", line 380, in startup
  File "/usr/lib/python2.5/site-packages/libvirt.py", line 262, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error Timed out while reading monitor startup output

Then I tried again and, as you said, it seems to work. The second portion of the Windows install works.

I did not realize that if I did not select Windows as the OS, the CD would be disconnected (intentionally) when the machine shuts down. Why is this intentional behaviour? Seeing as we are virtualizing a machine, I don't know many machines where the CD ROM drive just disconnects itself after turning the machine off. 

Although this is the case, it possible to manually reconnect the CD afterwards although it is not very user friendly. 

Reconnect - Works
-Remove Device Disk hdc
-Create a new storage device (IDE CDROM) and point it to /dev/sr0 

Reconnect - Does not work
-Go to hardware tab
-Click "Connect"
-Select "CD-ROM or DVD - Path to install media" (This is greyed out)

The latter will be most users first intuition.

Comment 12 Cole Robinson 2008-10-27 17:47:33 UTC
Cool, so this issue is fixed. That 'timed out' issue is a separate bug that is currently reported, though we haven't determined what is causing it yet. See bug 453491.

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