[SOLVED] What are the best practices for using Windows as a Q-Device arbiter in a two-node PVE cluster?

[pulipulichen]

I had tested latency half a year ago: https://forum.proxmox.com/threads/qdevice-deployment.173182/post-805735

From my experiment it seems that a hundred milliseconds are tolerable.

Thank you so much for sharing your experience—this is truly valuable. It helps me better understand the lower limits of what a Q-device requires to function effectively.

Your insights further confirm how flexible the Q-device setup can be. Thanks again for the clarification!

 

[pulipulichen]

Adding a Hyper-V–based PVE host just for quorum is short-sighted. You are introducing additional, unnecessary, management overhead:

• Storage pools will now need to be restricted to specific nodes.
• If you add NAS storage later and do not restrict it to particular nodes, the VM will attempt to probe it, introducing another potential point of failure.
• /etc/pve will now need to be replicated to this VM, which creates a higher level of dependency compared to a simple QDevice.
• You are introducing an additional SSH/GUI endpoint on your network. A lightweight QDevice can be tightly restricted after the initial connection; a full PVE node is harder to lock down.
• HA rules must be carefully managed to avoid accidental VM migrations to the Hyper-V VM.

Possibly other issues that do not immediately come to mind. Overall, this adds a lot of unnecessary complexity for no real gain.

Personally, I do not see a compelling reason to have a dedicated physical NIC for the QDevice VM. Companies run critical database workload on PVE, HyperV, etc. A modern hypervisor should be able to handle light QD workload.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

That's a very fair point. While adding a full PVE node might offer the minor convenience of seeing the arbiter's status directly in the WebUI, the administrative overhead and potential complexities you mentioned—especially regarding storage restrictions and unnecessary /etc/pve replication—definitely outweigh that benefit.

You've completely convinced me; these are critical perspectives I hadn't fully considered before. I'll stick with a lightweight QDevice to keep the cluster simple and robust. Thank you very much for the detailed explanation!

 

[Johannes S]

Another thing to consider: As soon as you add the qdevice the cluster members can login as root on the qdevice via ssh without additional authentification. So you really shouldn't use the qdevice VM for anything else. This is especially important if at some later point you want to replace your current qdevice with a dedicated ProxmoxBackupServer. This can be mitigated by doing a paaralel install of PVE and PBS on the same machine and installing the qdevice in a vm or lxc like described by aaron here: https://forum.proxmox.com/threads/2-node-ha-cluster.102781/post-442601

 

[pulipulichen]

Another thing to consider: As soon as you add the qdevice the cluster members can login as root on the qdevice via ssh without additional authentification. So you really shouldn't use the qdevice VM for anything else. This is especially important if at some later point you want to replace your current qdevice with a dedicated ProxmoxBackupServer. This can be mitigated by doing a paaralel install of PVE and PBS on the same machine and installing the qdevice in a vm or lxc like described by aaron here: https://forum.proxmox.com/threads/2-node-ha-cluster.102781/post-442601

You’ve made a very valid point regarding security. The potential risk of the arbiter being a weak link that could lead to unauthorized control over the PVE cluster is a serious concern that shouldn't be overlooked. Using a PVE instance as a qdevice indeed introduces security implications that require careful isolation.

As for the PBS integration you mentioned, I’m not planning to address that with my current architecture just yet. I’ll likely revisit the PBS setup and look into more dedicated solutions when I have the budget to procure new hardware.

 

[UdoB]

The potential risk of the arbiter being a weak link that could lead to unauthorized control over the PVE cluster is a serious concern that shouldn't be overlooked.

The Quorum Device cannot access the cluster via ssh.

The cluster can access the Quorum Device - until you remove the rights granted during installation: https://forum.proxmox.com/threads/f...nd-secure-it-by-disabling-root-access.181525/

 

[pulipulichen]

The Quorum Device cannot access the cluster via ssh.

The cluster can access the Quorum Device - until you remove the rights granted during installation: https://forum.proxmox.com/threads/f...nd-secure-it-by-disabling-root-access.181525/

You are absolutely right, and I appreciate the correction. I realize I may have used the wrong terminology in my previous post.

My initial concern about the "weak link" and SSH privacy was actually based on the scenario of adding a third full PVE node to a two-node cluster. In that case, the level of mutual trust and SSH access required between nodes would indeed raise privacy and security concerns.

However, as you pointed out, using a Q-Device is a different story. It effectively eliminates those specific concerns because it doesn't require the same level of integration or reciprocal access to the cluster.

Thank you for clarifying this distinction—it makes the best practices for using a Q-Device much clearer.