Description of problem: Created volume in storage pool with virt-manager Run virt-install through virt-manager GUI, using the volume just created Version-Release number of selected component (if applicable): 1.0.5.6-2.fc19 How reproducible: always Steps to Reproduce: 1. Created volume in storage pool with virt-manager 2. Run virt-install through virt-manager GUI, using the volume just created 3. Actual results: libvirt log: Unable to complete install: 'Unable to read from monitor: Connection reset by peer' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 100, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/create.py", line 1920, in do_install guest.start_install(False, meter=meter) File "/usr/share/virt-manager/virtinst/Guest.py", line 1134, in start_install noboot) File "/usr/share/virt-manager/virtinst/Guest.py", line 1202, in _create_guest dom = self.conn.createLinux(start_xml or final_xml, 0) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2782, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: Unable to read from monitor: Connection reset by peer qemu log: 2013-11-15 09:41:38.812+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 bcae9d97-faed-394f-7c9c-5752b7bfce6d -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.OG2S6B -initrd /var/lib/libvirt/boot/virtinst-initrd.img.emfZMB -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/3 (label charserial0) qemu-system-x86_64: -drive file=/mnt/vm/f19.img,if=none,id=drive-virtio-disk0,format=qcow2: could not open disk image /mnt/vm/f19.img: Permission denied 2013-11-15 09:41:39.347+0000: shutting down The new storage file (f19.img) is created with user/group root, not qemu: $ ls -Z /mnt/vm/ -rw-------. root root system_u:object_r:svirt_image_t:s0:c810,c834 f19.img drwx------. root root system_u:object_r:file_t:s0 lost+found -rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 now9c.qcow2 -rw-r--r--. qemu qemu system_u:object_r:svirt_image_t:s0:c448,c837 now9.qcow2 $ getfacl -a /mnt/vm/f19.img getfacl: Removing leading '/' from absolute path names # file: mnt/vm/f19.img # owner: root # group: root user::rw- group::--- other::--- Expected results: Created image should be owned by qemu.qemu, or should be chowned by virt-install before starting qemu. Additional info:
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.