This means if you are connecting to qemu:///system as a regular user (like via default virt-manager usage), you need to enter the host root password, which is annoying and not generally desktop usecase friendly. With qemu:///system, libvirtd runs as root, and app access to libvirtd is mediated by polkit. The easiest way to understand the benefit of one over the other is to list the problems with each setup. The privilege level of libvirtd and VMs have pros and cons depending on your usecase. That describes the 'what', but the 'why' is a bigger story. gnome-boxes and libguestfs use this by default. This means each user has their own qemu:///session VMs, separate from all other users. All config and logs and disk images are stored in $HOME. qemu:///session: Connects to a session libvirtd instance running as the app user, the daemon is auto-launched if it's not already running.virt-manager and big management apps like Openstack and oVirt use this by default. Daemon config is in /etc/libvirt, VM logs and other bits are stored in /var/lib/libvirt. ![]() qemu VMs are launched as the unprivileged 'qemu' user, though libvirtd can grant the VM selective access to root owned resources. ![]() libvirtd is running as root, so has access to all host resources.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |