9p (libvirt/QEMU) share modes

Can anybody explain what share modes - default, mapped, passthough, squashed - mean in libvirt/QEMU configuration?

enter image description here

I've got this share in passthrough mode. I see that inside VM it is owned by vagrant:vagrant user (which is absent from host machine) and share has rw bits set. But trying to create files there gives access denied error.

I need to understand what is going on to resolve the issue.


Solution 1:

Share modes define how the virtualised (p9fs) file system is presented to the guest machine. There are important implications for permission mapping. To understand this, it's important to remember that the virtualised file system needs to manage permissions of files and they may not be the same in the host as they are in the guest.

The best docs I have found regarding the modes is from the libvirt docs:

The filesystem block has an optional attribute accessmode which specifies the security mode for accessing the source (since 0.8.5). Currently this only works with type='mount' for the QEMU/KVM driver. The possible values are:

  • passthrough The source is accessed with the permissions of the user inside the guest. This is the default accessmode if one is not specified. More info. Beware that changes to permissions/ownership will affect all guests using that filesystem. This mode is generally quite fast.
  • mapped The source is accessed with the permissions of the hypervisor (QEMU process). More info. This means you need to make sure that files on the hypervisor are accessible to the QEMU process (username libvirt-qemu on my setup). The advantage is that file attributes and permissions are "mapped" for the guest so that they are independent changes elsewhere (as long as the files stay accessible). If your host system supports ACLs, this mode will also allow proper ACL support in the guest. This mode is generally a bit slower than passthrough.
  • squash Similar to 'passthrough', the exception is that failure of privileged operations like 'chown' are ignored. This makes a passthrough-like mode usable for people who run the hypervisor as non-root. More info

Solution 2:

I once had a very similar problem, providing read-write access to the shared folder. It was possible to read files but I was not allowed to write files to the shared source path folder.

Unix & Linux - KVM / QEMU / Virt-Manager : How can I store files in the mounted shared folder

The root cause is that the guest system is running as libvirt-qemu user. What you should do to create files from within the running guest system in the mounted shared folder are these steps :

In Virt-Manager -> Add Hardware -> Filesystem select Mapped as Mode setting for the VM.

Change permissions for the shared folders : sudo chmod -R 777 /<path-to-shared-folder>

Change the owner to your username : sudo chown -R user:user /<path-to-shared folder>

Change the permissions for virtual disk files : sudo chmod -R 777 /<path-to-virtual-disks>

Change the owner to your username : sudo chown -R user:user /<path-to-virtual-disks>

Add your username to the libvirtd group : sudo usermod -G libvirtd -a <your-user-name>

Give full permissions to the libvirt-qemu user : sudo setfacl -R -m u:libvirt-qemu:rwx /*

Note : * = Specify the folder directory hierarchy you want to give libvirt-qemu the permissions.

Reboot the host operating systems ... now you should be able to create files in the guest system.

Information about 9p virtio -> Sharing Host files with the Guest | QEMU Documentation 9psetup

Mode specifies the security mode for accessing the source. Mapped specifies that the source is accessed with the permission settings of the hypervisor. Passthrough specifies that the source is accessed with the user's permission settings that are set from inside the virtual guest machine. This is the default mode. Squash is similar to Passthrough, the difference is that the failure of privileged operations like chown are ignored, this makes a Passthrough mode usable for users who are running the hypervisor without elevated privileges.