Search results

I had one more system which had an ifupdown2 issue after upgrade to Trixie. All 5 systems with ifupdown2 bug were solved with removing comments from /etc/network/interfaces . specifically the comment lines had a interface name within the comment line. These insterface files with those...

1- what are Q35 and i440fx? 2- post /etc/network/interfaces for vmbr on both nodes

I solved this . the node that would have migrations fail to and from needed an adjustment in /etc/network/interfaces . the other 4 nodes have vmbr3 set as: auto vmbr3 iface vmbr3 inet static address 10.1.10.7/24 gateway 10.1.10.1 bridge-ports bond3 bridge-stp...

what is ' sdn config' ? I see software defined network.

from a node that is okay to migrate live to: root@pve2:[~]:# pveversion -v proxmox-ve: 9.0.0 (running kernel: 6.14.8-2-pve) pve-manager: 9.0.5 (running version: 9.0.5/9c5600b249dbfd2f) proxmox-kernel-helper: 9.0.3 proxmox-kernel-6.14.8-2-pve-signed: 6.14.8-2 proxmox-kernel-6.14: 6.14.8-2...

from a node that fails more info: root@pve5:[~]:# pveversion -v proxmox-ve: 9.0.0 (running kernel: 6.14.8-2-pve) pve-manager: 9.0.5 (running version: 9.0.5/9c5600b249dbfd2f) proxmox-kernel-helper: 9.0.3 proxmox-kernel-6.14.8-2-pve-signed: 6.14.8-2 proxmox-kernel-6.14: 6.14.8-2...

here is a migration that worked to an old node: task started by HA resource agent 2025-08-21 15:40:39 conntrack state migration not supported or disabled, active connections might get dropped 2025-08-21 15:40:39 starting migration of VM 107 to node 'pve2' (10.10.0.2) 2025-08-21 15:40:39 starting...

I have 5 nodes. pve was recently installed on 2 of the nodes. I can live migrate to the 3 older nodes. The 2 newer nodes get this warning [ sometimes , sometimes no warning ] : conntrack state migration not supported or disabled, active connections might get dropped Live migration fails...

ceph mon remove pve4

I also noticed the ext4 part. However the issue starts 100% of the time when a node is in the process of shutting down for a reboot - shortly after the point it turns off osd , the hang starts at some or all of the remaining nodes. I did not think that ext4 had hnything to do with ceph...

Also: has anyone else had the same issue? It could be that I have done something uniquely wrong.

so with no node restarts there have been no hangs on pve nodesand kvm's . I have this set in sysctl.d since 2019 per https://tracker.ceph.com/projects/ceph/wiki/Tuning_for_All_Flash_Deployments#Sample-sysctlconf could these be causing an issue? fs.file-max = 6553600...

also one thing I ran into is that I tried to reboot the system after removing one of the rpool drives. I was unable to run zpool attach because for some reason the newly installed drive was in use. so i tried to reboot. reboot failed . changing the boot device in bios would have fixed the...

hung KVM's run both bookworm and trixie. so the kvm kernel version is probably not at fault. also the hang does not persist.

in the last 6 hours no new hangs occurred. [ hangs = blocked for more than 122 seconds ] . i call hang because when that occurs keyboard hangs. certainly inside a KVM , not sure if at PVE cli ] there are 3 nodes and a few kvm;s with hangs in dmesg in all cases the time of hang occurred...

other 4 nodes use enterprise repo # pveversion -v proxmox-ve: 9.0.0 (running kernel: 6.14.8-2-pve) pve-manager: 9.0.5 (running version: 9.0.5/9c5600b249dbfd2f) proxmox-kernel-helper: 9.0.3 proxmox-kernel-6.14.8-2-pve-signed: 6.14.8-2 proxmox-kernel-6.14: 6.14.8-2...

from the new node. note we have not moved the subscription over so it is using testing # pveversion -v proxmox-ve: 9.0.0 (running kernel: 6.14.8-2-pve) pve-manager: 9.0.5 (running version: 9.0.5/9c5600b249dbfd2f) proxmox-kernel-helper: 9.0.3 proxmox-kernel-6.14.8-2-pve-signed: 6.14.8-2...

using pve 9.0.5 . 5 node ceph cluster. nodes have a mix of zfs and non zfs root/boot disks along with one large nvme formatted ext4 for vzdumps. we also use pbs . i have a cronscript which we have used for years that checks this: dmesg -T | grep hung | grep -v vethXChung ## **URGENT**...

we had a crashed node. it is deleted from cluster. we did not have a chance to remove it as a ceph monitor. [ we did replace the monitor ]. ceph -s shows: health: HEALTH_WARN .. mon: 4 daemons, quorum pve11,pve2,pve5 (age 7m), out of quorum: pve4 how can I delete a monitor assigned...

generally I destroy the OSD on old node , move it to new node then create a new osd. Or is there a stable way to do the osd ? A few months ago I checked threads and had no luck. Also I did not see an osd move in manual.