Using GCP Always Free e2-micro as a QDevice for a 2-node Proxmox VE cluster: any pitfalls?

[pulipulichen]

Hi all,

I am planning to build a 2-node Proxmox VE cluster and would like to use a cloud-hosted QDevice/qnetd instance on Google Cloud Platform. My goal is to keep the QDevice VM within the GCP Always Free tier if possible.

My current GCP VM setup is:

• Region/zone: us-west1-b
• Machine type: e2-micro — 2 vCPU, 1 GB RAM
• OS: Debian 12 Bookworm
• Boot disk: Standard persistent disk, 20 GB
• Network tier: Standard
• External IP: ephemeral

The QDevice/qnetd VM would not communicate with the PVE nodes over direct public IP connections. Instead, all PVE-to-qnetd traffic would go through a ZeroTier overlay network.

My on-prem Internet speed test result from the PVE side is:

• Download: 901.88 Mbit/s
• Upload: 728.16 Mbit/s

A long-running ping test from one PVE node to the qnetd VM over ZeroTier shows the following result:

1000 packets transmitted, 1000 received, 0% packet loss
RTT min/avg/max/mdev = 125.240 / 126.672 / 272.308 / 6.811 ms

I understand that QDevice/qnetd is not part of the main node-to-node corosync link and should not have the same strict low-latency requirements as the PVE cluster network itself. However, since this would be used for quorum arbitration in a 2-node cluster, I am trying to understand whether this is a reasonable design or whether I am overlooking important failure modes.

My main questions are:

1. Is this latency/jitter pattern acceptable for a QDevice in a 2-node Proxmox VE cluster?
2. Are there any known issues with running qnetd on a small cloud VM such as a GCP e2-micro?
3. For those using cloud-hosted QDevices, have you seen practical problems with availability, VM suspension, overlay network instability, or unexpected quorum behavior?

Any real-world experience, recommended minimum specs, or operational advice for running qnetd on a cloud VM would be appreciated.

Thanks!

 

[UdoB]

1. Is this latency/jitter pattern acceptable for a QDevice in a 2-node Proxmox VE cluster?

Yes.

I had tested high latency some time ago: https://forum.proxmox.com/threads/qdevice-deployment.173182/post-805735

1. Are there any known issues with running qnetd on a small cloud VM such as a GCP e2-micro?

Probably none, but I do not use it, so I can not tell. But involving a device "on the other side of the internet" is the exact opposite of https://en.wikipedia.org/wiki/KISS_principle - and that would be the reason not to go that route - for me. Of course: ymmv!

 

[pulipulichen]

I had tested high latency some time ago: https://forum.proxmox.com/threads/qdevice-deployment.173182/post-805735

Thank you so much for sharing your test results! It’s amazing to know that even latency of up to 1s is still workable for the QDevice. That is truly a valuable piece of real-world experience.

I also completely appreciate your point regarding the KISS principle. Having a device "on the other side of the internet" indeed adds external dependencies and complexity compared to a local network setup. However, knowing that the protocol is robust enough to handle high latency gives me a lot of confidence to experiment with this setup.

Thanks again for your incredibly helpful insights!