wake on lan and virtual machines....

[VJ]

Hello,

I'm trying to find a way to wake up a host when a wol-packet is send to the address of a contained guest (virtual machine).

The situation is: I have several Logitech Squeezeboxes, which connect to my Logitech Music Server (a Windows machine); the Squeezeboxes send a WOL-packet to wake up the server if needed. Now, there is an alternative music server (https://music-server.net/ ) which contains a Logitech Music Server and integrates with my Loxone home automation. The problem is that it runs on Linux, and I don't want to change the main OS.

My first idea was to run it in docker, but I don't manage to get it to work. Installation of the server is by means of a script and it uses some things (e.g. systemd) that are more difficult in docker. It also got a bit too complicated as a long term solution from a maintenance perspective.

Next I have tried installing it in a virtual machine (hyper-v) with its own IP address on the external network, while this works, the Squeezeboxes are unable to wake up the server as the WOL packet is sent to the mac address of the guest (but this is unreachable as the host is switched off).

As an alternative option, I have tried to put the guest behind a host-NAT and forward ports at the level of the virtual switch (https://tewarid.github.io/2019/06/26...n-hyper-v.html ). I could then set the Squeezeboxes connect to the IP of the host who then passes it on to the guest. This was my most successful attempt and while most things work but there is an issue with some broadcasts/unicasts that are not passed (known issue). This affects some functionality, so it also does not resolve the issue.

Now I thought: what if I add a second NIC and dedicate that one to the guest system? Hyper-V has such an option, but I cannot find what the effect would be of sending a WOL packet to that NIC... Any thoughts? Would it wake up the host? Any other ideas?

If that would not work, my best bet is to try forwarding the ports again... maybe I will find a configuration that works... Another option I thought is to use my home automation server to catch the WOL packet that was sent to the guest and send a WOL packet to the host as a result. The Squeezeboxes broadcast the WOL packet to 255.255.255.255, but I fear the Loxone filters incoming traffic somewhat as it does not show up.

Thanks,

Jörg

[MultimediaMan]

I need to point out that you definitely are "putting the cart in front the horse" in terms of the host. Virtual hosts are capacity aggregators, not really endpoints. It is normal for Virtual hosts to be shutdown and powered up as needed in a VMware Cluster, SCVMM-controlled Hyper-V Cluster, or even KVM Hypervisor Cluster but those use cases are with VMs (regardless of powered state) registered in the cluster they reside.

Now I thought: what if I add a second NIC and dedicate that one to the guest system? Hyper-V has such an option, but I cannot find what the effect would be of sending a WOL packet to that NIC... Any thoughts? Would it wake up the host? Any other ideas?

No, that wouldn't help you because the NIC, even though it is "dedicated" to the VM still has a v-switch to run through (passthrough-by-Hypervisor/proxy). In Windows, you need to go into the NIC hardware properties and enable WOL explicitly, but depending on the NIC and firmware even that might not be enough because some are setup for broadcast WOL and others unicast WOL (many do both). Intel SERVER NICs generally have the best support assuming you install ProSet. In Linux, you use ethtool, again Intel Server NICs generally have the best support.

[VJ]

I know... it is not typical that you would switch off the single host of a number of VMs...
It would be all fine if either I would not switch off the host or if I would not care about the wake-on-lan functionality and connect the VM to an external switch. I'm really talking normal consumer-grade equipment.

The wake on lan of my host works (intel nic), but I also now that to dedicate a NIC in Hyper-V it means that you have to indicate that it is not shared with the host... and I was not sure what the impact would be on the reception of a WOL packet: would the nic still be registered as a device that can switch on the computer, or not?

I'm now again trying the port-fowarding approach, as that was the most successful attempt so far. I had the issue that the Squeezeboxes were disconnecting after 5s, but now I think that may have had other reasons.

[UtwigMU]

If I understand correctly, what you are trying to achieve is have server wake up on demand in order to save power.

So you could get a cheap NUC or an old laptop, slap Linux on it and have it WOL. (little power, little space)

Maybe you could also find a way to port forward from Windows host or stick some kind of ha proxy load balancer in front - just throwing ideas.

[VJ]

If I understand correctly, what you are trying to achieve is have server wake up on demand in order to save power.

This works.
The point is to wake up the server when a WOL packet is sent to the address of a virtual server installed on it. In Hyper-V, all connections are through a virtual switch that runs on the host, so you cannot assign a NIC to a VM (you can only assign it to a virtual switch), nor share the hosts MAC. So there is no way the mac-address of the VM is reachable to achieve a WOL.
(VirtualBox does allow for such installations)

So you could get a cheap NUC or an old laptop, slap Linux on it and have it WOL. (little power, little space)

The point is not to have a computer/device running the whole time. The server I want as virtual can run from a Raspberry PI.

BUT: I've found the problem. The idea with port-forwarding should work (testing it today). I had some other weird behaviour which I thought was as an issue that prevented me to use the server in a VM installation, but it turns out it had to do with some settings of the server itself.

To be less cryptic: the VM is a music server for my Logitech Squeezeboxes. However, it not the standard server (that one I use now and runs on Windows, and works with WOL), but a distribution (linux only, installs via scripts) that adds functionality to integrate it with my home automation system. This distribution has the standard setting of powering off a player when playback stops, but because I tested with an empty library, it considers that playback is stopped. Adding files to a library and disabling that power off functionality made my players work correctly. So now I can try to use my port-forwarding idea, as that would make the players connect with the physical computer (and thus send WOL to that one).