Recent content by fabian

the second guest has pass-through disks, so those need to be copied to a different storage.. are you sure the rest of your config is correct? because your initial post had different storage names.. in particular, if the disks of pihole are actually on hp2_proxmox which is marked as shared, that...

yes, if you want more detailed control over the mountpoints than installing on top of Debian is the way to go.

please post the storage.cfg contents and the VM configs for both VMs

https://bugzilla.proxmox.com/show_bug.cgi?id=4935

the lock the log is referring to is the one inside the config file of the guest that the backup task itself sets.. do you have any scripts running that might remove such locks for whatever reason?

the next time you experience a bad download, please check - the file size (i.e., is your download truncated?) - try running a tool like vbindiff on it and a good copy to check which parts are different, usually you will see some pattern there (e.g., a single bit/byte flipped somewhere? 4k worth...

please provide the contents of the corresponding migration logs, "pveversion -v" from all nodes, and "find /etc/pve"

I am not aware of a particular high number of "bad ISO downloads" - I just think you might see more reports because there's a very active community here in one place.. if you in particular frequently see corrupted ISO downloads on your end, please provide details (can also be done privately).

you can see this in the "chunk_upload_stats" member of the index.json blob (the backup manifest, contained in each snapshot). this is added by the server when the backup snapshot is finalized. the numbers there *only count what has been uploaded by the client*: "unprotected": {...

you can use a directory-type storage as backup target (vma/tar format), and then define your own hookscript to do the encryption + offsite sync

the issue is kdump-tools - see https://forum.proxmox.com/threads/problem-after-updating-kernel.103293/#post-743761 you also want the -signed variant installed normally, not the one without that suffix ;)

boot the installer in debug mode, and then after the install has failed, retrieve "dmesg" and "lsblk" output and the installer log files from /tmp and attach them here..

check the network configuration and corosync logs on all nodes, it sounds like something is messed up there..

that probably means that whatever Paragon does when erasing the SSD makes wiping faster afterwards ;)

LVM will wipe the metadata when creating a thinpool.. one some broken SSDs/NVMe devices, this can take ages.. if it works with 8.3, that might mean that the kernel changed how it wipes your particular model..