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

[pulipulichen]

Hi everyone, I currently have two PVE nodes and want to set up HA. I know that in a two-node setup, losing one node means losing quorum, which stops the services, so I need a third vote.

My plan is to install a simplified PVE node as a VM on my Windows PC (running 24/7) using Hyper-V, and join it to the existing cluster as an arbiter. Is this "virtual PVE node" approach feasible, or is there a more recommended best practice?

 

[SteveITS]

The Qdevice does not need to run PVE. It can just be plain Debian. In fact I’d say it shouldn’t run PVE.

 

[gfngfn256]

As noted above - a QDevice is just an external vote provided by that server. You can use the corosync-qnetd package to set this up on the external server.

For details on implementation - see the official Proxmox notes here.

Good luck.

 

[UdoB]

VM on my Windows PC (running 24/7) using Hyper-V, and join it to the existing cluster as an arbiter. Is this "virtual PVE node" approach feasible,

Probably. As @SteveITS already said: a plain and minimal instance of Debian is sufficient.

or is there a more recommended best practice?

Well..., there may be different opinions about this one. Personally I do not like Windows systems to be a required part of my infrastructure.

Two options I would prefer are: if you have an independent NAS running 24*7 and it can run Containers: run the QDev there. If you have a Raspberry Pi or any other SingleBoardComputer with low energy costs and the capability to run Debian: choose this one

The QDev runs fine with a very small amount of CPU compute power and the network does not require the low latency of the main Corosync-Rings.

 

[pulipulichen]

Thank you all for the valuable advice and suggestions.

Two options I would prefer are: if you have an independent NAS running 24*7 and it can run Containers: run the QDev there. If you have a Raspberry Pi or any other SingleBoardComputer with low energy costs and the capability to run Debian: choose this one

Regarding the environment I am currently configuring, I don't have a NAS capable of running containers, nor do I have a spare single-board computer (like a Raspberry Pi) available to install Debian. This is why I was considering using my existing Windows Server 2019, which is already running 24/7, to host the arbiter.

As noted above - a QDevice is just an external vote provided by that server. You can use the corosync-qnetd package to set this up on the external server.

For details on implementation - see the official Proxmox notes here.

Good luck.

I completely agree that installing a minimal Debian instance with corosync-qnetd is the official and most lightweight approach. However, I’ve noticed a specific behavior with the Q-device: it seems that when using qnetd, the status of the arbiter is not visible in the Proxmox WebUI. To monitor its health or current voting status, I have to manually run pvecm status in the shell.

In contrast, if I set up a "mini" PVE node (even as a VM) and join it to the cluster, its status is immediately visible and manageable directly from the cluster view in the WebUI.

Given that my hardware resources are not particularly tight and the local network speed is fast enough, I am leaning towards using a virtualized PVE node instead of a standard Q-device for better visibility. Are there any hidden risks or potential downsides to using a full (but minimal) PVE node as an arbiter in this manner that I should be aware of?

Looking forward to your thoughts!

 

[LnxBil]

I completely agree that installing a minimal Debian instance with corosync-qnetd is the official and most lightweight approach. However, I’ve noticed a specific behavior with the Q-device: it seems that when using qnetd, the status of the arbiter is not visible in the Proxmox WebUI. To monitor its health or current voting status, I have to manually run pvecm status in the shell.

Monitoring should be automatically done in the background from another system so that you have proper monitoring and alerting. This can be automated via pvecm if you want to do this, but don't manually look for stuff.

In contrast, if I set up a "mini" PVE node (even as a VM) and join it to the cluster, its status is immediately visible and manageable directly from the cluster view in the WebUI.

Given that my hardware resources are not particularly tight and the local network speed is fast enough, I am leaning towards using a virtualized PVE node instead of a standard Q-device for better visibility. Are there any hidden risks or potential downsides to using a full (but minimal) PVE node as an arbiter in this manner that I should be aware of?

That should work, too. You should disable any usable storage on that virtualized node in order to not migrate something by accident.

What is your plan for storing the VMs? I assume ZFS with replication, as you don't have a NAS for storing.

 

[UdoB]

Are there any hidden risks or potential downsides to using a full (but minimal) PVE node as an arbiter in this manner that I should be aware of?

Just create that scenario, it will probably work. Please report back your experience here

What I would do (if I would be forced to use a VM on Windows for this) is to make sure I give it a separate / independent NIC. I want the PVE node to have access to all VLANs/networks of the cluster while avoiding this for the Windows host. I do not want the VM to interfere with the Windows settings and vice versa.

Good luck. And have fun! (No irony!)

 

[gfngfn256]

I still think that a QDevice is the way to go. Setting up another PVE VM (in Windows) just for the sake of GUI-visibility seems to me completely unnecessary and wasteful. Add to that, the NW element inter-cluster is more complex & generally heavier than a simple QDevice which runs simply as TCP/IP. If you really want a third node - do exactly that: BM.

In general, I do agree, that it would be nice to have some GUI-visibility of a QDevice.
Maybe add your opinion to this forum thread/bug/feature request for such a feature.