Recent content by longer

Yes, your understanding is correct. If for whatever reason the new subscription didnt get replaced correctly, you can attempt with --force option: pvesubscription update --force

I am also not sure if LVM-Thin can be safely shared between different nodes? Currently if the backend storage support thin-provisioning and discard, then (I think) you are more less having the same features as if its "LVMthin over iscsi". I mean then you can use iSCSI/FC LUN with shared...

https://forum.proxmox.com/threads/pbs-acme-order-kann-nicht-abgeschlossen-werden.176240/post-863521 Does it resolve when automatic updater run now? from above thread 2 reports mentioned it worked without change

I think the upgrade is necessary in any case since PVE7/Debian 11 is EOL. I found one thread related to Intel E810 NICs, where it was observed it can be related to causing memory leaks: https://forum.proxmox.com/threads/slow-memory-leak-in-6-8-12-13-pve.168961/post-799361 While its not the same...

Interesting topic, I am not aware of performance impact with keeping snapshot for too long or more snapshots means less performance. Indeed "snapshots are no backups" is to be taken seriously therefore ensure to always have your scheduled backup in place.

Is your NICs Broadcom bnxt_en NICs? I edited my first comment if thats can be tested (Ensure you have access via IPMI/iDRAC and take backup of /etc/network/interfaces so you can easily revert things)

So when you set bridge-vlan-aware yes You lose connectivity? Is your NICs Broadcom bnxt_en NICs? P.S I would think it should work with the below: auto vmbr0 iface vmbr0 inet static address 10.1.1.10/24 gateway 10.1.1.1 bridge-ports nic2 bridge-stp off...

One thing to add maybe, do you plan to heavily use snapshot/backup on NFS? If yes, then keep in mind that , there's a known behavior for VMs whose disks uses qcow2 format on file-level storage (without snapshot-as-volume-chain) [0]. As explained in thread [1], taking or deleting a large snapshot...

Yes its actually prerequisites for the upgrade to PVE9: https://pve.proxmox.com/wiki/Upgrade_from_8_to_9#Prerequisites Also, in general regarding the upgrade, ensure to double check the known issue in the wiki: Roadmap Proxmox VE 8.4 known issues Roadmap Proxmox VE 9.0-known-issues Roadmap...

There was similar report with issues with Nvidia vGPU when the CPU Type was set to host [1]. Setting the CPU type to host enables all CPU flags, meaning that features like Virtualization-based Security (VBS) are enabled. Could you try to set the CPU type for the VM to one of the QEMU CPU types...

Does it makes a difference if you set Bandwidth Limits? Datacenter -> Options -> Bandwidth Limits - Backup Restore.

You are right, I just checked the Debian package tracker and version 1.4.6 is indeed flagged as "A new upstream version is available... consider packaging it.": https://tracker.debian.org/pkg/clamav Seems the Debian maintainers haven't compiled it into the distribution streams yet. as PMG uses...

ClamAV updates automatically via the clamav-freshclam.service, which run continuously in the background. Check: ~# systemctl status clamav-freshclam PMG uses clamav from debian upstream - once they have an updated version - you will get it via regular update...

I am not exactly sure if this the current issue you observed, but since bonding is used, the following recommendation from Proxmox documentation applies: See 5.8.2. Corosync Over Bonds: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#pvecm_corosync_over_bonds

Do you have a separate interface dedicated for corosync? If possible share /etc/network/interfaces Corosync.conf