Bug 1030862

When the file ownership is manually changed to qemu.qemu, the installation proceeds over this step, but fails shortly after for similar reason (installation from network):

2013-11-15 10:06:07.667+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -name f19 -S -machine pc-i440fx-1.4,accel=kvm,usb=off -m 1024 -smp 1,sockets=1,cores=1,threads=1 -uuid 5c758563-c3b3-c44b-41bf-0523144fd411 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/f19.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-reboot -no-shutdown -kernel /var/lib/libvirt/boot/virtinst-vmlinuz.I2N_Im -initrd /var/lib/libvirt/boot/virtinst-initrd.img.sITcIE -append method=http://orion1.pdb.fsc.net/install/fedora/x86_64/19 -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/mnt/vm/f19.img,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:64:12:4b,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
char device redirected to /dev/pts/4 (label charserial0)
qemu: could not load kernel '/var/lib/libvirt/boot/virtinst-vmlinuz.I2N_Im': Permission denied
2013-11-15 10:06:08.931+0000: shutting down

This is actually worse than the original problem because the permissions can't be changed manually (files are downloaded, stored with wrong permissions, and deleted after qemu fails).

I tried to set /var/lib/libvirt/boot permissions to qemu.qemu, 02771, but qemu still fails, because the permissions on the downloaded files are extremely restrictive.

[root@cooper Backup]# ls -Zart /var/lib/libvirt/boot/
drwxr-xr-x. root root system_u:object_r:virt_var_lib_t:s0 ..
drwxrws--x. qemu qemu system_u:object_r:virt_content_t:s0 .
-rw-------. root root system_u:object_r:virt_content_t:s0 virtinst-vmlinuz.KMEEHT
-rw-------. root root system_u:object_r:virt_content_t:s0 virtinst-initrd.img.dOIUMI

I retried after update to latest F19 packages
Both problems still happen with 

libvirt-1.0.5.6-3.fc19.x86_64
virt-install-0.10.0-4.fc19.noarch

This is not a selinux problem, AFAICT.

# getsebool -a | grep virt
staff_use_svirt --> off
unprivuser_use_svirt --> off
virt_transition_userdomain --> off
virt_use_comm --> off
virt_use_execmem --> off
virt_use_fusefs --> off
virt_use_nfs --> off
virt_use_rawip --> off
virt_use_samba --> on
virt_use_sanlock --> off
virt_use_usb --> on
virt_use_xserver --> off

Martin, I'm not able to reproduce what you're seeing.  My steps were:

- start virt-manager
- create a new pool (/mnt/vms in my case)
- create a volume in the pool, vol0
- create a new VM
- select managed or existing storage and choose vol0

VM starts up, installs & runs ok

When you say "Run virt-install through virt-manager GUI, using the volume just created" do you mean you created the VM and booted it into the installer with virt-manager?

I meant the same thing you described. Sorry for having been imprecise.

But your comment made me suspicious... this was caused by my configuration. 

I had set dynamic_ownership = 0 in /etc/libvirt/qemu.conf because of 
bug #1012085. By setting dynamic_ownership back to 1, installation works again, both problems above are fixed.

Before you say this is a user error:

Without a fix for bug #1012085, installation from an ISO stored on CIFS storage requires dynamic_ownership = 0.

So, I'd need to toggle dynamic_ownership depending on whether or not I work with CIFS images.

Adding dependency to  bug #1012085. Once that is solved, this one can be solved by setting dynamic_ownership = 1 generally.

Dynamic ownership is (and should be the default) so I think this BZ can be closed as nothing needed here.  I asked Cole when we might see 1012085 released.