Test Lab Guide Virtualization Notes

  • Article

If you’re not aware of Test Lab Guides, they’re part of a new initiative we have at Microsoft that is intended to make life easier for you when it comes to adopting new products and technologies. We realize that when you consider bringing in a new product and technology, you have to consider how long its going to take to learn how it works. Sure, you might try a hands-on lab or a virtual lab to see what the product or technology can do, but after that, then what?

You’re likely going to try to set it up in a test lab. But do you know all the front-end and back-end components that go into making the product or solution work? Maybe – but only after you dig through a pile of design and deployment guides and maybe a few KB articles and some obscure forum posts. That “paper chase” takes a lot of time and if you’re like me, you consider the risk/benefit ratio when it comes to your time before you try out something new.

That’s where Test Lab Guides come in. Using a Test Lab Guide, you can test a new product or technology in a well-defined and pre-tested lab environment that covers all the front-end and back-end components. You configure everything in the test lab, you see all the moving parts, and you see how everything works together. Many people have told us already that the Test Lab Guides allowed them to quickly learn complex technologies because they could see how all the parts worked together – something that would have taken a long time using the traditional approach of sifting through hundreds of pages of documentation. Even better, after you go through the Test Lab Guide and get a working configuration, you can save a snapshot of the working setup and return to it later, either to check out how things look like when they’re working, or to extend it on your own with custom settings that mirror your current production environment.

 

It’s All About the Virtualization

As you can imagine, the key to test lab success is virtualization. Sure, you could scare up a bunch of PCs and create a lab network, but who has the time and resources for putting together a physical test network that contains 10, 15, 20 or even more clients and servers? While I know that can be done because that’s how we used to do things, the idea of saving disk images and exporting them and then importing them again to extend the configuration is just too time consuming for today’s busy admin. Nope – the reality is that with the advent of client and server virtualization on commodity hardware, test labs are almost exclusively done in a virtualized environment.

Test Lab Guides were designed with virtualization in mind. But if that’s true, why isn’t there any virtualization related information contained in the Test Lab Guides outside of the last step in each guide that tells you that you should snapshot your configuration? The reason for this is that when I’ve written Test Lab Guides, I’ve assumed that the admin using the Test Lab Guide is already well versed in his or her virtualization platform of choice, and would easily be able to translate the TLG instructions into that virtualization platform. While we naturally would prefer that you use Hyper-V as your Test Lab Guide virtualization platform, we realize that there are a number of different virtualization platforms to choose from: VMware Workstation, ESX, Xen and other’s are all capable environments on which you can run your Test Lab Guide scenarios.

Providing virtualization specific information would mean that we would include information that is specific for some platforms and not others. In addition, for the non-Hyper-V platform, if there are changes, we might not necessarily know about them, as it’s not in our charter to stay on top of each version of each virtualization offering.

However, I think it is important to share some virtualization information that will help you with your Test Lab Guide experience. Some of this is Hyper-V specific, but hopefully most of it will be easily applied to to non-Hyper-V platforms. And if you’re not currently using Hyper-V, you might want to give it a look. I was a big VMware user prior to joining Microsoft. However, after joining Microsoft I felt it was important for me to have some basic understanding of Hyper-V. The result is that I’ve been using Hyper-V almost exclusively in my Test Lab Guide development process and am very impressed with it. So if you’re a “VMware guy or gal” and never looked at Hyper-V, I recommend that you give it a look. If for no other reason, you might want to use Hyper-V for Test Lab Guides.

 

Virtual Networking

When working with virtualization, you need a  good working understanding of how its virtual networking feature operates. With Hyper-V, there is the concept of “virtual networks” – with each virtual network acting as a type of virtual switch. VMware has a similar concept, which are called “VMNet’s”. Each virtual machine you connect to the same virtual network or VMNet is on the same virtual network segment, or in other words, in the same Ethernet broadcast domain. If you want to create a multi-segmented network, you would create a virtual network for each segment.

