Description of problem: Configure libvirtd.conf to use the 'libvirt' group for its socket: unix_sock_group = "libvirt" and add your unprivileged user to it. Then either export LIBVIRT_DEFAULT_URI="qemu:///system" or just pass -c qemu:///system to all commands. This works perfectly fine with at least virsh and virt-manager, and even virt-install (and qemu) actually works perfectly fine, just throws these warnings: $ echo bar > /tmp/foo $ virt-install --name testvm --memory 2048 --disk size=20 --install fedora32 --unattended profile=jeos,admin-password-file=/tmp/foo --noautoconsole Using fedora32 --location https://download.fedoraproject.org/pub/fedora/linux/releases/32/Server/x86_64/os (process:52767): dconf-CRITICAL **: 16:15:07.433: unable to create file '/home/user/.cache/dconf/user': Permission denied. dconf will not work properly. (process:52767): dconf-CRITICAL **: 16:15:07.434: unable to create file '/home/user/.cache/dconf/user': Permission denied. dconf will not work properly. (process:52767): dconf-CRITICAL **: 16:15:07.434: unable to create file '/home/user/.cache/dconf/user': Permission denied. dconf will not work properly. (process:52767): dconf-CRITICAL **: 16:15:07.434: unable to create file '/home/user/.cache/dconf/user': Permission denied. dconf will not work properly. (process:52767): dconf-CRITICAL **: 16:15:07.434: unable to create file '/home/user/.cache/dconf/user': Permission denied. dconf will not work properly. (process:52767): dconf-CRITICAL **: 16:15:07.435: unable to create file '/home/user/.cache/dconf/user': Permission denied. dconf will not work properly. (process:52767): dconf-CRITICAL **: 16:15:07.435: unable to create file '/home/user/.cache/dconf/user': Permission denied. dconf will not work properly. (process:52767): dconf-CRITICAL **: 16:15:07.435: unable to create file '/home/user/.cache/dconf/user': Permission denied. dconf will not work properly. (process:52767): dconf-CRITICAL **: 16:15:07.435: unable to create file '/home/user/.cache/dconf/user': Permission denied. dconf will not work properly. (process:52767): dconf-CRITICAL **: 16:15:07.435: unable to create file '/home/user/.cache/dconf/user': Permission denied. dconf will not work properly. WARNING /home/user/.cache/virt-manager/boot may not be accessible by the hypervisor. You will need to grant the 'qemu' user search permissions for the following directories: ['/home/user', '/home/user/.cache'] Starting install... Retrieving file vmlinuz... | 10 MB 00:01 Retrieving file initrd.img... | 74 MB 00:12 Allocating 'virtinst-dxdhin04-vmlinuz' | 10 MB 00:00 Transferring virtinst-dxdhin04-vmlinuz | 10 MB 00:00 Allocating 'virtinst-lbh9b4iq-initrd.img' | 74 MB 00:00 Transferring virtinst-lbh9b4iq-initrd.img | 74 MB 00:01 Allocating 'testvm.qcow2' | 20 GB 00:00 Domain installation still in progress. You can reconnect to the console to complete the installation process. Everything gets created on the system-level properly (using qemu:///system) and ~/.local/share/libvirt is not even created. Version-Release number of selected component (if applicable): virt-install-2.2.1-3.fc32.noarch Additional info: $ groups user lp wheel cdrom dialout kvm video libvirt i2c-approved input
Thanks for the report. virt-install itself doesn't do anything with dconf/gsettings so I don't think it's related to virt-install code directly. Even using qemu:///system, it's only authorizing the connection to system libvirtd, which shouldn't be touching your homedir at all So I'm confused Can you provide ls -l ~/.config/dconf/user* If those permissions don't belong to your user, can you reset them 'chmod 644' and see if re-running virt-install reproduces the errors?
Right, that's correct - it wasn't somehow owned by my user. I guess I must have run something (virt-install?) as root with sudo env_keep+="HOME" while not having ~/.cache/dconf created and that got created with root:root. And I misinterpreted the Permission denied as the 'qemu' user trying to access my home. Removing ~/.cache/dconf and running virt-install as my user got rid of the dconf warnings and ~/.cache/dconf is now owned by me. However one warning remains: WARNING /home/user/.cache/virt-manager/boot may not be accessible by the hypervisor. You will need to grant the 'qemu' user search permissions for the following directories: ['/home/user', '/home/user/.cache'] $ ls -ld .cache/ .cache/virt-manager/ .cache/virt-manager/* drwx------. 1 user user 530 Aug 31 20:34 .cache// drwxr-x--x. 1 user user 100 Aug 30 01:27 .cache/virt-manager// drwxr-x--x. 1 user user 0 Aug 31 20:35 .cache/virt-manager/boot/ drwxr-xr-x. 1 user user 72 Aug 30 01:27 .cache/virt-manager/qemu:___system/ -rw-r--r--. 1 user user 561001 Aug 31 20:35 .cache/virt-manager/virt-install.log -rw-r--r--. 1 user user 59416 Aug 30 16:11 .cache/virt-manager/virt-manager.log This message does seem to come from virt-install's check_path_search. A qemu:///system spawned qemu process has presumably no business getting into my home, so the warning doesn't make much sense. Thanks.
Thanks for the info. Can you provide full virt-install --debug output when reproducing? You're right that may be a bug warning about that directory.
Created attachment 1713256 [details] virt-install --debug log Sure, attached.
It seems that the issue is some code guessing the kernel+initrd download dir to be in my home, DEBUG (urlfetcher:104) Using scratchdir=/home/user/.cache/virt-manager/boot whereas dumpxml on the still-installing domain shows it as under /var/lib: <os> <type arch='x86_64' machine='pc-q35-4.2'>hvm</type> <kernel>/var/lib/libvirt/boot/virtinst-2fr_qjyi-vmlinuz</kernel> <initrd>/var/lib/libvirt/boot/virtinst-ads3i38i-initrd.img</initrd> <cmdline>ks=file:/fedora.ks inst.repo=https://download.fedoraproject.org/pub/fedora/linux/releases/32/Server/x86_64/os</cmdline> <boot dev='hd'/> </os> (as it should be for qemu:///system)
Thanks. Something is wrong there I think but I'll need to dig into it
This is fixed as part of: commit 5473695fe1c0964c7a2e90cb910e83b0fc91f80b Author: Cole Robinson <crobinso> Date: Tue Sep 8 18:41:41 2020 -0400 installer: Upload unattended and cloudinit data to remote connections
FEDORA-2020-656e86b662 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-656e86b662
FEDORA-2020-656e86b662 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-656e86b662` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-656e86b662 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-c30055ffe4 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-c30055ffe4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c30055ffe4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-c30055ffe4 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.