Search results

currently, logging out is done purely client-side. this would require implementing something like https://bugzilla.proxmox.com/show_bug.cgi?id=5478 to trigger expiry of sessions/tickets via an external request, and hooking that into the OIDC flow.

if reading the volume doesn't work, then yes, likely the file is corrupt and/or the underlying storage is defective.

it's a mountpoint. like a I said, you need to chroot into the root disk and then run pmxcfs -l to populate it..

I haven't started really working on that.. are you also running into it with the jitsi repo, or a different one?

https://pve.proxmox.com/wiki/Recover_From_Grub_Failure has some instructions (just skip the "update grub adn install it" part ;))

you can boot from a livecd, mount your root file system and chroot into it. then you can run pmxcfs -l to mount /etc/pve and copy the contents.

you can configure migrations to be insecure by default via datacenter.cfg. your migration task log shows: a 200GB volume in ~10m == 341MB/s == 2730 mbits the ~32GB of RAM+state with 399MB/s == 3192 mbits which is roughly the same ballpark, and nowhere near the (effective) linespeed.. of...

please try what I asked you to try - all you showed us is that your effective line speed is faster (but also not able to fully load your 25Gbps link), and that scp is even slower ;)

it's possible that this is the max speed that SSH achieves on your host.. if you trust your local network between the nodes, you could try an "insecure" migration that uses a plain TCP connection without any encryption or authentication and see if that is faster..

no. but you can always consider a community subscription (or higher ;)) if you want to financially support the development of PVE or other Proxmox software.

see https://bugzilla.proxmox.com/show_bug.cgi?id=5477 and https://bugzilla.proxmox.com/show_bug.cgi?id=491

yeah, please read the documentation about the requirements for clustering and HA!

that depends what you want to achieve.. you either route that traffic through opnsense, or (if you haven't passed through the only nic), use vlans to separate that in front of the opnsense VM. you will find lots of threads here in the forum about virtualized gateways like that, with different...

you need to ensure your cluster network is stable enough.. that is a requirement for HA.

yes, this is HA doing its job. corosync notices nodes not being up/connected to eachother, and every node that is not part of the majority/quorum will "kill itself". "journalctl -b -u corosync" will give you the log since bootup.

yes, the watchdog is exactly what ensures that a node that is not part of the cluster quorum shuts itself down so that another node can take over its guests. check the logs of the "corosync" unit, it will tell you when each node lost contact with others..

please post the full migration task log and "pveversion -v"

the patches are in the archives: https://lists.proxmox.com/pipermail/pve-devel/2024-April/063672.html https://lists.proxmox.com/pipermail/pve-devel/2024-April/063673.html https://lists.proxmox.com/pipermail/pve-devel/2024-April/063670.html but please be wary of applying patches from the...

yes, these files are benign - they are part of an IPC library used by corosync ("libqb"), which backs the /etc/pve filesystem and clustering features of PVE.

yeah, you can have such a setup - you can either pass through the physical interface to the opnsense vm, or give it a nic on a bridge that uses the physical interface. your other guests would then use a second bridge that is not connected to a physical interface, but also connected to the...