Search results

Das obige Ereignis ist NICHT das Ergebnis einer Migration, sondern eine (vormals auf einer anderen Maschine geclonten und kalt migrierten) gestoppte VM wurde gestartet (qm start über GUI). Der Update auf 7.2 erfolgte im Mai, mit folgenden Versionen: proxmox-ve: 7.2-1 (running kernel...

Seit mein Cluster auf 7.2 ist, passiert es ab und zu daß in VMs Zeitsprünge auftreten, stets in Zusammenhang mit Migrationen aufgetreten (nicht unbedingt der betroffenen Maschine selber). Beim jüngsten Fall ist der Zeitsprung passiert, während eine andere VM neu gestartet wurde, daher denke ich...

Today, I live-migrated several VMs away from a PVE 7.1 to a 7.2 machine (shared storage). Most VMs behaved fine, but two showed a strange issue and needed reboot (all VMs 4.19 kernel, NTP synced using systemd-timesyncd). Migration took place at 11:25, took a few seconds with no problems...

no ZFS. FWIW, just checked on a machine with ZFS, can't see the consumed ARC memory in /proc/meminfo or htop either. So apparently kernel modules may consume memory that don't show up where I look.

total used free shared buff/cache available Mem: 32790452 13066656 13825864 62860 5897932 19125360 The Memory Usage graph of that node tells the same story. Excerpt from /proc/meminfo: MemTotal: 32790452 kB MemFree: 13826080 kB...

In a cluster of PVE 7.0 machines, I observe that machines have much less free memory than expected. I evacuated one machine, and rebooted. After the reboot, free shows 8GB used of 32GB total. 24h later, the RAM used has increased to 12GB. I can't locate any responsible process for this: htop...

I've installed kdump, and I still have those reboots. kdump is working fine, /var/crash is filled when provoking the crash with echo c >sysrq-trigger, but the malicious reboots don't log anything. So the reason seems to be non-software triggered. Mainboard BMC didn't log any power event. Running...

You're right, seeing "interrupt took too long" on other machines as well, when looking for it ;-) Unfortunately, this is a lonely machine in the desert, no machine to send netconsole to.

Running pve7 on a Supermicro board with Intel C3758, ECC memory, on-board NIC, 2xSamsung 860 pro. No problems with memory, temperature or SMART status detected, load is constantly low. Two VMS running, one OpnSense firewall, one Debian helper VM. pve has been rebooting 5x in the last 5 days...

Actually, the VGs need to be shared... Some VMs will be migrated to PVE, with TB of data on the SAN.

My storage is shared with non-PVE initiators as well. In addition, command line lvm actions won't lock against pve either. So PVE locking is mostly non-locking... Activating the volume to migrate with share option for the period of migration, and locking it exclusively afterwards would fix this.

I've setup LVM with lvmlockd and sanlock, backed by iscsi storage via multipath. AFAICS multipath can't be configured via GUI, so the actual backing of the volume group is unknown to PVE which should be fine since multipathd will handle everything. storage.cfg looks like this: lvm: santest...