Qemu 共享文件夹

  -virtfs local,path=path,mount_tag=mount_tag ,security_model=security_model[,writeout=writeout][,readonly=on] [,fmode=fmode][,dmode=dmode][,multidevs=multidevs]

  -virtfs proxy,socket=socket,mount_tag=mount_tag [,writeout=writeout][,readonly=on]

  -virtfs proxy,sock_fd=sock_fd,mount_tag=mount_tag [,writeout=writeout][,readonly=on]

  -virtfs synth,mount_tag=mount_tag

Define a new virtual filesystem device and expose it to the guest using a virtio-9p-device (a.k.a. 9pfs), which essentially means that a certain directory on host is made directly accessible by guest as a pass-through file system by using the 9P network protocol for communication between host and guests, if desired even accessible, shared by several guests simultaneously.

Note that -virtfs is actually just a convenience shortcut for its generalized form -fsdev -device virtio-9p-pci.

The general form of pass-through file system options are:

• local

  Accesses to the filesystem are done by QEMU.

• proxy

  Accesses to the filesystem are done by virtfs-proxy-helper(1). This option is deprecated (since QEMU 8.1) and will be removed in a future version of QEMU. Use local instead.

• synth

  Synthetic filesystem, only used by QTests.

• id=id

  Specifies identifier for the filesystem device

• path=path

  Specifies the export path for the file system device. Files under this path will be available to the 9p client on the guest.

• security_model=security_model

  Specifies the security model to be used for this export path. Supported security models are “passthrough”, “mapped-xattr”, “mapped-file” and “none”. In “passthrough” security model, files are stored using the same credentials as they are created on the guest. This requires QEMU to run as root. In “mapped-xattr” security model, some of the file attributes like uid, gid, mode bits and link target are stored as file attributes. For “mapped-file” these attributes are stored in the hidden .virtfs_metadata directory. Directories exported by this security model cannot interact with other unix tools. “none” security model is same as passthrough except the sever won’t report failures if it fails to set file attributes like ownership. Security model is mandatory only for local fsdriver. Other fsdrivers (like proxy) don’t take security model as a parameter.

• writeout=writeout

  This is an optional argument. The only supported value is “immediate”. This means that host page cache will be used to read and write data but write notification will be sent to the guest only when the data has been reported as written by the storage subsystem.

• readonly=on

  Enables exporting 9p share as a readonly mount for guests. By default read-write access is given.

• socket=socket

  Enables proxy filesystem driver to use passed socket file for communicating with virtfs-proxy-helper(1). Usually a helper like libvirt will create socketpair and pass one of the fds as sock_fd.

• sock_fd

  Enables proxy filesystem driver to use passed ‘sock_fd’ as the socket descriptor for interfacing with virtfs-proxy-helper(1).

• fmode=fmode

  Specifies the default mode for newly created files on the host. Works only with security models “mapped-xattr” and “mapped-file”.

• dmode=dmode

  Specifies the default mode for newly created directories on the host. Works only with security models “mapped-xattr” and “mapped-file”.

• mount_tag=mount_tag

  Specifies the tag name to be used by the guest to mount this export point.

• multidevs=multidevs

  Specifies how to deal with multiple devices being shared with a 9p export. Supported behaviours are either “remap”, “forbid” or “warn”. The latter is the default behaviour on which virtfs 9p expects only one device to be shared with the same export, and if more than one device is shared and accessed via the same 9p export then only a warning message is logged (once) by qemu on host side. In order to avoid file ID collisions on guest you should either create a separate virtfs export for each device to be shared with guests (recommended way) or you might use “remap” instead which allows you to share multiple devices with only one export instead, which is achieved by remapping the original inode numbers from host to guest in a way that would prevent such collisions. Remapping inodes in such use cases is required because the original device IDs from host are never passed and exposed on guest. Instead all files of an export shared with virtfs always share the same device id on guest. So two files with identical inode numbers but from actually different devices on host would otherwise cause a file ID collision and hence potential misbehaviours on guest. “forbid” on the other hand assumes like “warn” that only one device is shared by the same export, however it will not only log a warning message but also deny access to additional devices on guest. Note though that “forbid” does currently not block all possible file access operations (e.g. readdir() would still return entries from other devices).