See also https://fedoraproject.org/wiki/Reporting virtualization bugs

What versions of python-virtinst, libvirt and qemu-system-x86?

Please attach ~/.virt-manager/virt-manager.log and /var/log/libvirt/qemu/$guest.log

Just FYI, I got a similar error when I tried to install a VM with 2048MB of RAM on a 32-bit machine. There was an error message in the log file that only 2047MB are supported (which didn't make it through to the GUI). After adjusting the RAM size to that, it worked.

Created attachment 350375 [details]
~/.virt-manager/virt-manager.log

I get the error even when I use the default settings of 512 MB RAM and one CPU.

$ rpm -q python-virtinst libvirt qemu-system-x86
python-virtinst-0.400.3-8.fc11.noarch
libvirt-0.6.2-12.fc11.x86_64
qemu-system-x86-0.10.5-3.fc11.x86_64

Created attachment 350376 [details]
/home/braden/bolt-vista-x64.log

libvir: Security Labeling error : SELinuxSetFilecon: unable to set security context 'system_u:object_r:virt_content_t:s0' on /share/en_windows_vista_sp2_x64_dvd_342267.iso: Operation not supported.
libvir: QEMU error : internal error Failed to set security label

Braden: could you try with libvirt-0.6.2-13.fc11 from updates-testing? It looks like this is a dup of bug #507555

Using libvirt-0.6.2-13.fc11 doesn't appear to change anything.

I'll attach updated log files.

Created attachment 355638 [details]
~/.virt-manager/virt-manager.log using libvirt-0.6.2-13.fc11

Created attachment 355639 [details]
/var/log/libvirt/qemu/bolt-vista-x64.log using libvirt-0.6.2-13.fc11

libvir: Security Labeling error : SELinuxSetFilecon: unable to set security context 'system_u:object_r:virt_content_t:s0' on /share/en_windows_vista_sp2_x64_dvd_342267.iso: No such file or directory.
libvir: QEMU error : internal error Failed to set security label

Okay, the problem here seems to be that you've deleted the iso which is still referenced in the XML configuration for the guest. You can fix that by using the 'Disconnect' button in virt-manager's Details->disk hdc

We should fix libvirt not to fail in this case because we're also going to fix qemu to not fail in this case - see bug #473154

I don't see why we should ignore this error - it is a clearly broken configuration. Ignoring the failure to relabel a disk because the operation is not supported is reasonable. Ignoring an error due to the file path not even existing is just going to silently hide problems from users.

bug 473154 is a different problem to the one reported here. The reason /dev/sr0 opening failed is because that was a physical CDROM device with no media present - the path itself still exists. In this bug the report is about a path to an ISO image, not a CDROM device.

Okay, looks like you're right about bug #473154 - even with Cole's patch, qemu will still fail if the ISO has been deleted

Bear in mind, though, that we leave the cdrom connected to the ISO for window's installs and users will fairly naturally just delete the ISO at some point after the install has finished.

No, I have not deleted the iso.  It is still there as I type this.  Unless the process of creating the virtual machine removes and replaces that file, that error message is inaccurate.

Now, /share is an NFS mount.  Could that be the problem?

And Mark, as stated in the original description of this bug, this is happening during virtual machine creation. There is thus no opportunity to disconnect the iso.

(In reply to comment #9)
> libvir: Security Labeling error : SELinuxSetFilecon: unable to set security
> context 'system_u:object_r:virt_content_t:s0' on
> /share/en_windows_vista_sp2_x64_dvd_342267.iso: No such file or directory.

It's the "No such file or directory" that lead me to believe the ISO had been deleted. But, as I discovered in bug #515547, this error message is bogus

(In reply to comment #12)

> Now, /share is an NFS mount.  Could that be the problem?

Yep, that's the problem.

In order to use ISOs on an NFS mount for installing guests, you need to mount it using the virt_content_t label e.g.

  $> mount -o context="system_u:object_r:virt_content_t:s0" ....

Hopefully that sorts it out for you, sorry it took so long to diagnose

I've updated:

  https://fedoraproject.org/wiki/Reporting_virtualization_bugs#SELinux

Thanks

Actually, the alternative to mounting it with a specific context is to set the 'virt_use_nfs' sebool:

  $> sebool virt_use_nfs on

However, libvirt currently has a bug that prevents the from working. See bug #517157

*** This bug has been marked as a duplicate of bug 517157 ***

Reopening.  libvirt-0.7.1 doesn't appear to fix this problem.  The error message has changed a bit, though:


Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: bind(unix:/var/lib/libvirt/qemu/bolt-vista-x64.monitor): Permission denied
qemu: could not open monitor device 'unix:/var/lib/libvirt/qemu/bolt-vista-x64.monitor,server,nowait'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 1489, in do_install
    dom = guest.start_install(False, meter = meter)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 628, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 726, in _do_install
    self.domain = self.conn.createLinux(install_xml, 0)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1077, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error unable to start guest: bind(unix:/var/lib/libvirt/qemu/bolt-vista-x64.monitor): Permission denied
qemu: could not open monitor device 'unix:/var/lib/libvirt/qemu/bolt-vista-x64.monitor,server,nowait'

'

Thanks for trying

That's a different issue to the NFS issue, so I'm going to close it again

The "could not open monitor device" issue was fixed by an selinux-policy update AFAIR. Please open a new bug if it persists

*** This bug has been marked as a duplicate of bug 517157 ***