Server virtualization just got a little easier and possibly more exciting with the release of Windows Server 2012 and Hyper-V 3.0. It’s easier because of the PowerShell cmdlets,
In the past, IT pros have had limited PowerShell support, making it difficult to build and automate host and virtual machine (VM) configurations. This lack of support has caused many IT pros to avoid the most valuable weapon of server virtualization -- Server Core, which is light, fast and highly secure.
With Hyper-V 3.0 and PowerShell, admins can easily automate and scale a virtualization environment, prepare disaster recovery (DR) scripts and handle Server Core. The first step is to configure the new Hyper-V extensible switch for networking. Even though you’ll need to customize this for your environment, it’s still important to know the ins and outs of basic switch cmdlets.
Benefits using PowerShell in Hyper-V 3.0
Configuring a single virtual switch using PowerShell doesn’t make sense until you add its benefits, such as:
- Cmdlets that support the virtual switch, such as the –ComputerName parameter, which allows you to configure multiple hosts simultaneously.
- Cmdlets that work over PowerShell remoting, providing an efficient way to configure multiple hosts.
- You can write one-liners to configure the virtual switch and save them as .ps1 files, creating a script for automation and DR.
The tools at hand
Once you understand the benefits, it’s time to get started with the tools you’ll need to perform the switch configuration. Hyper-V 3.0 contains 164 cmdlets, 19 of which are used to configure the virtual switch. This might seem like a large number, but don’t worry; you won’t need most of them until you start working with additional third-party extensions.
For now, to create and configure a virtual switch, you’ll only need six of the switch cmdlets and one or two of the network adapter cmdlets, including:
- Get-Help *VMSwitch* -- Lists all 16 cmdlets for the virtual switch.
- Get-Help *VMSwitch -- Lists the six necessary cmdlets (note that there is no wildcard on the end of the cmdlet).
Creating a new Ethernet virtual switch
The external virtual switch ties the physical interface to the virtual environment. There are two cmdlets: New-VMSwitch and Add-VMSwitch. Both commands look similar, but they serve different purposes.
New-VMSwitch creates a new switch for one or more hosts. Here is an example of how to create an Ethernet switch on two hosts:
New-VMSwitch –Name ‘Outside Ethernet’ –NetAdapterName Ethernet
–ComputerName Host1, Host2 –Notes ‘Teamed nic support required’
You can use the Get-NetAdapter cmdlet to list all adapters on the host to select the correct argument for the –NetAdapterName parameter. Hyper-V 3.0 defaults to the Ethernet switch to allow the host to access the adapter. If this is not what you need for your configuration, you can set -AllowManagementOS to $False.
More on using PowerShell cmdlets
Windows PowerShell cmdlets for XenServer management
Top Hyper-V PowerShell cmdlets for basic tasks
Overcoming Hyper-V Live Migration limitations with PowerShell cmdlets
If you have an Ethernet resource pool in System Center Virtual Machine Manager (SCVMM), Add-VMSwitch cmdlet adds a virtual switch to the Ethernet pool. You will need to specify the pool name, similar to this example:
Add-VMSwitch –ComputerName host1 –Name ‘Outside Ethernet’
-ResourcePoolName ‘Ethernet Pool’
Configuring an Ethernet switch may be the extent of your switch endeavors, but many environments need internal or private network switches on the host.
Creating an additional internal/private virtual switch
The New-VMSwitch cmdlet, combined with a couple of the network adapter cmdlets, will make it easy to create internal/private switches. The example below creates a new internal switch called “Inside File Servers” on Host1 and Host2.
New-VMSwitch -Name 'Inside File Servers' -SwitchType Internal -Notes 'File server network'
The parameter –SwitchType supports internal or private, depending on your needs. This parameter is not available if you use –NetAdapterName, which configures only the external interface.
Once you create the internal adapters, you’ll want to assign them an IP address. This is where a couple of additional network adapter cmdlets come in handy. The following displays the internal switch I created above:
Get-NetAdapter -name *inside*
The New-NetIPAddress cmdlet sets IP Address, Subnet Mask and default gateway information on an interface. In this case, it’s the virtual interface for our internal switch.
Get-NetAdapter -name *inside* | New-NetIPAddress -IPAddress 192.168.3.10
If the host is a domain member and an internal VM is a domain controller, you might want to add a domain name system (DNS) entry to the internal adapter. This provides another DNS server for the host to access if one of the primaries fails. DNS settings are set using the Set-DnsClientServerAddress cmdlet.
Get-NetAdapter -name *inside* | Set-DnsClientServerAddress -ServerAddresses 192.168.3.15
What about the rest of the switch cmdlets?
The last four basic cmdlets can retrieve, remove and change a virtual switch. Here are a few of my favorite examples.
To get a list of virtual switches from multiple hosts as well as all the property information, use the following cmdlet:
Get-VMSwitch –ComputerName Host1, Host2 | Format-List –Property *
To change the name of a virtual switch from “Inside file Server” to “Inside Print Server,” use this cmdlet:
Get-VMSwitch –Name ‘Inside file server’ | Rename-VMSwitch
–NewName ‘Inside Print Server’
The Set-VMSwitch cmdlet provides several parameters for modifying an existing switch. The following command disables the management OS from using the external switch:
Get-VMSwitch –SwitchType External | Set-VMSwitch
The last cmdlet is Remove-VMSwitch, and it does exactly what it sounds like it would do -- removes a virtual switch by name. When testing a script for switch configurations, you’ll want to clear all switches from the host. This last example removes all switches from the host:
Get-VMSwitch | Remove-VMSwitch
PowerShell cmdlets for Hyper-V 3.0 extensible switch make it easy to configure and automate single or multiple hosts. Apply these techniques to your DR scripts and perform your next host-switch deployment using PowerShell.
This was first published in October 2012