SimonF

You can remove that hostdev secton. Want did you have passed thru on old MB?

I have tried any of the new options yet, you can download new binary from gitlab releases and replace the current file. /usr/bin/virtiofsd Additional options can be passed to virtiofsd. By default no including the variables passed from libvirt I add the following --syslog --inode-file-handles=mandatory --announce-submounts You can create a file called /etc/libvirt/virtiofsd.opt with options. Add the lines above, each option should be on a new line. --syslog --inode-file-handles=mandatory --announce-submounts --migration-mode <MIGRATION_MODE> You may need to check any details regarding snapshots in the issue link. --migration-mode <MIGRATION_MODE> Defines how to perform migration, i.e. how to represent the internal state to the destination, and how to obtain that representation. - find-paths: Iterate through the shared directory (exhaustive search) to find paths for all inodes indexed and opened by the guest, and transfer these paths to the destination. This parameter is ignored on the destination side. [default: find-paths] --migration-on-error <MIGRATION_ON_ERROR> Controls how to respond to errors during migration. If any inode turns out not to be migrateable (either the source cannot serialize it, or the destination cannot opened the serialized representation), the destination can react in different ways: - abort: Whenever any error occurs, return a hard error to the vhost-user front-end (e.g. QEMU), aborting migration. - guest-error: Let migration finish, but the guest will be unable to access any of the affected inodes, receiving only errors. This parameter is ignored on the source side. [default: abort] --migration-verify-handles Ensure that the migration destination opens the very same inodes as the source (only works if source and destination use the same shared directory on the same filesystem). This option makes the source attach the respective file handle to each inode transferred during migration. Once the destination has (re-)opened the inode, it will generate the file handle on its end, and compare, ensuring that it has opened the very same inode. (File handles are per-filesystem unique identifiers for inodes that, besides the inode ID, also include a generation ID to protect against inode ID reuse.) Using this option protects against external parties renaming or replacing inodes while migration is ongoing, which, without this option, can lead to data loss or corruption, so it should always be used when other processes besides virtiofsd have write access to the shared directory. However, again, it only works if both source and destination use the same shared directory. This parameter is ignored on the destination side. --migration-confirm-paths Double-check the identity of inodes right before switching over to the destination, potentially making migration more resilient when third parties have write access to the shared directory. When representing migrated inodes using their paths relative to the shared directory, double-check during switch-over to the destination that each path still matches the respective inode, and on mismatch, try to correct it via the respective symlink in /proc/self/fd. Because this option requires accessing each inode indexed or opened by the guest, it can prolong the switch-over phase of migration (when both source and destination are paused) for an indeterminate amount of time. This parameter is ignored on the destination side.

Do you only have one gpu in system

Fixed in next beta when released..

It may allow running snapshot of VM if using virtiofsd, Currently it fails as not supported.

I have asked for the latest vers be added to next beta release Virtiofsd v1.11.1 There is support for migration. https://gitlab.com/virtio-fs/virtiofsd/-/issues/136

There has been a merge of code, but have not tested the new version https://gitlab.com/virtio-fs/virtiofsd/-/issues/136

I dont think backups where announced to be part of 7. PBS is an enterprise class solution so suspect lots of money and time was tken to develop.

Will be based on your system time.

Shou!d not show in fcp now.

/boot/config/VMPCIOverride.cfg

No as it will not longer be available to use again once reverted.

Changed Status to Closed

Thanks alreaxy reported here