Posey's Tips & Tricks
How To Make Hyper-V Virtual Machines Portable
There are plenty of reasons to make Hyper-V VMs portable. The key is to make sure they work consistently, regardless of where each VM is running. Here's how to do it.
I found myself having to set up dozens of virtual machines (VMs) recently after someone asked me to create some video-based courseware for them. This wasn't really outside of the norm for me because I do that sort of thing all the time. The problem was that I wasn't going to be recording the courses in my own lab. Therefore, I had to make sure that the VMs were going to function exactly the same way in the studio as they do in my own lab.
Now, I realize that this is a pretty unique situation. Most people don't create Hyper-V VMs and then go running off to a studio to record the course. Even so, the need for VM portability really isn't all that unusual. Think of all the stories of organizations that create VMs on-premises and later decide to host them in the cloud.
The key to making my Hyper-V VMs portable was to ensure that network connectivity worked consistently, regardless of where the VM was running. This is trickier than it sounds because my VMs didn't just need Internet access -- they had to be able to communicate with each other. Furthermore, some of the VMs required static IP addresses.
This meant that simply allowing a DHCP server to assign IP addresses to all of the VMs was not an option. It was also not an option to assign static addresses to some VMs and let other VMs get their IP addresses from a DHCP server. The studio would presumably be using a different IP address range than what I use in my lab, so statically assigning IP addresses to some VMs but not others would cause the VMs to lose the ability to communicate with one another.
I also thought about assigning a static IP to all of my VMs, but doing so would prevent the VMs from being able to access the Internet, since the studio uses a different IP address range than I do.
The solution to this particular problem actually proved to be surprisingly simple. I assigned two virtual NICs to each VM. I gave one of the virtual NICs a static IP address (something in the 192.168.x.x range). I let DHCP provide the IP address for the other virtual NIC.
Giving each VM a virtual NIC with a static IP address ensured that the VMs would be able to communicate with one another. Additionally, because the IP address assignments were static, I didn't have to worry about any surprises related to incorrect DNS records.
As previously mentioned, I let DHCP take care of assigning the IP address to the remaining NIC. This ensured that the VM would be able to access the Internet and, if necessary, it would be able to access resources on the organization's network.
If you are designing a VM that will eventually have to function on a different network, then there are two things that you have to remember. First, in order for this configuration to work correctly, the static IP address has to be assigned to the VM's first NIC. Second, remember that the virtual NICs have a dependency on an underlying virtual switch.
For those who may be new to Hyper-V, there are three different types of virtual switches that are supported. External virtual switches allow a VM to communicate with the outside world. In order to achieve this, however, the virtual switch must be bound to a physical network adapter.
The reason I mention this is because if you export a Hyper-V VM and then import it into a different host on a different network, the new host is probably going to use a different type of physical NIC, and any virtual switch that exists is almost certain to have a name that differs from that of the virtual switch that exists in your own environment.
There are a couple of options for getting around this problem. One option is to make note of your virtual switch and then create an identically named virtual switch on the destination host before importing the VM.
Another option is to find out ahead of time what name the destination host's virtual switch has been assigned. If you know the virtual switch name, then you can create an identically named virtual switch in your own lab and connect the VMs to that virtual switch.
Both of these options represent an ideal situation. If neither of these options works for you, it's not the end of the world. You will just have to connect your imported VMs to whatever virtual switch happens to exist on the destination host. Just keep in mind that this will require you to redo any static IP address assignments within the VMs, so it's a good idea to keep a list of IP address assignments.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.