Trying to get wakeonlan working

stuartbh

Well-Known Member
Dec 2, 2019
136
19
58
61
All,

I have a VLAN that my Proxmox servers sits on and I also have a laptop that is connected to the same VLAN (all are running Linux, the laptop, guests, etc...). We can call the VLAN 100

I installed ngrep on the Proxmox server and ran it using: ngrep '\xff{6}(.{6})\1{15}' -x port 9
When I execute wakeonlan 06:66:00:00:00:01 on my laptop I can see the packet arriving on interface eno1, which informs me that there is not an issue with respect to my network per se (I have Cisco 3560G switches) as the packet is making it to the eno1 port of the Proxmox server. I also ran ngrep against the bond0 interface and the vmbr0 interface and the wakeonlan packet shows up on each of those interfaces. Thus, the wakeonlan package is making onto the vmbr0 interface. However, the VM running OVMF bios with a virtio network device still does not boot up due to the wakeonlan packet when it is in a shutdown state. Of course, I can power it on via the Proxmox console and it boots up fine.

Can anyone provide any guidance on what I might be desirous of trying to get this working?

Thanks!

Stuart
 
Last edited:
However, the VM running OVMF bios with a virtio network device still does not boot up due to the wakeonlan packet when it is in a shutdown state. Of course, I can power it on via the Proxmox console and it boots up fine.
So you are trying to power on VMs using wake-on-lan? That's not supported, unfortunately, in any case.

There have been a few scripted solutions in the past here on the forum, you should be able to find them if you search for that.
 
Thank you both for your replies.

I am first wondering why Proxmox does not support such functionality? Is it a design choice or is it just that it has not been requested or implemented as yet?

I looked at this solution: https://forum.proxmox.com/threads/wake-on-lan-for-vm.84355/

To say that I was thoroughly unimpressed with the script is a bit of an understatement as its logic was terrible and is highly inefficient. However, I took the time to re-write it and posted it as an attachment to the original thread set forth herein above.

I do think using the API to accomplish some of the tasks that are currently using binaries (in both the original script and my new script) would be a better way to accomplish this. This function could also be containerized (I'd prefer docker, but LXC would work too) meaning that it could easily be installed as a tur(n)key solution.


Stuart