This is madness, but since this is a hobby project and not a production server, there is a way:

• Shrink the filesystems on the existing disks to free up as much space as possible, and shrink their partitions.
• Add a new partition to each of the three disks, and make a RAID5 volume from those partitions.
• Move as many files as possible to the new RAID5 volume to free up space in the old filesystems.
• Shrink the old filesystems/partitions again.
• Expand each RAID component partition one at a time by removing it from the array, resizing it into the empty space, and re-adding it to the array, giving plenty of time for the array to rebuild.
• Move files, shrink the old partitions, and expand the new array partitions as many times as needed until all the files are moved.

This could take several days to accomplish, because of the RAID5 rebuild times. The less free space, the more iterations and the longer it will take.

If you can assign a second IP address to the network interface, then just do so, and bind the docker container to one, and Adguard Home to the other. Otherwise, the reverse proxy based on the server name is the way.

I don’t know about theory, but the big practical advantage to ZigBee is that it works.

Sorry, that’s a shitty thing to say. I’m salty because the only time I tried X10 was 25 years ago, and the experience was less than great. Unreliable switching, spurious commands, slow performance, etc. Sending signals over the power wires sounds great in theory, but in practice there are all sorts of pitfalls, like resistive versus inductive loads, bridging circuits to different legs of two-phase power, or conflicting commands on the wire.

ZigBee has just worked for me, since it avoids all of the potential wiring issues. You just plug a device in, put it in pairing mode, and Home Assistant finds it, interrogates its capabilities, and adds it (by name) with the correct entities. No mucking about with addresses, or adding signal paths to the house wiring. As a mesh network, it’s quite robust, since most plugged-in devices act as repeaters.

The downside of ZigBee, of course, is that it may not work well in WiFi-saturated environments, since it uses the same 2.4GHz frequency band.

I realize that I forgot to answer the question! The wake_on_lan integration has a broadcast_address parameter. It doesn’t explicitly let you pick a network interface, but it might be worth trying to set it to the broadcast address of the Wi-Fi subnet. Then the routing table would ensure that the packet goes out on the correct interface.

For troubleshooting, start at the destination and work back. Run a packet trace on the target machine, and other machines on the WiFi network to see if any WoL packet comes through at all. If not, then look at the VM host.

How does HAOS access the USB network adapter? By pass-thru, so it’s like a USB device connected to the VM, or through a bridge on the VM host? If it’s the latter, a Linux network bridge device is often configured not to pass broadcast packets by the firewall rules. (Things like Docker will enable firewall filtering.) Check that the bridge allows broadcast packets through. If it’s the former, the USB pass-thru, do a packet trace from HAOS to ensure that it’s actually sending the packet, I guess.