Recent content by Michiel_1afa

That is unfortunate. But yes, you might want to make a 2nd bridge device, and a vm or container to act as a router between the 2 bridges.

You often do not have to, but I would consider it good practice to do anyway so you have a clear indication of what lan these vms are on.

Hi moshe, you have 2 options here, you enable vlan support on the first (default) bridge vmbr0. it you will put vm's on vlan 1, they will be able to communicate with router, vlan1 is the default vlan in most (all) netwerk equiptment. If you put any other vlan besides 1, they can only communicate...

This is a bit of a meh.. issue easy to work around, but would be nice to find out whats going on. Affects: at least PVE 8 & 9 - exact patch version does not matter. - File size in this case does not matter, happens with any size image. Uploading an iso to a server in the cluster that is not...

Crosspost reply here. I also noticed problems with 6.17.2-2 which are not an issue on 6.17.2-1: https://forum.proxmox.com/threads/super-slow-timeout-and-vm-stuck-while-backing-up-after-updated-to-pve-9-1-1-and-pbs-4-0-20.176444/post-822997 On top of that, in that treat it does not look like...

Yes, we have determined as a group the problem is on the PBS (kernel) side, affecting all versions of PVE. - Would also like to add 6.17.2-2 has problems on the PVE side, we have noticed vm disks halting randomly with 'watchers' being stuck on the ceph side. This happens with live migrations...

No ! while this technically might work it invalidates the cluster, you shouldnt have 2 votes on a single node... Might as well install qdevice on 1 of the hosts directly (is that even possible?) What exactly do you disagree with, @SInisterPisces can build a valid 2 node cluster, and there for...

In our internal documentation, a 'just' 2 node setup is not recommended. The recommendation we do, 2 PVE servers + 1 PBS server (hardware) or something else that can act as a voting node: https://pve.proxmox.com/pve-docs/chapter-pvecm.html#_qdevice_technical_overview In all cases we end up...

Yes I agree with fabian here, if you look at your 'read' speed that is stable, and it is scanning the full disk to find the blocks to backup which can result in parts of the backup actually writing 0 bytes and in nearly all cases itll write less then it will read. This looks normal.

@ Staff. I see the 6.17 kernel is still in the enterprise repository for PBS.. with these problems resulting in broken VM disks i'd have expected that to be pulled for now until a fix is available. Right now if I, or anyone would update in a simular situation their env blows up.

it is in my earlier message, but our main production clusters we have both 9 and 8 versions, both fully updated as of last weekend. All PBS is 4 though (4.0 with the 6.14 kernel)

Can confirm downgrading the kernel worked for us, no more hanging backups or broken vms.

Welcome to the party Do not wait finishing upgrading your PVE cluster. PBS is the problem here so either do not upgrade PBS, or 'downgrade' PBS to the 6.14 kernel. The PVE machines are not an issue here and seem to be safe to upgrade to 9. For right now in our env I have: - Disabled all...

Same issue here PBS on ZFS fully upgraded, PVE 8 and 9 (2 seperate clusters) on both sides after upgrading this weekend I woke up to a absolute shitshow this morning with vm's detached from their ceph disks, linux complaining about scsi & ext4 errors and generally a bad time. After fixing all of...

Ofcourse, https://bugzilla.proxmox.com/show_bug.cgi?id=5649 and https://bugzilla.proxmox.com/show_bug.cgi?id=5650 Hope the bug reports are enough information.