Tuesday, 26 January 2016

Using PowerShell DSC to construct a Hyper-V host

Administrators versed in PowerShell can streamline the process of using a server as a Hyper-V host.

While Hyper-V lags behind VMware in market share, Microsoft's hypervisor has been slowly catching on. Organizations love the price point -- sometimes free -- and the ever-increasing Hyper-V platform feature set. These advances have spurred administrators to deploy an increasing number of Hyper-V hosts.
We can set up a Hyper-V host on an existing server running Windows Server 2012 R2 using automation to make the process repeatable. This tutorial will explain how to use Windows PowerShell, specificallyPowerShell Desired State Configuration (DSC), to execute the deployment.
What does it take to build a Hyper-V host from an existing Windows server? For our purposes, it takes three things: a couple Windows features, a directory to hold VMs and a switch to connect the network to the VMs.
Building the framework
When starting any PowerShell DSC project, begin with a single PS1 PowerShell cmdlet file and a configuration block inside. We will call the configuration HyperVBuild.
Configuration HyperVBuild {

}
A configuration is similar to a function; it has code inside that can be executed at will, but it behaves a little differently. After configuration block, what follows is typically a parameter to the configuration just like a PowerShell function. A common parameter is $NodeName; this parameter will designate the computer in which the configuration will be applied. In this case, we default to the local host because the script resides on the server where we want to build the Hyper-V host.
Add the node block and assign the value of the $NodeName parameter in there. This tells Windows to create a configuration for the computer name specified in $NodeName.
Configuration HyperVBuild {
     param(
           [string]$NodeName = 'localhost'
     )

     node $NodeName {

     }
}
Add a dash of Hyper-V
After this framework is in place, we need to import a module called xHyper-V. Since the creation of a Hyper-V switch is required, this PowerShell DSC module is needed to get that functionality. The xHyper-V module doesn't come with Windows, but it can be downloaded from Microsoft's Github repository. Place it into the C:\Program Files\WindowsPowerShell\Modules directory; it will then be available on all subsequent scripts.
Use the Import-DscResource cmdlet and specify the module name xHyper-V.
Configuration HyperVBuild {
     param(
           [string]$NodeName = 'localhost'
     )
     Import-DscResource –ModuleName xHyper-V
     node $NodeName {

     }
}
We can now begin adding the necessary resources. First, add the Hyper-V Windows feature. This uses a PowerShell DSC resource that is built into Windows. Create a line starting with the resource name of WindowsFeature followed with a label to represent the resource. In this instance, we will call it Hyper-V.
Then, inside the block, use the Ensure attribute and set that to Present to install the Windows feature and also the name of the Windows feature to install when the configuration is run.
WindowsFeature 'Hyper-V' {
Ensure='Present'
     Name='Hyper-V'
}
Next, we need to ensure the Hyper-V-PowerShell feature is installed, so we'll create another block.
WindowsFeature 'Hyper-V-Powershell' {
Ensure='Present'
     Name='Hyper-V-Powershell'
}}
Next, we need a folder before creating the VMs, so we need to ensure one is created at C:\VMs. This uses the File resources to create the folder. The File resource has a Type attribute to indicate either a file or a directory.
File VMsDirectory {
Ensure = 'Present'
Type = 'Directory'
     DestinationPath = "$($env:SystemDrive)\VMs"
}
For the last feature, use a resource from the xHyper-V module called xVMSwitch to create and configure Hyper-V switches. Make the Type Internal to create a network for the VMs that can't communicate outside of the host.
xVMSwitch LabSwitch {
DependsOn = '[WindowsFeature]Hyper-V'
Name = 'LabSwitch'
     Ensure = 'Present'
Type = 'Internal'
}
Notice the DependsOn attribute. This is a common attribute across all resources that allows you to set the order resources are executed. In this example, we ensure the Hyper-V Windows feature is installed first before attempting to create the switch.
You should now have a configuration that looks something like this:
configuration HyperVBuild
{
     param (
           [string]$NodeName = 'localhost'
     )
     Import-DscResource -ModuleName xHyper-V
     node $NodeName {
           WindowsFeature 'Hyper-V' {
                Ensure='Present'
                Name='Hyper-V'
           }
           WindowsFeature 'Hyper-V-Powershell' {
                Ensure='Present'
                Name='Hyper-V-Powershell'
           }
           File VMsDirectory
           {
                Ensure = 'Present'
                Type = 'Directory'
                DestinationPath = "$($env:SystemDrive)\VMs"
           }
           xVMSwitch LabSwitch {
                DependsOn = '[WindowsFeature]Hyper-V'
                Name = 'LabSwitch'
                Ensure = 'Present'
                Type = 'Internal'
}
}
}
Now that the configuration has been built, generate the MOF files to apply to the system when configuration starts. To do this, execute the configuration block just like a PowerShell function by calling it by the name HyperVBuild.This creates a folder of the same name that contains an MOF file called localhost.mof.
The final part is to apply the configuration to the local machine. To do that, use the Start-DscConfiguration cmdlet and use a few different parameters.
Start-DscConfiguration -Path .\HyperVBuild -Wait -Force
The first parameter is Path. This points Start-DscConfiguration to the folder with the MOF file. Next, the –Wait parameter ensures Start-DscConfiguration waits to complete before releasing control to the console. Finally, the –Force parameter tells Start-DscConfiguration to "push" the configuration rather than pull. The push/pull scenario is further explained in detail in this article.
Once Start-DscConfiguration starts, you may see some messages on the console as it progresses through the configuration. If everything goes well, a few minutes later you will have a brand new Hyper-V server ready for VMs.

No comments:

Post a Comment