![]() Basically the host admin sets up a bridge, adds it to a whitelist at /etc/qemu/nf, then it's available for unprivileged qemu instances. There is an option for qemu:///session VMs to use a privileged networking setup, via the setuid qemu-bridge-helper. This has many drawbacks: the VM can not easily be accessed by the outside world, the VM can talk to the outside world but only over a limited number of networking protocols, and it's very slow. This is an IP stack implemented in userspace. The default qemu network mode when running unprivleged is usermode networking (or SLIRP). Unfortunately this includes most general purpose networking options. However because nothing in the chain is privileged, any VM setup tasks that need host admin privileges aren't an option. This integrates better with desktop use cases since permissions aren't an issue, no root password is required, and each user has their own separate pool of VMs. With qemu:///session, libvirtd and VMs run as your unprivileged user. (Though try giving a VM access to a file on a fat32 USB drive that was automounted by your desktop session.) qemu:///session It's a pain for apps to handle, and it's confusing for users, but after dealing with it for a while in virt-manager we've made it generally work. The VM is running as unprivileged user qemu and can't access your $HOME, so libvirt has to change the ISO file owner to qemu:qemu and virt-manager has to give search access to $HOME for user qemu. For example, say you download an ISO to $HOME and want to attach it to a VM. There are ways to work around it but it requires explicit admin configuration.ĭesktop use cases also suffer as VMs are run as the qemu user, but the app (like virt-manager) is running as your local user. 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. qemu:///system: Connects to the system libvirtd instance, the one launched by systemd.The URI is how users or apps tell libvirt what hypervisor (qemu, xen, lxc, etc) to connect to, what host it's on, what authentication method to use, and a few other bits.įor QEMU/KVM (and a few other hypervisors), there's a concept of system URI vs session URI: If you've spent time using libvirt apps like virt-manager, you've likely seen references to libvirt URIs. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |