[SOLVED] Access to Proxmox through GUI denied

[nekton]

I am running Proxmox 7.3 on three servers. They all have VMs running on them and are clustered.

When I try to log in through the GUI I get an login error. But I am able to ssh into the servers.

The servers have been running for several months.

I don't know where to begin to solve this problem and don't want to hard boot the proxmox servers because of the VMs running on them.

Is there a command I can run to get the GUI to accept the root/password to be accepted again?

 

[UdoB]

Wild guess: in the Login Dialog you can find a drop down list "Realm:" select "Linux PAM" instead of "Proxmox VE auth".

Best regards

 

[Dunuin]

Unmounted PMXCFS (for example because the root filesystem is full or pveproxy/pvecluster service not running) also results in failing webUI logins while SSH works.

 

[nekton]

The problem has been resolved after looking at logs and doing some googling.

I ran systemctl restart corosync on each machine and then service pve-cluster on each machine. This allowed me to log back into each node and access the VMs which were all still running.

I am not sure why the clustering information got into a state where it did not think it had quorum but this resolved it. If anyone wants to take the time explaining that to me I would appreciate it.

 

[Dunuin]

Dedicated NICs just for corosync and all nodes at the same site?

 

[nekton]

Dedicated NICs just for corosync and all nodes at the same site?

I am not sure I know what you mean regarding dedicated NICs for corosync, but yes, all servers are in the same location.

 

[Dunuin]

Corosync should have low latency all the time (<10ms and <1ms recommended) or you might encounter situations where you lose quorum while all nodes are actually running.
So you shouldn't share a NIC for corosync and other traffic like storage backend, backups, guest communication and so on. So stuff like running a backup won't saturate the connection lifting the corosync latency above 10ms.
Thats why it is best practice to have a dedicated NIC just for corosync.
See the manual: https://pve.proxmox.com/wiki/Cluster_Manager

• We recommend a dedicated NIC for the cluster traffic, especially if you use shared storage.

• Network Requirements
  The Proxmox VE cluster stack requires a reliable network with latencies under 5 milliseconds (LAN performance) between all nodes to operate stably. While on setups with a small node count a network with higher latencies may work, this is not guaranteed and gets rather unlikely with more than three nodes and latencies above around 10 ms.
  The network should not be used heavily by other members, as while corosync does not uses much bandwidth it is sensitive to latency jitters; ideally corosync runs on its own physically separated network. Especially do not use a shared network for corosync and storage (except as a potential low-priority fallback in a redundant configuration).

 

[nekton]

Corosync should have low latency all the time (<10ms and <1ms recommended) or you might encounter situations where you lose quorum while all nodes are actually running.
So you shouldn't share a NIC for corosync and other traffic like storage backend, backups, guest communication and so on. So stuff like running a backup won't saturate the connection lifting the corosync latency above 10ms.
Thats why it is best practice to have a dedicated NIC just for corosync.
See the manual: https://pve.proxmox.com/wiki/Cluster_Manager

Thanks Dunuin! This was quite helpful.