## Description of problem: With the correct polkit rule, a user can manage the system mode daemon with qemu:///system. In such configuration, virt-install fails to complete because the qemu process cannot access the kernel image. ---- Aug 11 00:01:14 kvm13.lab.local libvirtd[27929]: 2017-08-10 22:01:14.583+0000: 27931: error : qemuProcessReportLogError:1862 : internal error: process exited while connecting to monitor: qemu: could not load kernel '/var/lib/libvirt/boot/virtinst-vmlinuz.ruXFEj': Permission denied ---- When using the qemu:///system URI, virt-install saves the kernel into the system scratchdir /var/lib/libvirt/boot/ : ---- [Fri, 11 Aug 2017 00:01:13 virt-install 3287] DEBUG (urlfetcher:90) Fetching URI: http://host.lab.local/pub/rhel/7.3/os/x86_64/images/pxeboot/vmlinuz Retrieving file vmlinuz... | 5.1 MB 00:00:00 [Fri, 11 Aug 2017 00:01:13 virt-install 3287] DEBUG (urlfetcher:166) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.ruXFEj ---- If the user for QEMU processes run by the system instances is not the current user, nor root, the installation fails because this user cannot read the kernel file. The file owner is the user who executes the virt-install command: ---- # ls -l /var/lib/libvirt/boot/ total 48924 -rw------- 1 bruno support 44701632 Aug 11 00:01 virtinst-initrd.img.1FF624 -rw------- 1 bruno support 5391264 Aug 11 00:01 virtinst-vmlinuz.ruXFEj ---- The mode is set to 0600 by tempfile.NamedTemporaryFile(), thus the qemu process cannot read the files. ## Version-Release number of selected component (if applicable): virt-manager-common-1.4.1-7.el7.noarch libvirt-3.2.0-14.el7_4.2.x86_64 $ cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.4 (Maipo) ## How reproducible: Easily ## Steps to Reproduce: 1. Configure polkit # cat /etc/polkit-1/rules.d/48-org.libvirt.unix.manager.rules /* Allow users in support group to manage the libvirt daemon without authentication */ polkit.addRule(function(action, subject) { if (action.id == "org.libvirt.unix.manage" && subject.isInGroup("support")) { return polkit.Result.YES; } }); 2. If needed, change the group and mode of /var/lib/libvirt/images and /var/lib/libvirt/boot # chgrp support /var/lib/libvirt/{boot,images} # chmod 731 /var/lib/libvirt/{boot,images} 3. As a user, start virt-install (must be member of group support) $ id uid=1182(bruno) gid=1000(support) groups=1000(support) $ /usr/bin/python2 /usr/share/virt-manager/virt-install --connect qemu:///system --name demo2 --ram 4096 --vcpus 2 --virt-type kvm --machine pc --location http://host.lab.local/pub/rhel/7.3/os/x86_64/ --arch x86_64 --os-variant rhel7.0 --disk path=/var/lib/libvirt/images/demo2-disk0,size=10,format=qcow2 --wait 0 --debug ## Actual results: The installation of the virtual guest fails. ## Expected results: The installation of the virtual guest completes. ## Additional info: I have been able to workaround this issue with the following patch in urlfetcher: ---- diff -u /usr/share/virt-manager/virtinst/urlfetcher.py.ori /usr/share/virt-manager/virtinst/urlfetcher.py --- /usr/share/virt-manager/virtinst/urlfetcher.py.ori 2017-03-08 22:55:43.000000000 +0100 +++ /usr/share/virt-manager/virtinst/urlfetcher.py 2017-08-11 00:21:21.705304598 +0200 @@ -160,6 +160,7 @@ fileobj = tempfile.NamedTemporaryFile( dir=self.scratchdir, prefix=prefix, delete=False) fn = fileobj.name + os.chmod(fn, 0640) self._grabURL(filename, fileobj) logging.debug("Saved file to " + fn) ----
Thanks for the report. Default libvirtd running as root should be chowning that file to qemu:qemu. Do you have dynamic_ownership turned off in qemu.conf ?
Indeed dynamic_ownership is disabled in qemu.conf.
I also have group = "support".
Thanks for the info. Unfortunately since those are non-standard settings that can cause issues in a variety of ways, virt-install can't support that in all cases. I suggest you continue to use your patch as a local workaround