Search results

there was a bug in the initial 1.0.0 version, please upgrade to 1.0.1 (e.g., via the no-subscription repositories), then it should work.

the difference between -2 and -1 for 6.17.2 is a tiny fix that avoids a kernel panic, so this only means that the issue at hand doesn't trigger quickly deterministically on either version of that kernel.

please post: - pveversion -v on both PVE nodes - VM config - migration and start log of the migrated VM - journalctl of both PVE nodes

thanks for your report! with also hit this internally now, so it seems there is some edge case not yet handled properly!

for containers, it depends which backup mode you use. for snapshot mode, the backup will be taken directly from a storage-level snapshot, no extra copy needed. for suspend mode, a temporary copy needs to be made (first it will be copied while the container is running, then the container is...

I don't think this is exposed yet - please file an issue! you can drive the process manually via CURL or some other API client, if you want (the Documentation linked in the top bar contains an API viewer).

which version of PBS are you using?

see the linked bug report - a new patch is waiting for review on pve-devel..

well it's barely 4 days old ;) we haven't settled yet on what the next version after 6.17 will be.

protection is not meant to make a backup immutable, but to protect it from being pruned. I think your desired semantics would require a different flag/mechanism. there are two related bugzilla entries: - https://bugzilla.proxmox.com/show_bug.cgi?id=6780 -...

and MTU 9000

@Chris managed to reproduce an issue that matches the symptoms in this thread. a newer 6.17.4 kernel is available on pbs-test that seems to fix that particular reproducer. testing and feedback would be highly appreciated!

you have a file that is probably a few hundred GB "big", but filled with zeroes. ZFS can store that and all the other data while taking less than 112GB of space. but PBS will still see the total size of the file and display that. PBS will most likely also take a lot less actual space for storing...

yeah, so then you have a big file that is actually empty, which ZFS can store efficiently without hitting the quota ("size") for the guest volume. for PBS this looks like a big (probably very compressible ;)) backup.

we've already added it to the known issues of the 4.1 release notes. it's not possible to just pull kernel 6.17. we've managed to reproduce the issue once so far and will update this thread once we know more (and of course, roll out a fix quickly once a culprit is identified).

I've said it a few times, but I can say it once more ;) this error here is almost certainly a sign of hardware-level corruption or instability. nothing inside a guest should be able to trigger this unless there is a bigger problem. missed that, sorry :)

the efi shell got disabled as part of a CVE fix a while back.. maybe there is a way to get it back if secureboot is disabled @fiona ?

it doesn't really make much of a practical difference. "apt-get" was the "stable" interface, and "apt" the "nice" one, but going forward apt will get versioned interfaces as well, and apt-get will likely be dropped/just exist as a compat layer for that. doing just "apt upgrade" first is not...

what kind of storage is local-data? ZFS for example can store a lot of logical data in 112G of physical quota..

https://bugzilla.proxmox.com/show_bug.cgi?id=5978 what does "journalctl -b -u pveproxy | tail -n 200" say? likely there is some extra garbage in the file that you can remove..