[pve-devel] [PATCH cluster/guest-common/qemu-server/manager v6 0/11] virtiofs

[Fabian Grünbichler]

high level:

- some indication for which patches require which patches and/or package
  relation bumps would be nice (e.g., qemu-server -> pve-guest-common
  and pve-manager -> pve-doc-generator)
- the qemu-server unit tests fail for me with the patches, but work
  without. they do work when run as root, so I assume some mocking for
  pmxcfs related things is missing

if I start a VM with `qm start`:

Jul 19 13:57:48 yuna qm[3872900]: <root at pam> starting task UPID:yuna:003B1897:0127A0F1:64B7CFBC:qmstart:901:root at pam:
Jul 19 13:57:48 yuna qm[3872919]: start VM 901: UPID:yuna:003B1897:0127A0F1:64B7CFBC:qmstart:901:root at pam:
Jul 19 13:57:48 yuna systemd[1]: Started 901.scope.
Jul 19 13:57:48 yuna kernel: device tap901i0 entered promiscuous mode
Jul 19 13:57:48 yuna kernel: vmbr10: port 2(tap901i0) entered blocking state
Jul 19 13:57:48 yuna kernel: vmbr10: port 2(tap901i0) entered disabled state
Jul 19 13:57:48 yuna kernel: vmbr10: port 2(tap901i0) entered blocking state
Jul 19 13:57:48 yuna kernel: vmbr10: port 2(tap901i0) entered listening state
Jul 19 13:57:48 yuna QEMU[3872940]: kvm: Unexpected end-of-file before all data were read
Jul 19 13:57:48 yuna qm[3872923]: command '/usr/libexec/virtiofsd '--fd=9' '--shared-dir=/var/lib/apt'' failed: received interrupt
Jul 19 13:57:48 yuna qm[3872900]: <root at pam> end task UPID:yuna:003B1897:0127A0F1:64B7CFBC:qmstart:901:root at pam: OK
Jul 19 13:57:48 yuna sudo[3872855]: pam_unix(sudo:session): session closed for user root
Jul 19 13:57:59 yuna QEMU[3872940]: kvm: Failed to set msg fds.
Jul 19 13:57:59 yuna QEMU[3872940]: kvm: vhost_set_vring_call failed 22
Jul 19 13:57:59 yuna QEMU[3872940]: kvm: Failed to set msg fds.
Jul 19 13:57:59 yuna QEMU[3872940]: kvm: vhost_set_vring_call failed 22
Jul 19 13:57:59 yuna QEMU[3872940]: kvm: Failed to set msg fds.
Jul 19 13:57:59 yuna QEMU[3872940]: kvm: vhost_set_features failed: Invalid argument (22)
Jul 19 13:57:59 yuna QEMU[3872940]: kvm: Error starting vhost: 22
Jul 19 13:57:59 yuna QEMU[3872940]: kvm: Failed to set msg fds.
Jul 19 13:57:59 yuna QEMU[3872940]: kvm: vhost_set_vring_call failed 22
Jul 19 13:57:59 yuna QEMU[3872940]: kvm: Failed to set msg fds.
Jul 19 13:57:59 yuna QEMU[3872940]: kvm: vhost_set_vring_call failed 22

$ qm start 901
[2023-07-19T11:57:48Z INFO  virtiofsd] Waiting for vhost-user socket connection...
[2023-07-19T11:57:48Z INFO  virtiofsd] Client connected, servicing requests

with only the qemu process in the systemd scope for that VM..

if I start via the API, the above issue goes away, but as noted by
Friedrich, the virtiofsd process is not part of the VM scope, but a
child of the start task, and lingers after the VM has been stopped.

On July 6, 2023 12:54 pm, Markus Frank wrote:
> cluster:
> 
> Markus Frank (1):
>   add mapping/dir.cfg for resource mapping
> 
>  src/PVE/Cluster.pm  | 1 +
>  src/pmxcfs/status.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> 
> guest-common:
> 
> Markus Frank (1):
>   add DIR mapping config
> 
>  src/Makefile           |   1 +
>  src/PVE/Mapping/DIR.pm | 175 +++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 176 insertions(+)
>  create mode 100644 src/PVE/Mapping/DIR.pm
> 
> 
> qemu-server:
> 
> v6:
>  * added virtiofsd dependency
>  * 2 new patches:
>     * Permission check for virtiofs directory access
>     * check_local_resources: virtiofs
> 
> v5:
>  * allow numa settings with virtio-fs
>  * added direct-io & cache settings
>  * changed to rust implementation of virtiofsd
>  * made double fork and closed all file descriptor so that the lockfile
>  gets released.
> 
> v3:
>  * created own socket and get file descriptor for virtiofsd
>  so there is no race between starting virtiofsd & qemu
>  * added TODO to replace virtiofsd with rust implementation in bookworm
>  (I packaged the rust implementation for bookworm & the C implementation
>  in qemu will be removed in qemu 8.0)
> 
> v2:
>  * replaced sharedfiles_fmt path in qemu-server with dirid:
>  * user can use the dirid to specify the directory without requiring root access
> 
> Markus Frank (3):
>   feature #1027: virtio-fs support
>   Permission check for virtiofs directory access
>   check_local_resources: virtiofs
> 
>  PVE/API2/Qemu.pm         |  18 +++++
>  PVE/QemuServer.pm        | 167 ++++++++++++++++++++++++++++++++++++++-
>  PVE/QemuServer/Memory.pm |  25 ++++--
>  debian/control           |   1 +
>  4 files changed, 204 insertions(+), 7 deletions(-)
> 
> 
> manager:
> 
> v6: completly new except "ui: added options to add virtio-fs to qemu config"
> 
> Markus Frank (5):
>   api: add resource map api endpoints for directories
>   ui: add edit window for dir mappings
>   ui: ResourceMapTree for DIR
>   ui: form: add DIRMapSelector
>   ui: added options to add virtio-fs to qemu config
> 
>  PVE/API2/Cluster/Mapping.pm         |   7 +
>  PVE/API2/Cluster/Mapping/DIR.pm     | 299 ++++++++++++++++++++++++++++
>  PVE/API2/Cluster/Mapping/Makefile   |   3 +-
>  www/manager6/Makefile               |   4 +
>  www/manager6/Utils.js               |   1 +
>  www/manager6/dc/Config.js           |  10 +
>  www/manager6/dc/DIRMapView.js       |  50 +++++
>  www/manager6/form/DIRMapSelector.js |  63 ++++++
>  www/manager6/qemu/HardwareView.js   |  19 ++
>  www/manager6/qemu/VirtiofsEdit.js   | 120 +++++++++++
>  www/manager6/window/DIRMapEdit.js   | 186 +++++++++++++++++
>  11 files changed, 761 insertions(+), 1 deletion(-)
>  create mode 100644 PVE/API2/Cluster/Mapping/DIR.pm
>  create mode 100644 www/manager6/dc/DIRMapView.js
>  create mode 100644 www/manager6/form/DIRMapSelector.js
>  create mode 100644 www/manager6/qemu/VirtiofsEdit.js
>  create mode 100644 www/manager6/window/DIRMapEdit.js
> 
> -- 
> 2.39.2
> 
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 
> 
>