vendor-reset VS pyznap

I have the vendor-reset fix. I have disabled resizable bar, and I have added the fix for the AMD driver detecting the VM in the XML file.

Credit to the fine people in this github issue:https://github.com/gnif/vendor-reset/issues/46

I’m not sure what you mean by forwarding, but if you mean regular gpu passthrough and the reset bugs with amd gpus, then for the rx580 vendor-reset should typically work: https://github.com/gnif/vendor-reset

Does not work with the lower 6000 (below 6800) and 7000 series that can also have reset issues.

Just an update installing vendor-reset to counteract the amd gpu reset bug fixed my issues completely. Are you running an amd gpu by chance, it may be worth a shot to try it. https://github.com/gnif/vendor-reset

1) download https://github.com/gnif/vendor-reset/archive/refs/tags/v0.1.0.zip

Sanoid/syncoids been mentioned but honestly for once a week learning by doing . Pyznap also excellent when you want to automate. https://github.com/yboetz/pyznap

In contrast, zfs snapshots are immutable, and thus anything short of a hardware failure can be addressed with a simple zfs rollback command. This includes deliberate, accidental, and malicious actions. They can also be automated (I personally use pyznap but syncoid is also quite popular), creating what is effectively an incremental backup. I maintain - for each dataset - 24 hourly, 7 daily, 6 monthly, and 1 yearly snapshot. Additionally, I have a wholly separate server that wakes up once a day to ingest these snapshots via zfs send/recv, so even if I made a horrible mistake or suffered a catastrophic hardware failure, I could completely restore from the other server. This last point brings snapshots firmly into the realm of backups, IMO.

Another favorite option is Pyznap, which is python based and originally created to have have a few features and changes compared to sanoid. The author is also active here on reddit. I and not sure what the differences are anymore, it'll come down to trying them and preference.

I have two Supermicro X9 2Us, each with Proxmox. One has allegedly existed solely as a backup target, which wakes up daily to ingest ZFS snapshots using pyznap. Unfortunately, for reasons which are unclear, this particular node doesn't always like to see its boot device, which is an NVMe drive. It's the exact same board as my primary, with the exact same modified BIOS to allow booting from NVMe. It usually takes 2-3 cycles before it'll see it and boot.

I have two nearly identical systems, both running Proxmox, with Debian VMs. One is a backup, which (once this is worked out) will wake up daily to ingest incremental backups. I'm using pyznap to handle the backup strategy.

https://github.com/yboetz/pyznap/issues/1#issuecomment-351015432