Re: [pve-devel] TrueNAS over iSCSI: Snapshot Management

["Max R. Carrara" <m.carrara@proxmox.com>]

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
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel