I did a post at the start of the year about Lab management and VLAN tags, how they are not supported, but you can work around the problems. Over the past few months we have split our old Hyper-V cluster into one for production and one for test/lab development. This gave our IT team a chance to look at the VLAN problem again.
So a quick reminder of the issue – the deployment tools in Lab management that create environments provide no means to set a VLAN tag for any networks connections they create. Once an environment is created you can manually set a VLAN tag, but it is all a bit of a pain and certainly unsupported.
The solution our IT team have come up with to avoid the problem is to set the default VLAN tag on the physical port on the Ethernet switch. Hence any VMs/Environments on the the new test/lab Hyper-V don’t have to worry about VLANs at all, they are all automatically, in our case, on subnet 200. This works for TFS Lab Management and also means our developers need to have no knowledge of IP routing setup to deploy a VM/environment. Our production Hyper-V box, that runs much of our business systems, still uses manually set VLAN tagging as before, but as there is no auto deployment involved on this system there are no problems.
There is one gotcha though…..
If you try to use a VM created on our old setup, that was previously set with the VLAN tag of 200, it cannot see the LAN, even though it has what you think is the correct VLAN tag. This is because setting a VLAN tag with Hyper-V to 200 is not the same as not setting a VLAN tag in the operating system and letting the Ethernet switch default the port to the VLAN tag 200. So you have to let the switch manage the VLAN tag, the VM needs to know nothing about it. As shown below
So once this is all set you have your routed network, but also have a fully supported Lab Management setup