Can you attach /var/log/libvirt/qemu/{VMNAME}.log? Thanks.

Created attachment 335848 [details]
First log

Not sure, which log is the right one. Sending all (4) from today's probes.

Created attachment 335849 [details]
Second log

Created attachment 335851 [details]
Third log

Created attachment 335852 [details]
fourth log

What libvirt version have you got

libvirt-0.6.1-5.fc11.x86_64

I had the same problem (same message).
setenforce 0 seems to solve it.
I've not time to understand exactly what is going on, but I was using an image not in /var/lib/libvirt/
Michal try to build a virtual machine with NEW storage in the default path, and don't use ISOs but use a cd (for testing). You shouldn't get the error anymore.
If it is so it's not a bug (but there should be a warning *inside* virt-manager about selinux and paths).

As Stefano said. `setenforce 0' does the job for that moment, now I am able to get VM connected to PXE, e.g.


Start wizard with setenforce 1` -> hit "Finish" got error from comment #0. Set setenforce 0 -> hit "Finish" you get this

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 272, in show_details
    details = vmmDetails(self.get_config(), con.get_vm(uuid), self)
  File "/usr/share/virt-manager/virtManager/details.py", line 337, in __init__
    self.update_widget_states(self.vm, self.vm.status())
  File "/usr/share/virt-manager/virtManager/details.py", line 783, in update_widget_states
    self.set_migrate_menu()
  File "/usr/share/virt-manager/virtManager/details.py", line 730, in set_migrate_menu
    self.engine.populate_migrate_menu(menu, self.control_vm_migrate)
  File "/usr/share/virt-manager/virtManager/engine.py", line 578, in populate_migrate_menu
    conns = self.get_available_migrate_hostnames()
  File "/usr/share/virt-manager/virtManager/engine.py", line 601, in get_available_migrate_hostnames
    driver = self.windowManager.current_connection().get_driver()
AttributeError: 'NoneType' object has no attribute 'get_driver'

But the VM is running quite fine in background.

I am also reproducing this 100% of the time trying to install an F10 ISO guest into a current rawhide host.  Will look into it more this evening

The traceback in comment #9 is a virt-manager bug, which I'll be fixing shortly.

The first two log files posted (Comment #2 and Comment #3) were hitting issues with qemu, pulseaudio, selinux, and libvirt. This is worked around in libvirt 0.6.1-5, unfortunately at the expense of having sound for your selinux protected VMs.

The log files in Comment #3 and Comment #4 are hitting selinux issues wrt booting off URLs. If running as a regular user, we currently don't have a selinux approved place to put fetched kernels. This wasn't a problem for most people in the past since we used ConsoleHelper to auth the whole app as root, allowing the user to put kernels into /var/lib/libvirt/boot. This won't fly anymore since we are solely using PolicyKit. We _need_ to get this working in some capacity before devel freeze though.

Comment #10 / jforbes, that is a similar (and long time known) selinux issue. My guess is the ISO is in your home directory or some other not deliberately allowed place. As a temporary workaround, you can move the iso to /var/lib/libvirt/images, then run

restorecon /var/lib/libvirt/images/your-iso.iso

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

The NoneType traceback should be fixed in virt-manager-0.7.0-2.

Okay, so to summarise:

  - virt-manager no longer runs as root

  - kernel/initrd images are downloaded to ~/.virtinst/boot

  - they are labelled as user_home_t rather than virt_image_t

  - qemu cannot access them

dwalsh: any ideas?

Adding to F11VirtBlocker

Best option I think is to add a dbus service to virt-manager to allow it to do some things with privs.  So it could download these images and place them in /var/lib/libvirt/images.

We could set the label on ~/.virtinst to svirt_image_t and allow svirt to search the users homedir.

Currently homedir labeling for virt is setup like the following

HOME_DIR/VirtualMachines(/.*)? 	gen_context(system_u:object_r:virt_image_t,s0)
HOME_DIR/VirtualMachines/isos(/.*)? 	gen_context(system_u:object_r:virt_content_t,s0)
HOME_DIR/.virtinst(/.*)? 	gen_context(system_u:object_r:virt_content_t,s0)

virt-manager should probably run restorecon when it creates these directories to make sure they get labeled correctly.

Labeling and svirt perms are in 

selinux-policy-3.6.10-2.fc11

We might want to include instructions for setting labelling for virt somewhere on the virt wiki page as I am sure there are users who will want to place their virt images somewhere else.

Created attachment 336636 [details]
This patch will allows virt-manager.py to set the context on a file when it does an install

This patch does two things,  It sets the context on the iso image to something that svirt processes can read even if they are in the users home directory or in /tmp.

It also fixes the context on the ~/.virtinst directory.  The correct patch might have been to only run the restorecon on creation of the .virtinst dir, but if we want to cleanup, this patch will allways fix the context.

This looks like a reasonable patch to me. Only change I'd make is to wrap the first  selinux call in a try / except block, so virt-manager doesn't have a hard dep on selinux modules.

After playing with this some more, I've decided this is better done in virtinst, so changing the patches a little.

Created attachment 338088 [details]
Fix context for kernel/initrd images

This patch ensures that $HOME/.virtinst/boot is setup with the correct SELinux context before downloading any initrd/kernel images.

This fix is being built into

 python-virtinst-0.400.3-3.fc11


Since this bug is just reporting problems with kernel/initrd installs, I will deal with CDROM / ISO patches in the separate bug 473154

Assuming this was actually fixed by the patch and closing

Please re-open if issues remain