jefftee I prefer Alpine Linux.

zxcp what about the
IOMMU Disabled message that you posted above?

IndyJ The problem appears to be in the 5.15 kernel as well but the workaround seems to fix the issue.

IndyJ The file restore issue was due to installing XO on FreeBSD (fine for VM restores, not file extraction).

I then installed XO on Ubuntu 20, and this worked for restoring files from Linux VMs but not Windows VMs.
Then I installed on CentOS 8 and had the same problem as Ubuntu.

I then installed on Fedora 34 and everthing works fine.

IndyJ So I went to the logs and pasted the command directly into the shell. while the vhd file does exist the mount point does not.

The command assumes a temporary directory within /tmp that is not getting created by the script.

If I create the directory and paste the command into the shell the vhd does mount.

Thanks for the tips.
When I try to restore an individual file from the server using ZFS compression & dedupe XOA gives me an error: "Error while scanning disk"

I'm wondering if the compression or dedupe is the likely cause. My money is on the Deduplication. Any thoughts on this?

Not being a ZFS expert here is an oddity: I have two old servers I use for backups. One is NFS with XFS filesystem (testing XO backups). The second is NFS with ZFS.

I copied my data from the server with XFS to the one using ZFS via rsync: A 17 Terabyte NFS/XFS share used only approximately 7 Terabytes on the ZFS server.

However If I backup data via XO to the NFS share on the ZFS system I don't seem to save space compared to backing up to NFS on the XFS filesystem.

I'm using lz4 compression & Dedupe on the ZFS system..

I'm testing XO. I have an NFS server with ZFS (compression + deduplication enabled).

Would backing up to this nfs share cause problems for backups & restores?

IndyJ said in Xen VMs & elrepo kernel:

Danp said in Xen VMs & elrepo kernel:

IndyJ May this is your issue? https://elrepo.org/bugs/view.php?id=1137&nbn=1

For those who install the kernel-ml from Elrepo: I tested this on all my CentOS 7/8 VMs: The results were mixed, the procedure worked on about half of them. Proceed with Caution.

Update:
This same issue has found its way into Fedora 34 in the stock kernel. No special repos, just "dnf update" and it happened. Could this affect the entire 5.14 series?

Danp said in Xen VMs & elrepo kernel:

IndyJ May this is your issue? https://elrepo.org/bugs/view.php?id=1137&nbn=1

For those who install the kernel-ml from Elrepo: I tested this on all my CentOS 7/8 VMs: The results were mixed, the procedure worked on about half of them. Proceed with Caution.

Danp That is the very problem I'm having. Thanks for looking that up!