So why not do the same thing on a desktop OS? Because Hyper-V networking only give the host a single virtual network adapter for every physical one. You may specify the VLAN identifier for the virtual adapter, but that is the only VLAN your host will see from the trunk.
Like I said, this is fine on a server, where you probably don't even want to have any host connectivity with your virtual swicthes at all, you would have a dedicated NIC for host connectivity. Anyway, a single connection to the host would always be enough.
When I was not running Hyper-V, I would on Windows be using Intel PROSet to create virtual adapters for my VLANs. I decided to ignore Intels recommodations and try to feed Hyper-V my virtual Intel adapters instead of a trunk adapter, and create a new virtual switch for every virtual PROSet adapter.
As PROSet would take care of the VLAN tagging, this setup should in theory fit my needs for VLAN id 1999:
I actually had this working for a single virtual switch, but as soon as I added another, for my second VLAN, I lost connectivity for my host. After tearing my hair out for an hour, I finally figured out that if I specified the VLAN id for the Hyper-V virtual management adapter, it started working. Go figure.
As it turned out, I had to do the same thing for my guests. Even if the VLAN filtering should already be done by PROSet, I had to specify the VLAN id for my guests as well.