You should confirm you’re backing up extended attributes. These are global (they’re not per-vm extended attributes), so if you share the same path with two guests, they’ll see the same UIDs. Any metadata changes made by the guest are stored in extended attributes. On the guest, you can chown/chmod as much as you want. (the qemu-owned process still needs permissions for these files) On the host, you would chown -R qemu:qemu all the files you intend to share with the client. This completely separates host and client permissions.
This would be a slightly better option if you were running a VM as your user, and running apps in the VM as the same user.įiles are created with qemu user credentials and the client-user’s credentials are saved in extended attributes. Pretty sure this is correct)Īs described, this is effectively the same as Passthrough, but it pretends ownership and permissions changes worked (even though they didn’t). (Note, the wiki is a little unclear and lists this as “none”. This makes a passthrough like security model usable for people who run KVM as non root. It is equivalent to passthrough security model the only exception is, failure of privileged operation like chown are ignored. This would be an option if you were running a VM as your user, and running apps in the VM as the same user. You’ll also get errors setting ownership/permissions.Įvery file created will be owned by qemu (which may just be a non-descript UID on your guest). The file was written to the host disk by the qemu-owned VM process, failed to set ownership to chris, leaving you with a file you created, but can not read. So if you’re user chris in the VM, you can write a file to the share, but be unable to read it. Writing doesn’t really work, as the Qemu host process is running as a limited user account. Even root on the guest can’t read a file qemu on the host can’t access. Reading files works as expected, keeping their original UIDs and permissions, as long as you keep in mind that both the guest and host are applying permissions rules. I tried to use this option, going so far as making my shared directory permissions an inadvisably-open 777. Effectively, this means that while the guest may try to set ownership permissions on a file, the host may block it based on the qemu’s user account. However, Fedora runs the VMs as the qemu user (additionally, you can run VMs as your user). This would be the simplest option if the VMs were run as root. To quote the Qemu 9p documentation wiki:įiles on the filesystem are directly created with client-user’s credentials. Mode is how UIDs and permissions are handled between guest and host. I didn’t find a very good explanation of “Handle”. Path is the option you want to use, here. In practice, a lot more thought and configuration is required. You select a path, you give it a name, and you mount it in the client. On the surface, it is actually very simple. This is the “built-in” filesystem passthrough in libvirt+qemu. I eventually worked around the quirky issues by forcing IPv4 on the NFS clients.įast forward to today, and I decided to investigate using filesystem passthrough using virtio-9p. Ideally, everything would use fe80:: internally, but it didn’t, and that was likely due to me mucking about with things. Additionally, the uncertainty of whether any connection will come as fe80:: vs my regular routable address was a pain (especially when my IPv6 network changed). While I have an IPv6 connection and IPv6 network, my router will stop advertising the IPv6 network if the Internet goes down, causing connectivity issues.
However, that was becoming increasingly troublesome, unfortunately due to IPv6. During my most recent server-build, I had to tackle exposing host-managed files to VMs.
0 kommentar(er)
