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