Branch | Azure Pipelines | Automated Tests | Code Quality |
---|---|---|---|
main |
This module will build a multiple machine Hyper-V Lab environment from an XML configuration file and other optional installation scripts.
While studying for some of my Microsoft certifications I had a need to quickly and easily spin up various Hyper-V Lab environments so that I could experiment with and learn the technologies involved.
Originally I performed this process manually, creating Hyper-V VM's and environments to suit. But as the complexity of the Lab environment increased (e.g. take multi-tier PKIs) manually building these Labs became unmanageable. Also, if I wanted to repeat a particular process multiple times I would have to either snapshot multiple VMs or manually back them all up. This quickly became unsupportable as snapshots slows VMs down and constant backups of large Hyper-V environments was slow and also limited by space. This gave me a basic set of requirements for this module.
So as a solution to these problems I decided that I wanted a declarative approach to automating the process of building a Lab environment.
This had the following advantages:
The general goals of this module are:
To use this Module you will require on your Lab Host:
Operating Systems supported and automatically tested:
Operating Systems that should work but are not automatically tested:
Windows Management Framework 5.1 (WMF5.1) installed.
WMF 5.1 is installed on Windows 10 and Windows Server 2016 out of the box, but for Windows Server 2012/R2 and Windows 8/8.1 it will need to be installed separately. WMF 5.1 can be downloaded from here.
PowerShell Core 6/PowerShell 7: Untested, but may work.
Hyper-V available (which requires intel-VT CPU support).
To use labs that contain Nested Hyper-V hosts only Windows 10 built 10586 or later and Windows Server 2016 TP3 or later are supported.
Copies of the Windows installation media for any Operating Systems that will be used in your Labs. Note: Most Lab configuration files can contain a URL where the relevant trial media can be downloaded from, but you can use any Windows Install Media source you choose (including custom built ISOs).
An internet connection to download the WMF 5.1 MSU and any other optional MSU packages required by the Lab. Note: This only needs to be done during the Install-Lab phase and can be disabled after this phase is complete.
WS-Man enabled to allow communication with the Lab Virtual Machines. Note: if WS-Man is not enabled, the Install-Lab cmdlet will attempt to install it with confirmation being required from the user. Confirmation can be suppressed using the -force option.
If you wish to contribute to this project, please read the Contributing.md document first. We would be very grateful of any contributions.
The use of this module is fairly simple from a process standpoint with the bulk of the work creating a Lab going into the creation of the configuration XML that defines it. But if there is a Lab configuration already available that fits your needs then there is almost nothing to do.
A Lab consists of the following items:
There are a library of DSC configuration files for various machine types already defined and available for you to use in the DSCLibrary folder.
The easiest way to download and install the LabBuilder module is using PowerShell Get to download it from the PowerShell Gallery:
Install-Module -Name LabBuilder
PowerShell Get is built into Windows Management Framework 5.1, which is a requirement of this project, so it should already be installed onto your host. If it is not installed, download it from here.
Once the Lab files are available the process of installing the Lab is simple.
Install-Lab -ConfigPath 'c:\MyLab\Configuration.xml'
This will create a new Lab using the c:\MyLab\Configuration.xml file.
If you want more verbose output of what is happening during the Lab Install process, use the -verbose parameter:
Install-Lab -ConfigPath 'c:\MyLab\Configuration.xml' -Verbose
Once the Lab has been installed, it can be stopped using this PowerShell command:
Get-Lab -ConfigPath 'c:\MyLab\Configuration.xml' | Stop-Lab
This will shutdown any running Virtual Machines in the Lab in Reverse Boot Order, starting with Virtual Machines that have no boot order defined. LabBuilder will wait for all machines with the same Boot Order to be shut down before beginning shut down of VMs in the next lowest Boot Order. Any Lab Virtual Machine that has already been stopped will be ignored.
Note: Boot Order is an optional attribute defined in the Lab Configuration that controls the order Lab Virtual Machines should be booted in.
You can of course just shut down the Virtual Machines in a Lab yourself via Hyper-V (or some other mechanism), but using Stop-Lab ensures the Virtual Machines are shutdown in a specific order defined in the Lab (e.g. Domain Controllers shut down last).
Once the Lab has been installed and then stopped, it can be started back up using this PowerShell command:
Get-Lab -ConfigPath 'c:\MyLab\Configuration.xml' | Start-Lab
This will start up any stopped Virtual Machines in the Lab in Boot Order, with Virtual Machines that have no boot order defined being started last. LabBuilder will wait for all machines with the same Boot Order to be started up fully before beginning start up of VMs in the next highest Boot Order.
Note: Boot Order is an optional attribute defined in the Lab Configuration that controls the order Lab Virtual Machines should be booted in.
You can of course just start up the Virtual Machines in a Lab yourself via Hyper-V (or some other mechanism), but using Start-Lab ensures the Virtual Machines are started up in a specific order defined in the Lab (e.g. Domain Controllers started up first).
During the Install process of a Lab, if the template VHD files to use as boot disks for your VMs, LabBuilder will attempt to convert the required ISO files into VHD boot disks for you. This will only occur if the ISO files required to build a specific VHD file are found in the ISO folder specified by the Lab.
By default LabBuilder will look in the isofiles sub-folder of your Lab folder
for any ISO files it needs.
You can change the folder that a Lab looks in for the ISO files by
changing/setting the isopath attribute of the
Some common ISO download locations:
Important: If you are converting Windows Server 2016 ISO files or adding packages to VHDs please see the [Windows Server 2016](#Windows Server 2016) section.
Multiple VHD templates may use the same ISO file in a Lab. For example, if multiple editions of an Operating system are used in the same lab.
Once an ISO has been converted to an VHD, it will be stored in the VHDFiles
folder in your lab folder.
However, if you are using multiple Labs on the same machine you might want to
share these VHD files between mutlpile Lab projects to save having to build
and store copies for each Lab.
In that case, you can set the vhdpath
attribute of the <templatevhds>
node
in the configuration to a different relative or absolute path.
The conversion process for a single ISO to VHD can take 10-20 minutes depending
on your machine.
For this reason multiple Labs can be configured to use the same path to store
these VHDs by changing the vhdpath
attribute of the <templatevhds>
node
in the configuration.
If you are converting a Windows Server 2016 image and your Lab Host is running either:
Important: Only Windows Server 2016 Technical Preview 5 and above are supported with LabBuilder.
You will need to install an updated version of the DISM before you will be able to add any packages to a Windows Server 2016 ISO. This includes building Nano Server Images.
You can get the latest version of the DISM by downloading and installing the Windows ADK. After installing the Windows ADK, you can force LabBuilder to use this version by configuring the "dismpath" attribute in the "settings" element of your LabBuilder configuration file:
<labbuilderconfig xmlns="labbuilderconfig"
name="PesterTestConfig"
version="1.0">
<description>My Lab</description>
<settings labid="TestLab"
domainname="CONTOSO.COM"
labpath="C:\Lab"
dismpath="C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM" />
When a new Lab is installed onto a Lab Host from a configuration file, LabBuilder performs the following tasks (in order):
The entire process above is automated. As long as you a valid Lab Configuration file and any required Windows Installation Media ISO files then the Lab will be installed for you. Depending on the size of the Lab you are building and whether or not the ISO files need to be converted to VHD files, this could take from 5 minutes to many hours. For example, an Lab containing eight Windows Server 2012 R2 Virtual Machines configured as an AD Domain containing various services installed on a Host with four CPU cores, 32 GB RAM and an SSD will take about 45 minutes to install.
All Lab Guest Virtual Machines must have WMF 5.1 installed onto them before they are first booted in a Lab environment. This is to ensure the Self-Signed certificate can be generated and returned to the host for DSC MOF encryption.
If WMF 5.1 is not installed before the Lab VM Guest first boot then DSC configuration will not proceed, and the Lab Guest VM will boot with a clean OS, but none of the specific features installed or configured (e.g. DC's not promoted).
WMF 5.1 is only required to be installed onto Windows 7, 8 and 8.1 or Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2. Windows 10 and Windows Server 2016 already include WMF 5.1 so it doesn't need to be installed.
Most Labs are configured to install WMF 5.1 completely automatically so you don't need to install worry about it.
Note: It is possible to change a Lab Configuration file to prevent automatic installation of the WMF 5.1 MSU package onto Guest Lab VM's, but this is not recommended unless there is a good reason for doing so.
LabBuilder supports automatically installing any MSU package that can be downloaded from the internet onto the Lab Guest VMs during installation of the Lab. These MSU packages can be installed during any of the following phases of Lab installation:
By default, Lab configuration files are configured to ensure WMF 5.1 is installed at each of the above phases.
The WMF 5.1 MSU package is controlled by adding a new MSU element to the <Resources> element in a Lab Configuration. E.g.
<msu name="WMF5.1-WS2012R2-W81"
url="https://download.microsoft.com/download/6/F/5/6F5FF66C-6775-42B0-86C4-47D41F2DA187/W2K12-KB3191565-x64.msu" />
This defines the name of the MSU package and the Download location. The package can then be added to the <Template>, <TemplateVHD> or <VM> element in the Packages attribute. E.g.
<templatevhd name="Windows Server 2012 R2 Datacenter Full"
iso="9600.17050.WINBLUE_REFRESH.140317-1640_X64FRE_SERVER_EVAL_EN-US-IR3_SSS_X64FREE_EN-US_DV9.iso"
url="https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2012-r2"
vhd="Windows Server 2012 R2 Datacenter Full.vhdx"
edition="Windows Server 2012 R2 SERVERDATACENTER"
ostype="Server"
packages="WMF5.1-WS2012R2-W81"
vhdformat="vhdx"
vhdtype="dynamic"
generation="2"
vhdsize="40GB" />
Other MSU packages can also be installed in the same way. Multiple MSU Packages can be installed to the same VHD by comma delimiting the Packages attribute.
Documentation for the LabBuilder Configuration XML can be found in the file docs/about_LabBuilderSchema.md.
Complete documentation for the LabBuilder Lab Cmdlets can be found in the file docs/cmdlets-lab.md.
A list of Cmdlets in the LabBuilder module can be found by running the following PowerShell commands:
Import-Module LabBuilder
Get-Command -Module LabBuilder
Help on individual Cmdlets can be found in the built-in Cmdlet help:
Get-Help -Name Install-Lab
For a list of changes to versions, see the CHANGELOG.md file.