Virtual Environments Concepts and Guidelines
This topic assumes that you are familiar with the basic concepts of virtualization, such as virtual machines and virtual machine templates, that are described in the topic Using a Virtual Lab for Your Application Lifecycle.
This topic describes concepts and guidelines for creating virtual environments by using Visual Studio Lab Management in Microsoft Test Manager. The topic contains the following sections:
A virtual environment is a collection of virtual machines that is managed by Lab Management. You can run manual and automated tests from Microsoft Test Manager using this virtual environment. You can schedule Microsoft Team Foundation Build workflows to build, deploy, and test builds of your application onto virtual environments. Lab Management is integrated with Microsoft System Center Virtual Machine Manager (SCVMM) to enable you to efficiently create, store, and run these environments.
Lab Management environments enable testers to perform the following tasks:
Store a snapshot of the environment that saves the state of all the virtual machines in the environment at a point in time.
A tester can take a snapshot of a configured environment and then revert the environment to this clean state after a test. A tester who discovers a bug can snapshot the environment and then attach a link to the snapshot in a bug. A developer who investigates the bug can create a copy of the snapshot environment while the tester continues on with his work.
Start and stop the virtual machines at the same time.
Run multiple copies of environments that are stored in the library.
You manage Lab Management environments for a team project from the Lab and Library tabs of Test Manager.
The Lab tab provides access to the virtual environment and machines that are deployed on the host groups of a team project. A host group is a collection of one or more physical computers that are managed by Lab Management to host the environments. You interact with a host group as if it was a single computer.
The Library tab provides access to stored environments, virtual machines, and templates that you use to create virtual environments in the team project Lab.
Deployed Environments in the Team Project Lab
The Lab tab of Test Manager shows the deployed environments and virtual machines that are available for your team project.
A deployed environment is a collection of virtual machines that is located on a team project host group. A deployed environment can be running or stopped.
From the Lab tab, you can connect to the individual machines through Environment Viewer, and you can create and store virtual machines and templates in the team project Library.
Sources of deployed environments
You can create deployed environments from the following sources:
One or more templates. A template is a virtual machine whose computer identity has been removed.
Any combination of stored virtual machines or templates. In most cases, a best practice that reduces the possibility of error is to create environments only from stored virtual machines or only from templates.
A stored environment of templates.
A stored environment of any combination of stored virtual machines or templates.
One or more deployed virtual machines that have been created outside Lab Management. These environments are called composed environments.
Stored Objects in the Team Project Library
From the Library tab, you can import, modify, and remove stored virtual machines and templates. You can also create and modify stored environments, and deploy those environments to the Lab.
Stored virtual machines and templates
The Stored machines and templates area of the Lab tab lists the virtual machines and virtual machine templates that you use to create deployed environments.
There are two sources of stored machines and templates:
An administrator creates and stores them in a SCVMM library share. You then import the virtual machines and templates into your team project library.
You create a virtual machine or template from a virtual machine in deployed environment and store in the library.
A template is a virtual machine that has had its identity information removed. When you include a template in a deployed environment, a new virtual machine is created. You can configure the template to provide the identity information automatically or you can provide the identity information when the environment is deployed.
Stored virtual machines
When you include a stored virtual machine from the team project Library in a deployed environment, an exact duplicate of the virtual machine is copied to a host in the Lab. Because the identity of the copied machine is the same as the source machine, you must take steps to avoid duplicate identities on network-joined computers.
A best practice is to make sure all virtual machines in the Library are workgroup machines and are not domain-joined.
When you create a non-network-isolated environment, change the computer name and then join it to the external domain.
The sequence of changing the computer name and then joining the machine to the domain makes sure that the identity of the machine is unique.
If you create a network isolated environment, Lab Management creates an alias for the machine on the external network. You can use the computer on a private network inside the environment, or leave the as a workgroup machine.
The Environments area of the Library tab lists the stored environments for the team project. A stored environment contains configuration information and references to virtual machines and templates. You can deploy new environments from stored environments.
The Microsoft Environment Viewer to manage running environments and virtual machines in your Lab. The Environment Viewer enables you to:
Start, stop, and pause an environment.
Take a snapshot of the state of an environment, or restore an environment to a previous snapshot.
View status and system information for the environment and the virtual machines it contains.
Connect to the individual machines in the environment.
For more information, see Operating and Modifying Virtual Environments.
There are three common patterns for creating and using virtual environments:
Using non-network-isolated environments.
Using network isolation.
Using deployed virtual machines in a composed environment.
Environments Without Network Isolation
Environments that do not use network isolation are joined only to the external network. They are created from virtual machines, templates, and stored environments in the project Library.
Creating environments created from stored virtual machines and templates
When you create a deployed environment from stored virtual machines or templates, you customize each of the deployed machines to have unique names. Templates can be configured to provide the customization automatically. Once you are done with the environment, you delete it. Other users can create similar environments from the same stored virtual machines or templates in the same manner. For more information, see How to: Create an Environment from Virtual Machines or Templates
Creating environments from stored environments
You can also create a stored environment from stored virtual machines, templates, or a deployed environment. When you deploy a stored environment, you must customize the names of virtual machines created from stored virtual machines; templates can be configured to provide the customization automatically. For more information, see Creating Stored Environments.
Environments that are generated from a stored environment of templates are functionally the same. They are not exact copies of each other because the identities of the computers in deployed environments are all unique.
You can run multiple copies of the environments at the same time.
When preinstalled applications that are running in your environment are not affected by the changed identities of the virtual machines, deployment of an environment can be a simple task.
The number and size of virtual machines in the environment is not restricted.
You must supply identity information for each deployed virtual machine. You can automate this process by using templates.
Deployed environments are not exact copies of each other.
Preinstalled applications that cannot be reconfigured to handle the changed identities will break. These applications must be installed after deployment.
Only one snapshot of an environment can be run at a time. For example, if a tester creates a snapshot of the state of an environment when she discovers a bug, she cannot share a copy of the environment with a developer for investigation and continue to work on her environment at the same time.
The machines in a network-isolated environment are protected from network conflicts by using two network adapters. One network adapter is used for a private network inside the environment. The second adapter is configured by Lab Management to present a separate, unique identity to the external network. The NetBIOS broadcast of the computer is disabled and the Lab Management identity is registered as an alias for the computer. This separate identity enables two-way communication between the virtual machines in the environment and the external network, even though multiple copies of the environment are running.
You can store network-isolated environments so that multiple copies of the environment can be run at the same time. When a network isolated environment is copied, the corresponding virtual machines in the two copies are exact duplicates of each other, because the identities of the machines within the private network remain the same each time that they are deployed. The aliases of the virtual machines on the external network make sure that that network conflicts do not occur.
You create a network isolated environment by choosing the network isolation capability when you deploy the environment from virtual machines or templates. You then install any necessary applications. If necessary, you also connect the virtual machines to the private network. You can then directly store a copy of the environment to the Library. Team members can deploy multiple copies of the stored environment at the same time. For more information, see How to: Create and Use a Network Isolated Environment.
Deployed environments are exact copies of one another. Developers and testers can be sure that their environments are identical.
Preinstalled applications are not affected by deployment. Because the identity of the machines do not change, applications do not have to be reconfigured or reinstalled.
Environments that model production environments are created most easily as isolated environments.
Multiple snapshots of an environment can be run at the same time. For example, a tester can create a snapshot of the state of an environment when she discovers a bug, and then store a copy of the environment in the library. She can continue to work on the environment while a developer deploys a new environment from the stored copy and investigates the bug using the stored snapshot.
All virtual machines in an isolated network must fit on a single host.
The virtual machines in a network-isolated environment must be either workgroup-joined or joined to a private domain that is hosted by a domain controller within the virtual environment. You cannot have virtual machines in a network isolated environment that are joined to a domain hosted by a domain controller on your lab network.
When the isolated environment uses a private domain, each deployed environment requires a domain controller and a DNS server. You should use an additional virtual machine for this role. An additional machine is not required for private workgroups.
Each virtual machine in the environment requires two network adapters. Your application might not work on computers that use two network adapters.
Composed environments are created from virtual machines that are deployed on a host. The creation and management of these virtual machines is performed Test Manager. As a result, the deployed virtual machines must be configured to prevent network conflicts before you create the environment.
After an administrator places the virtual machines on physical machines that are in the team project Lab, you create a new environment by selecting one or more of the machines in a composed environment. When you are finished with environment, delete it to release the machines back to the administrator. You should not store a copy of a composed environment in the library. Form more information, see How to: Compose an Environment from Deployed Virtual Machines.
Composed environments are useful in two common scenarios:
Getting started with Lab Management by using existing virtual machines. Composing is a quick way to create virtual environments and see the benefits of testing on those environments. You do not have to learn the concepts of templates and libraries before you get started.
Incorporating virtual machines that are already being used for testing practice inside an organization. Instead of recreating all the assets you can just take your existing virtual machines, compose them into virtual environments, and use them as targets for workflow deployment or testing.
Once Lab Management is installed and the appropriate Test Manager software agents on existing virtual machines, you can immediately create and use virtual environments.
You can transition to Lab Management without disrupting your current testing.
You cannot store these environments into the library and create multiple copies.
You cannot configure network isolation capability on composed environments.
You can use any combination of stored virtual machine and templates in your team project library.
A primary consideration in choosing between stored virtual machine and templates in a team project library is avoiding naming conflicts in a domain.
Naming conflicts in virtual machines
A computer has several identifiers that enables the machine to be uniquely identified on a network or in a workgroup. These identifiers include the following:
Computer name - This name is also known as the machine or host name.
MAC (Media Access Control) address - The identifier of the network adapter.
SID - The Windows security identifier assigned to the computer.
IP (Internet Protocol) address - A unique numeric identifier of the computer.
If multiple copies of a virtual machine are running on a domain or workgroup and share one or more of these identifiers, a naming conflict can, and frequently will, occur. A naming conflict between two machines can result in the following situations:
One or both of the machines are disconnected from the network.
Network traffic is incorrectly targeted If two machines have the same identity on a network, a command or message that is intended for one machine might be sent to the second.
A recommended practice is to use templates whenever possible. Templates can be an unfamiliar concept to some users, but the reduced risk of name conflicts when you use templates can make the additional learning curve an acceptable burden. You can configure a template to automatically create a unique identity for the virtual machine that is created from it, or you can configure the template to demand that a user supply an identity when the template is deployed. Templates also provide additional deployment options that are not available for stored virtual machines, such as running scripts when the machine is deployed and specifying the domain or workgroup to which the deployed machine is joined.
Stored virtual machines can be the preferred choice in some cases. For example, if an application such as SQL Server that depends on a fixed computer name is installed, you should use a virtual machine instead of a template to store a copy of the configured machine in the team project library. In these cases, you must use network isolation in your environment if you want to run multiple copies of the virtual machine at the same time.
You can create virtual machines in deployed environments that have unique identities from both virtual machine templates and virtual machines that are stored in the team project Library.