Recent content by fabian

it is on no-subscription for both bookworm and trixie at the moment.

Thanks for sharing. Please note that Proxmox is a registered trademark, so please don't use it as part of your own product/app/tool name. You can indicate that your work is for Proxmox VE by, e.g., using a wording that avoids suggesting that this is a Proxmox project, but rather for (enhancing)...

we've already prioritized internally going through the backlog of the installer issues filed in bugzilla for the next series of releases, so they should all get an update one way or another once that has happened! please be patient (we are aware that this has taken longer than it should have!)

latest version of that patch series: https://lore.proxmox.com/pbs-devel/5004667b-a4a3-45d0-8baa-d163181be4fd@proxmox.com/T/#t technically this adds support for count/skip by offloading it to an external tool, just like for restore..

proxmox-backup-client will soon have pipe support, since a single snapshot can contain multiple archives this would just require creating one archive from a pipe (e.g. via dd) that extracts the part of the disk that you want..

I should have been more specific - we do not support "incremental restore" on top of an already restored guest, for the same reason. It is a bit of a similar issue like persistant bitmaps - the blockage is not so much technical (the hurdles there can be overcome), but the associated risk of data...

"continuous restore" is not implemented. one issue with it is that it can (silently!) break if something/someone modifies the disk that has been restored inbetween restore runs, unless you re-verify it which is very expensive.

you have other weird errors in your logs as well.. please double check the full journal for possible causes.

https://bugzilla.proxmox.com/show_bug.cgi?id=7305 - thanks!

could you file an issue on bugzilla.proxmox.com and include the commands to reproduce and their output? thanks!

"burning" previously used IDs is what the referenced patch series is about, so if you want that semantics, somebody needs to pick it up and drive it over the finish line, like I wrote above. yes, reuse in the context of backup/restore is the most common issue (but not the only one, so to avoid...

we've had plenty of discussions about this. we have no plans at the moment to switch the used IDs to a non-human-readable one, and there are already two IDs in the VM config that identify the VM and are generated on creation and re-generated at various life cycle points: - smbios1 uuid - vmgenid...

I don't know of any plans to pick up that particular patch series on our end, but we'd be happy to review if somebody else wants to drive it across the finish line. I think for your particular use case, you could use a tuple of (smbios uuid, vmid) as identifier, or use "different smbiod uuid"...

I haven't seen any announcement, but I also haven't followed developments too closely.. maybe @fiona knows more?

as far as I can tell, there was never a new version of the patch series after the last round of reviews..