[Not: This is a complete rewrite of my initial reply as I learned a lot more]
So let me propose some answers to my own question, in the hopes someone will chime in and correct me if I have it wrong. I spent the weekend trying a ton of alternatives and experiments, and reading. A lot of what I am about to write is supposition not documented fact. And it’s a long ramble so I will bold some conclusions for those with short attention spans.
First – Hass.io vs. other alternatives: My strong impression is that the trajectory is toward making hass.io easier, with most modules going in and integrating now (especially post ingress) with almost no need for documentation. The counterpoint is that, at least relatively speaking, using alternative installation methods is getting much harder. Partially this is coming from hass.io (and in particular the “store” type modules) getting easier, but partially this is coming from the rapid changes occuring and the latency (or lethargy) in updating the documentation for alternatives. After all, if most people are just clicking on a tile to install (say) configurator, updating all the documentation for its install on docker or on another vm becomes less likely.
Configurator is a good example - I got a non-hass.io version running in a VM and then found documentation to install configurator – then found another separate version that was different and clearly reflecting a change (as it referred to the old way). I followed it and it failed – my fault perhaps. But I do a lot of linux admin as well as programming and after 30 minutes or so I just punted and moved on. Clicking a tile is so much easier.
So the gist of that aspect of my experience is I want to stay with a hass.io format, so as to be more in keeping with Home Assistant’s own development path.
So…Hyper-V versions. Initially I believed that the only way to get Hass.io running on HyperV was the pre-configured vhdx container. This ran hass.io fine, but did not have a conventional linux shell where I could add service (like usbip).
I learned later that it is really easy to run hass.io inside a docker container on a hyperV linux VM (e.g. ubuntu is what I used). That works very nicely, and provides a customizable linux while retaining (mostly) the advantages of hass.io.
But… I have a z-wave stick. And that is a real challange with Hyper-V, as Hyper-V will not pass raw hardware level access for USB through like VMware would, or virtualbox.
So off to Virtual box. Never used it before, a bit of going around in circles to get it running and getting the Nortek stick visible Big issue is windows kept turning it off, had to find drivers, put in the wrong driver to just get it visible in windows to turn off power management, but then it worked fine.
But Virtual box is like a toy in some ways – it won’t run as a service (so then introduce new tools to make it pretend), but most importantly – NO VLAN SUPPORT. Sorry, I’m spoiled, I can pass trunked or tag-identified VLAN’s into HyperV in any way I want. But despite several hours of trying I could not get a virtualbox VM to be on a different VLAN than the (one nic) host I was using. Two nics would solve this, but really… it did not look like a solid solution. And I personally detest dealing with anything Oracle – I do not trust them to be there, and work, down the road.
So with a lot of articles (a central one being here ) I tried setting up an rPi as zwave server. While I had quite a few false starts, this ends up working fine when you start up carefully.
Before getting to that I should note that if you search for (non-Home Assistant) related usbip postings, you will find that some linux versions are running older versions, some do not install a kernel compatible version, so you need to make sure the client and server side match (though I had it working with a non-matched version also). I ended up using ubuntu on the rPI not raspbian, though not sure that mattered, but it was not clear that raspbian had a fully compatible version. Here are some details:
https://askubuntu.com/questions/647068/usb-ip-kernel-modules-are-missing
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/898003
Anyway… the issue is that I find now I have lots of issues if I reboot: reboot the rPi server and zwave just stops communicating until I restart the HyperV client’s usbip service (or reboot it). Rebooting the client side from ubuntu works, but rebooting from hass.io (from inside the docker container) reboots, but the service will not start until the rPi is restarted. I hesitate to call it “unstable” as it seems to work fine when both are running, but it is certainly fragile when I try restarting things.
So… is this better than the rPi (or maybe more to the point a Nuc that I could run everything on faster) – maybe. I love Hyper-V snapshots (for rolling back bad changes) and how fast things run. But I hate things I want to depend on that are fragile.
Thanks,
Linwood