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