When working with Test Lab Guides, you can create virtual networks for each of the subnets called out the in the Test Lab Guide. For example, in the Base Configuration Test Lab Guide (https://www.microsoft.com/downloads/en/details.aspx?FamilyID=ab6c61af-9c34-4692-815c-4396b482d31b), you are asked to create a “Corpnet subnet” and an “Internet subnet”. When using Hyper-V, you would create a virtual network for the Corpnet subnet and another virtual network for the Internet subnet.

If you need more network segments, you would create more virtual networks. For example, in the Test Lab Guide: Demonstrate UAG DirectAccess (https://www.microsoft.com/downloads/en/details.aspx?FamilyID=71be4b7b-e0e9-4204-b2b5-ac7f3c23b16d), you need to create a new subnet called the “Homenet” subnet. To support the Homenet subnet, you just create a new virtual network.

If you are working with Hyper-V, you need to be aware that there are three types of virtual networks that you can choose from. These are:

  • Internal networks. These virtual networks allow hosts connected to the same virtual network to communicate with one another and with the host operating system.
  • Private networks. These virtual networks allow hosts connect to the same virtual network to communicate with one another. They are not able to communicate with the host operating system through the virtual network.
  • External networks. These virtual networks allow you to connect virtual machines to a live network. Each External network is associated with a particular NIC connected to your computer.

When I create the Base Configuration, I create two Private virtual networks: one for the Corpnet subnet and one for the Internet subnet. You can name them whatever you want and it’s probably best to name them Corpnet subnet and Internet subnet. Do the same for any other virtual networks you need to create to support the Test Lab. The Test Lab Guide will provide you some guidance on the name of the network (such as calling the new network the “Fabrikam” network), in which case you create a new virtual network for the Fabrikam subnet.

 

What about Internet Access?

Now you might be wondered what to do if you need to provide Internet access to a machine on a Private virtual network. Remember that virtual machines connected to a Private virtual network are able to communicate with other VMs on the same Private virtual network, but aren’t able to communicate with any other physical or virtual machine. You’ll have to do something to else to provide a virtual machine actual Internet access.

You might want to provide a VM actual Internet access if you want to download some applications or updates. The approach you use to provide this access will vary with the role the virtual machine is playing on the Test Lab network. For example, CLIENT1 (from the Base Configuration) is a Windows 7 client machine that’s designed to move between the Corpnet subnet, the Internet subnet and the Homenet subnet (and even the Fabrikam subnet if you choose to use the Fabrikam Base Configuration [https://www.microsoft.com/downloads/en/details.aspx?FamilyID=4521421f-bd0c-4eed-b280-a7aaf2fde321]). You can create an External virtual network and connect CLIENT1 to that network. It will then pick up IP addressing from the “live” network’s DHCP server and you can then download the information you need from the Internet. After you get the information you need, you can move CLIENT1 from the External virtual network back to the Corpnet subnet (which is a Private virtual network).

While this approach works fine for virtual machines that are designed to be mobile, it gets a bit more tricky when you want to provide Internet access for more “sessile” machines. Examples of these types of machines would be domain controllers and Exchange Servers; both of which really aren’t designed to be moved from one network to the other and be DHCP clients. We’re going to have to think of a different approach for these servers.

In addition, there might be scenarios when you need to demonstrate actual  Internet from specific client types access or you want to provide Internet access to all machines so that you can demonstrate things like Windows Update Services.

To do this, you might consider what I did in the Test Lab Guide: Demonstrate UAG SP1 RC Force Tunneling (https://www.microsoft.com/downloads/en/details.aspx?FamilyID=756e35c6-d706-4b18-80c2-881e9bccda3c). In that Test Lab Guide, I configured INET1 with a second network interface and then configured that network interface to use an External virtual network so that it could connect to the Internet. I then configured the default gateway settings on the computers in the Test Lab so that Internet bound traffic would go through INET1. There were some network gateway and DNS configurations that were required to make it work, but it did allow all the computers in the Test Lab Internet access, including DirectAccess clients.

Note:
We plan to update the Base Configuration Test Lab Guide so that Internet access is made a default option. I hope to have that update to the Base Configuration Test Lab Guide to you before the end of January. If you need help before that, please let me know and I’d be happy to show you how to provide Internet access to your Test Lab.

Make sure to always create the virtual networks you need before you create the virtual machines that you’ll to connect to them. It’s better to have the virtual network ready for the virtual machines instead of having the virtual machines wait for you to create the networks to connect to them.

For more information about configuring virtual networks on a Hyper-V server, check out the following video: https://www.screencast.com/t/Ft4Dpm4tLZ (around 7 mins)

 

Creating and Snapshotting the Virtual Machines

This is one area where there are a number of options and everyone has their favorite. One popular option is to use parent/child disk configurations, where you essentially create a parent disk that subsequent virtual machines can take advantage of when you want to quickly create new virtual machines for your Test Lab. Kurt Hudson did a great job describing how you do this in his TechNet wiki article Hyper-V Virtual Machine (VM) Parent-Child Configuration Using Differencing Disks https://social.technet.microsoft.com/wiki/contents/articles/hyper-v-virtual-machine-vm-parent-child-configuration-using-differencing-disks.aspx

While this is a valid and popular approach for quickly creating new virtual machines, and something that can be done with VMware and other virtualization platforms, I’ve have chosen not to use this approach when it comes to building out Test Labs. This and similar approaches that “key” into a parent disk introduce dependencies and potential points of failure that reduce the flexibility of the solution. It also makes it more complicated. However, it does have the advantages of allowing you to create virtual machines more quickly, and even more significant is the amount of disk space you can save by using this approach.

If disk space isn’t an issue for you, and if you’re willing to put in a few more minutes per virtual machine to reduce the risks of a parent/child configuration to your entire virtual lab infrastructure, then you might want to consider my approach. My approach is easy and it’s simple (which pretty much describes me). The approach I use for virtual machines:

  • Each virtual machine has its own disk file with the default value of 127 GB (it doesn’t take this much space on the physical disk because the virtual disk grows in size as needed to fit the data placed on the disk)
  • Each virtual machine is placed in its own folder on the hard disk. This makes it easy to identify the location of the virtual machine and the files associated with it
  • For the base configuration, after the operating system is installed, connect the virtual machine to an External virtual network and run Windows Update. Do the same for any other virtual machines that you might add to the Base Configuration
  • Connect the virtual machines to the virtual networks on which they will participate in the specific Test Lab that you’re using. Some virtual machines (such as CLIENT1) will move between virtual networks in many Test Lab scenarios.
  • At the end of each Test Lab, save a snapshot of the all the machines that participated in the Test Lab and give all the snapshots the same name.

 

Snapshot the Virtual Lab

Creating virtual machines and snapshots are closely related topics. Each virtual machine you create and configure represents a good chunk of invested time. If you don’t snapshot that virtual machine at the end of your Test Lab, you’ve wasted your efforts (OK, not wasted completely because you probably learned something during the process). When you snapshot the virtual machines in your Test Labs, you can quickly restore the snapshots and start at the end of that Test Lab. At that point you can create a new Test Lab, you can play with the settings to see what happens, or you can use troubleshooting and diagnostic tools and see what they look like when the system is working correctly. Snapshots are unique to virtualization and are a powerful tool to speed your ability to create advanced, realistic and actionable Test Lab scenarios that enable you to learn about your products and communicate more effectively than ever.

However, you need to be systematic about snapshotting. Over my years of using VMware Workstation I had created hundreds of virtual machines to support thousands of possible scenarios for ISA Server and TMG. I didn’t have a co-ordinated system for managing the snapshots and as you can imagine this lead to snapshot sprawl. Over time the sprawl got so bad that my carefully saved snapshots didn’t provide me value and I ended up often having to recreate Test Lab scenarios that I had already done.

At the end of each Test Lab Guide there is a step that informs the reader to snapshot the lab. The step also includes instructions on what to name the Test Lab. The reader should be instructed to shut down each of the virtual machines gracefully at the end of the lab and then snapshot all the virtual machines at the same time after all machines have shut down. After the snapshot it complete, rename the snapshot from its default name to the name suggested in the Test Lab Guide.

Something that we don’t include in the Test Lab Guides regarding virtualization, but something that most virtualization savvy admins are already aware, is that the order you start the VMs is important. In general, you want to start the domain controllers first. Then start servers that provide key infrastructure services to other servers and clients.

This requires that the reader understand the overall solution – and this might not be a reasonable expectation, since the reason for going through the Test Lab Guides is to learn about the product. For example, in the Demonstrating UAG DirectAccess Test Lab Guide, you should start the DC1 virtual machine (a domain controller) first, and then start the UAG DirectAccess server. The reason for this is that the UAG DirectAccess server acts as an ISATAP router for the rest of the network, and it should be available when the ISATAP hosts on the network start up and configure their ISATAP adapters as they start up.

I have not included this start up information in the Test Lab Guides, which is something we will fix in the next version of the Test Lab Guide specification.

Three suggestions for you, and things I plan to implement in the next version of Test Lab Guides are:

  1. Tell the reader which virtual machines to start up as part of step 1. Typically, step 1 in all Test Lab Guides is to complete the steps in some other Test Lab Guide, and then restore the snapshots in that Test Lab Guide. I would recommend that you have the reader start all the virtual machines that were part of the prerequisite Test Lab Guide, even if they won’t be configuring all of them. This creates a more coherent set of virtual machine snapshots and enables you build on the entire environment without having to worry about Active Directory or services sync that might get problematic if you don’t start the entire lab.
  2. Provide the reader guidance on the order of restoration of the snapshots. Like in the example I gave above, tell the reader to start DC1 first, then start UAG1, and then you can start all the other virtual machines at the same time.
  3. Provide the reader information about the approximate amount of memory they should have available on the virtual server to run the entire Test Lab. This includes the memory required to restore the snapshots and the memory required by virtual machines. Also, I’ve made the assumption that Test Lab admins have almost unlimited disk space – you might want to consider providing some information on how much disk space will be used by the end of completing you Test Lab Guide.

To get a better idea of how snapshots are created, restored and named, please see my video on this subject at https://www.screencast.com/t/pGpBxCoZO4QO (around 7 mins).

 

Summary

In this article I provided a handful of tips and tricks that I use with virtualization when creating Test Lab Guides. These are methods that have worked for me and many of them come from habits of working with virtualization for the last decade; some of the habits might be good and some might need improvement. But if you starting on your trek of writing Test Lab Guides and also beginning your work with virtualization, I hope that these notes help you creating your Test Lab Guides faster than might have otherwise.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Knowledge Engineer, Microsoft DAIP iX/Forefront iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): https://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: https://twitter.com/tshinder
Facebook: https://www.facebook.com/tshinder