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
# 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:
-CD-ROM or DVD
-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.
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.:
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.
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
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 184.108.40.206-27.rc1.fc10.i686
Steps to Reproduce:
New VM - Default/ WinXP/4G HDD/512RAM/1CPU
OK -> Error: SELinux blocks the VM from being created
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.
-SELinux should not block the action of creating a VM
-CD-ROM should be statically set to the machine. This is still a bug.
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.
You are correct. I am trying to create a windows VM.
The file you specified does not exist in my user's home directory.
My mistake, it was in /root/.virt-manager/virt-manager.log
Created attachment 321328 [details]
Created attachment 321329 [details]
As well, here is an export of the SELinux alerts, if it can be helpful.
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.
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
-Select "CD-ROM or DVD - Path to install media" (This is greyed out)
The latter will be most users first intuition.
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.