/run/pve ??
- Thread starter DocMAX
- Start date
I imagine you are referring to this.
Put bluntly, yes there is support for waking up a node via WOL in PVE, but not for waking up the cluster!
aaron has already given you this advice, but having the majority of the nodes sleeping = cluster sleeping. You'll encounter all sorts of trouble even if you dally with quorum settings. You've been warned.
If you don't use most of the nodes it's far more reasonable to not use a cluster at all but setup the datacenter manager in a vm to migrate between the nodes.
Your current setup will always cause issues, there is a reason why the documentation doesn't recommend such shenangians.
Your current setup will always cause issues, there is a reason why the documentation doesn't recommend such shenangians.
yeah, thanks for the warning. pve is probably for enterprise use. but i use it just for home enternainment. it's perfect for launching VMs on different machines @home since gpu passthough is supported (which is probably not meant as a enterprise feature). when i am not home i keep them updated on the server, which is running 24/7.
I don't get what you are trying to achieve. Some people might consider fixing broken clusters entertainment, I'm not one of them.
So: What are you trying to achieve with your cluster if most of the times the remaining nodes are offline? If you want to replicate your vms to other hosts you could also use pve-zsync ( https://pve.proxmox.com/wiki/PVE-zsync ). And as said for a migration of one vm to another node you don't need a cluster either, the datacenter manager will cover this. So: Why are you using a cluster and which usecase are you serving with your vms?
And GPU passthrough is not about enterprise or not, there are actually valid usecases for using it in an enterprise environment (see https://pve.proxmox.com/wiki/NVIDIA_vGPU_on_Proxmox_VE which describes a setup for a gpu which is way to expensive for regular homelabs).
You are correct through that PVE is not mainly for for homelabs, this is especially true for the cluster feature. To be blunt: It expect that at least three members of the cluster are always running (or two members + one qdevice for small clusters), if you don't want to have your member nodes running 24/7 a cluster is not for you. Expect you consider troubleshooting "home entertainment"
So: What are you trying to achieve with your cluster if most of the times the remaining nodes are offline? If you want to replicate your vms to other hosts you could also use pve-zsync ( https://pve.proxmox.com/wiki/PVE-zsync ). And as said for a migration of one vm to another node you don't need a cluster either, the datacenter manager will cover this. So: Why are you using a cluster and which usecase are you serving with your vms?
And GPU passthrough is not about enterprise or not, there are actually valid usecases for using it in an enterprise environment (see https://pve.proxmox.com/wiki/NVIDIA_vGPU_on_Proxmox_VE which describes a setup for a gpu which is way to expensive for regular homelabs).
You are correct through that PVE is not mainly for for homelabs, this is especially true for the cluster feature. To be blunt: It expect that at least three members of the cluster are always running (or two members + one qdevice for small clusters), if you don't want to have your member nodes running 24/7 a cluster is not for you. Expect you consider troubleshooting "home entertainment"
My usecase should be easy to understand:
a pve server 24/7. it holds a windows VM for gaming. i can do updates on OS, games etc. while i am not at home or trigger them remotely. the images is at
/zpool/nfs/images/201/vm-201-disk-0.qcow2 for example, which is shared via NFS.
game pc1, game pc2 and so on are pve nodes too. they do have almost the same vm config exept the hard disk is pointing to the image on my pve server and gpu passthrough is enabled. my home network has sufficient speed to start the OS directly from network. the main benefit of this is i don't need to do updates on each machine. i can do snapshots. test different images etc. the VM is allready up to date. when it boots it just gets the GPU of the respective PC where it boots up.
i needed to enable the cluster to be able to see all my PCs on one page, including wake on lan function.
if this setup can be simplifed i welcome new ideas.
a pve server 24/7. it holds a windows VM for gaming. i can do updates on OS, games etc. while i am not at home or trigger them remotely. the images is at
/zpool/nfs/images/201/vm-201-disk-0.qcow2 for example, which is shared via NFS.
game pc1, game pc2 and so on are pve nodes too. they do have almost the same vm config exept the hard disk is pointing to the image on my pve server and gpu passthrough is enabled. my home network has sufficient speed to start the OS directly from network. the main benefit of this is i don't need to do updates on each machine. i can do snapshots. test different images etc. the VM is allready up to date. when it boots it just gets the GPU of the respective PC where it boots up.
i needed to enable the cluster to be able to see all my PCs on one page, including wake on lan function.
if this setup can be simplifed i welcome new ideas.
Last edited:
So you have different VMs pointing to the same VM image? This is a rather risky setup since if you ever run multiple vms from the same disk image their changes will overwrite each other, causing havoc. For the update it would be more reasonable to enable the automatic update function of the operating system and more often schedules backups in PVE (e.g. hourly or daily depending on your needs) instead of abusing the hypervisor and operating system for a non-supported, error-prone setup. If you don't want to download the updates multiple times you and don't want to go the rabbit hole of WSUS ( I'm not even sure it's possible with non-Windows Server) pve-zsync as said should cover your needs (it basically replicates a vm with it's config to each configured target PVE node on a regular schedule e.g. every 5/10/15 minutes: https://pve.proxmox.com/wiki/PVE-zsync ) and can then be launched if needed. For a single-managment-of-glass: Proxmox Datacenter Manager provides this.
But I also don't get why you want to have one disk image for multiple vms in the first place. For tests you could always create a linked clone of a snapshot of the vm, test stuf and afterwards remove the clone before actually doing the change in production. If you want to move a vm to another node you can always use the migrate feature of the data center manager or inside the cluster (again: In the current state of your cluster don't do anything, split it up in three single-nodes and use the datacenter manager for migrations and having all nodes in one UI. The datacenter manager doesn't have the network requirements of a cluster).
So I still don't get what you want to achieve with your setup for me it looks like a combination of bad ideas which which will break sooner or later. And all this just to solve a problem that doesn't need to be solved if you use the software as it was designed, instead of jumping through endless hoops.
But I also don't get why you want to have one disk image for multiple vms in the first place. For tests you could always create a linked clone of a snapshot of the vm, test stuf and afterwards remove the clone before actually doing the change in production. If you want to move a vm to another node you can always use the migrate feature of the data center manager or inside the cluster (again: In the current state of your cluster don't do anything, split it up in three single-nodes and use the datacenter manager for migrations and having all nodes in one UI. The datacenter manager doesn't have the network requirements of a cluster).
So I still don't get what you want to achieve with your setup for me it looks like a combination of bad ideas which which will break sooner or later. And all this just to solve a problem that doesn't need to be solved if you use the software as it was designed, instead of jumping through endless hoops.
Thanks for the feedback. I want to clarify a few things regarding my setup to address the concerns about data corruption and why I chose this specific architecture.
First and foremost: I am fully aware that multiple VMs cannot write to the same image simultaneously. This is a single-user, multi-seat environment. I only ever power on one gaming node at a time. I am the only user; when I move from my office to my living room, I shut down one and boot the other.
By treating my PVE nodes as "compute nodes" and my central server as "storage," I gain several advantages that a standard distributed setup cannot offer:
First and foremost: I am fully aware that multiple VMs cannot write to the same image simultaneously. This is a single-user, multi-seat environment. I only ever power on one gaming node at a time. I am the only user; when I move from my office to my living room, I shut down one and boot the other.
By treating my PVE nodes as "compute nodes" and my central server as "storage," I gain several advantages that a standard distributed setup cannot offer:
- Single Source of Truth: I only have to manage one Windows installation. I perform OS updates, driver installs, and massive game patches (e.g., 100GB+ Steam updates) once. Every node is "up to date" the moment it boots.
- Storage Efficiency: I don't waste terabytes of space duplicating the same game library across multiple physical machines. The high-speed NFS share over my home network makes the performance difference negligible compared to local SATA SSDs.
- Snapshot & Disaster Recovery: I can take a snapshot of the master image before testing a new driver or a "modded" game version. If it breaks, I roll back once, and the fix is instantly applied to every room in my house.
- Hardware Independence: My gaming environment is completely decoupled from the hardware. If a motherboard or local boot drive fails on a node, I lose zero data. I can simply point a different node to my NFS image and be back in-game in minutes.
- Centralized Maintenance: I can boot the VM from my phone or a laptop via the PVE Web UI while I'm away, let it run updates on my server, and shut it down. When I get home, all my "remote" nodes are ready to go.