On Tue Oct 7, 2025 at 3:55 AM CEST, Lorne Guse wrote: > >> For deleting intermediate snapshots.. can this be done on TrueNAS UI or does >> proxmox control this? >> If done on TrueNAS, can Proxmox learn about (adjust to) deleted snapshots? > It currently doesn't. I ran a test and deleted a snapshot from TrueNAS. The > snapshot still exists in Proxmox, but the disk is gone. > > TrueNAS [INFO] : Connected > TrueNAS [INFO] : Authenticated > TrueNAS [INFO] : Version: TrueNAS-25.10-RC.1 > TASK ERROR: can't rollback, snapshot 'test2' does not exist on > 'truenas:vm-100-disk-0' > > This is why I was asking if there was a way to "sync" snapshots between > platforms. > > Proxmox has an API > https://pve.proxmox.com/pve-docs/api-viewer/index.html#/nodes/{node}/qemu/{vmid}/snapshot<https://pve.proxmox.com/pve-docs/api-viewer/index.html#/nodes/%7Bnode%7D/qemu/%7Bvmid%7D/snapshot> > [...] > > $ pvesh delete /nodes/proxmox9/qemu/100/snapshot/test3 > TrueNAS [INFO] : Connected > TrueNAS [INFO] : Authenticated > TrueNAS [INFO] : Version: TrueNAS-25.10-RC.1 > TrueNAS [INFO] : Deleted snapshot: tank/proxmox/vm-100-disk-0@test3 > > Theoretically, I could pull a list of snapshots from both systems and compare > them. This could allow for my original use case of pulling in TrueNAS > snapshots as well as also watching for snapshots that have been removed. I > can see a path. We should agree on how it should work before I try anything. >
Hmm, I mean, in such scenarios I would personally rather say that PVE has the authority over snapshots in that regard, since we're expecting the host / the cluster to have control over the storage; as in, that there are no external influences. (At least, I can't think of any scenario / case off the top of my head where we're taking such external influences into account.) I've sifted through our code a little to see if there's a feasible way of actually doing this without calling the API, relying on any internals or implementation details, but there isn't really. (And `PVE::Storage` amongst other modules isn't expected to call the API at all.) So, what I would suggest instead is shipping some kind of daemon systemd service alongside your plugin—which you totally can do since you're packaging it neatly and all that. That daemon could periodically call our REST API to list snapshots on PVE and also communicate with TrueNAS via its own API (or whatever way you prefer obviously) in order to compare snapshots and prune the missing ones in PVE. Note that you when delete snapshots like that via the REST API, you might have to set `$force` so that it removes the snapshot's config / metadata, even if removing the snapshot itself fails (as it does in this case here). (Side note: If you need to parse & read `/etc/pve/storage.cfg` via that daemon, you can do so via `PVE::Storage::config()` [0] for example.) I think that this route is probably the most feasible / sane / maintainable on your end, because you really don't want to rely on any of our internals, as those aren't versioned like the storage (plugin) API. It's up to you if you want to follow that route of course; personally I would suggest that PVE keeps the authority and that any deviation from that on the storage's side should be considered a user error, but at the same time, I totally see your point. [0]: https://git.proxmox.com/?p=pve-storage.git;a=blob;f=src/PVE/Storage.pm;h=1dde2b751a766a28af8d40df7149936691cca772;hb=refs/heads/master#l232 _______________________________________________ pve-devel mailing list [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
