Ben Armstrong

Hyper-V Replica and Name Resolution

2013-06-14T07:13:35Z

I have been running Hyper-V Replica in my house for a while now. A while ago I noticed that some of my virtual machines kept on going into a critical replication state. It took a while for me to figure out what was happening:

Can you spot the difference between the working virtual machine and the failed one? The failed virtual machine is replicating using the fully qualified domain name – while the working one is using the short network name. Looking at the event log for this virtual machine confirmed that something was going wrong with name resolution:

Now for a confession. I am a bit of a klutz when it comes to configuring name resolution. For this reason my initial thought was to just change my virtual machines to all use the short network name for replication. But there was a problem with this approach. When you perform a planned failover using Hyper-V Replica we automatically switch to using the fully qualified domain name.

So I bit the bullet and tracked down some colleagues who were able to help me sort out my DNS server – and once that was done Hyper-V Replica was rock solid again.

Cheers,
Ben

Going to TechED? See you there!

2013-05-28T20:27:28Z

Next week I am heading off to TechED. What will I be talking about? It’s a secret…

Seriously. I have two sessions which are currently showing up as:

And:

And I can’t tell you any more than that. But, if it is a secret – it has to be something good, right?

I will also be on the show floor for most of the week, so feel free to hunt me down and have a chat about what you have been doing with Hyper-V!

Cheers,
Ben

Rename the guest OS to match the virtual machine name on Hyper-V

2013-05-13T20:02:00Z

When you are managing a large number of virtual machines, it can get tricky to keep track of everything. One thing that I see many people doing to help with this is to make sure that the guest operating system has the same network name as the virtual machine name. This makes life a lot easier when moving between different tools.

However, I tend to rename and copy virtual machines a lot, which makes it difficult to keep the virtual machine and guest operating system name synchronized. To handle this I wrote the following script:

# Get the virtual machine name from the parent partition

$vmName = (Get-ItemProperty –path “HKLM:\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters”).VirtualMachineName

# Replace any non-alphanumeric characters with an underscore

$vmName = [Regex]::Replace($vmName,"\W","_")

# Trim names that are longer than 15 characters

$vmName = $vmName.Substring(0,[System.Math]::Min(15, $vmName.Length))

# Check the trimmed and cleaned VM name against the guest OS name

# If it is different, change the guest OS name and reboot

if ($env:computername -ne $vmName) {(gwmi win32_computersystem).Rename($vmName); shutdown -r -t 0}

What this script does is:

Read the virtual machine name from the registry inside the virtual machine
Clean up the virtual machine name and check it against the guest OS name
If they match, move along
If they do not match, rename the guest operating system and reboot

I have this script inside my virtual machines, configured to run automatically when the guest operating system boots.

Cheers,
Ben

Using PowerShell to configure live migration networks in a Hyper-V cluster

2013-05-03T00:16:47Z

A long time ago, Didier Van Hoye asked me how to configure the networks that should be used for live migration by a Hyper-V cluster using nothing but PowerShell. Unfortunately, I never got around to getting an answer for him – until today.

Didier – this one is for you.

Now for a bit of background: When you create a Hyper-V cluster, you need to configure which networks are used for virtual machine live migration. You want to ensure that virtual machine live migration is going over a network with enough bandwidth available (a minimum of 500mbit per concurrent live migration is recommended) and where we are not going to disrupt other network traffic (i.e. do not have live migration run over your storage network). You also want to ensure that the network used by live migration is appropriately secure – either physically secure, or using technology like IPsec – as we do not do any encryption of the data being sent over this network.

You can do this through the UI quite easily:

But how do you do this with PowerShell? Well, after a lot of digging around it turns out that it is not that hard. It is not obvious, but it is not hard. If you only have one network for live migration – you can actually do this in one line. If you know the cluster network name you can run:

Get-ClusterResourceType -Name "Virtual Machine" | Set-ClusterParameter -Name MigrationExcludeNetworks -Value ([String]::Join(";",(Get-ClusterNetwork | Where-Object {$_.Name -ne "Migration Network"}).ID))

Or, if you just know the IP subnet for the live migration network you can run this:

So what is this doing?

Well, it is getting the “Virtual Machine” resource from the cluster (which is actually a global resource – that is not specific to a single virtual machine – bad naming, I know) and then it is setting the “MigrationExcludeNetworks” parameter on this resource. Which, unsurprisingly, is a list of the cluster networks to exclude from live migration.

Where things get a little fiddly here is:

This parameter wants the cluster network IDs rather than the names. For example: instead of specifying “Management Network” I need to specify “b18643a5-0cab-4d7d-93bf-6b4dc983ed2b”. This is annoying – but luckily the Get-ClusterNetwork Cmdlet returns this information through the “ID” property.
This parameter takes a semi-colon separated list (and there must be no spaces – otherwise it gets mad at you). Again, annoying but not the end of the world. In the samples above I use [String]::Join to pull this off.

It would get quite fiddly (but not impossible) if you wanted to configure multiple networks for live migration – but hopefully you should have the gist of how to do it from reading this article.

Cheers,
Ben

PowerShell script to tell you if you need to update your Integration Services

2013-04-29T17:33:00Z

A while ago I did a blog post that showed you how easy it was to check what version of the Integration Services were installed inside your virtual machines. However, a number of people came back to me and said: “Ben, I do not really care about the version number of the integration services – what I want to know is whether I need to update the integration services or not”.

Hmm…

That is a much trickier problem to solve. In fact, in Windows Server 2008 and Windows Server 2008 R2 it is not really possible to write a good script that will do this. Luckily, it is possible to write a script for this in Windows 8 / Windows Server 2012. Unfortunately, it is not the simplest script around.

There are a couple of reasons for this:

You can’t do this with the Hyper-V PowerShell cmdlets, you need to go straight to WMI
This information is only available through GetSummaryInformation – which is a rather strange interface

With that in mind – here is the script that will get you the information you need:

# GetSummaryInformation documented here: http://msdn.microsoft.com/en-us/library/hh850062(v=vs.85).aspx

# MSVM_SummaryInformation documented here: http://msdn.microsoft.com/en-us/library/hh850217(v=vs.85).aspx

# Get the Management Service from the v2 namespace

$VMMS = gwmi -namespace root\virtualization\v2 Msvm_VirtualSystemManagementService

# 1 == VM friendly name. 123 == Integration State

$RequestedSummaryInformationArray = 1,123

$vmSummaryInformationArray = $VMMS.GetSummaryInformation($null, $RequestedSummaryInformationArray).SummaryInformation

# Create an empty array to store the results in

$outputArray = @()

# Go over the results of the GetSummaryInformation Call

foreach ($vmSummaryInformation in [array] $vmSummaryInformationArray)

   {  

   # Turn result codes into readable English

   switch ($vmSummaryInformation.IntegrationServicesVersionState)

      {

       1       {$vmIntegrationServicesVersionState = "Up-to-date"}

       2       {$vmIntegrationServicesVersionState = "Version Mismatch"}

       default {$vmIntegrationServicesVersionState = "Unknown"}

      }

   # Use Hyper-V PowerShell cmdlets to quickly get the integration version number

   $vmIntegrationServicesVersion = (get-vm $vmSummaryInformation.ElementName).IntegrationServicesVersion

   # Display "Unknown" if we got a null result

   if ($vmIntegrationServicesVersion -eq $null) {$vmIntegrationServicesVersion = "Unknown"}

   # Put the VM Name, Integration Service Version and State in a PSObject - so we can display a nice table at the end

   $output = new-object psobject

   $output | add-member noteproperty "VM Name" $vmSummaryInformation.ElementName

   $output | add-member noteproperty "Integration Services Version" $vmIntegrationServicesVersion

   $output | add-member noteproperty "Integration Services State" $vmIntegrationServicesVersionState

   # Add the PSObject to the output Array

   $outputArray += $output

   }

# Display information in nicely formatted table

write-output $outputArray | sort "VM Name"

If I run this script on one of my Hyper-V servers – I get this:

Looks like I need to do a lot of integration service updates. Bummer.

But getting back to the script – what is GetSummaryInformation and why is it so tricky to use? GetSummaryInformation is a WMI method that we implemented to allow people to get a lot of random information about virtual machines in a quick and efficient method. The way it works is that you call it and pass in an array of numbers – this array indicates the information that you want to get about the virtual machines. You can read all of the possible options here: http://msdn.microsoft.com/en-us/library/hh850217(v=vs.85).aspx

One final note – in order to get the Integration Services state – you need to use the WMI v2 namespace.

Cheers,
Ben

Installing ICs offline in Hyper-V

2013-04-19T00:37:03Z

There is a great post over on the virtualization team blog about how to install the Hyper-V integration components offline. Go check it out: http://blogs.technet.com/b/virtualization/archive/2013/04/19/how-to-install-integration-services-when-the-virtual-machine-is-not-running.aspx

Cheers,
Ben

5th Grader using Hyper-V

2013-03-18T22:16:56Z

A colleague at Microsoft just sent me a pointer to this video of his 5th grade son showing you how to use Hyper-V to create a virtual machine:

http://blogs.technet.com/b/yungchou/archive/2013/03/18/are-you-smarter-than-a-5th-grader-in-creating-hyper-v-virtual-machine-and-installing-windows-server-2012.aspx

This seems like an excellent idea for our next Hyper-V advertising campaign!

Cheers,
Ben

Changing the Hyper-V Server login experience

2013-03-13T21:42:19Z

I have been spending some time working with the free version of Hyper-V server recently (available here: http://www.microsoft.com/en-us/server-cloud/hyper-v-server/default.aspx). It is lots of fun to see just how much you can do with this free software (hint: you can do everything you can with Hyper-V on a full installation of Windows).

However – one thing that I realized quickly was that I did not like the default login experience. Normally, when you login to a Hyper-V server you will get a command prompt and a running instance of the Server Configuration tool:

This is all fine and good when you are first setting the server up. But after then it gets a bit annoying. The reality is that most of the time you will be managing Hyper-V remotely – from another Windows computer. The only reason why you would want to login to a Hyper-V server directly is because something has gone wrong, and you need to do some troubleshooting.

Now, when it comes to troubleshooting a Hyper-V server – there are really only two things I want:

I want to know if all of my virtual machines are okay.
I want a PowerShell window so I can use the Hyper-V cmdlets to dig in deeper if I need to.

Having PowerShell launch by default is quite easy. Just launch PowerShell from the command prompt (type in “PowerShell” and hit enter) and then run this command:

Set-ItemProperty "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon" Shell 'PowerShell.exe -WindowStyle maximized'

Now you will get a PowerShell window instead of a command prompt whenever you login. But I wanted a bit more than that. To get a better experience – I needed to create a PowerShell profile. To create the profile I ran these commands:

     Set-ExecutionPolicy RemoteSigned

    New-Item -path $profile -type file -force

    notepad $profile

And put the following information into the profile file:

    # Maximize the window

    (Get-Host).UI.RawUI.BufferSize = New-Object System.Management.Automation.Host.Size(((Get-Host).UI.RawUI.MaxPhysicalWindowSize.Width-3),(Get-Host).UI.RawUI.BufferSize.Height)

    (Get-Host).UI.RawUI.WindowSize = (Get-Host).UI.RawUI.MaxWindowSize

    # Get the colors corrected

    (Get-Host).UI.RawUI.ForegroundColor = "White"

    (Get-Host).UI.RawUI.BackgroundColor = "DarkBlue"

    # Change path and clear the screen

    cd \

    cls

    # Display a welcome message

    write-host Welcome to $env:computername

    write-host

    write-host Current virtual machine status:

    get-vm

    write-host

The result is that when I login to my Hyper-V server now, I am presented with a full screen PowerShell window and a listing of my virtual machines straight away. Very handy.

Cheers,
Ben

Dynamic Memory Pro Tip–be reasonable with your startup ram

2013-02-26T17:39:32Z

Hyper-V now allows you to configure a startup, minimum and maximum memory limit. If you are like me – you probably leave the startup ram at the default of 512mb – but you should really consider changing it to better suit your environment. Here is a quick screenshot from one of my Hyper-V servers:

Two things that I have discovered:

Some of my virtual machines benefit from having a startup and minimum that is below 512mb. My FTP server, for instance, is a core installation of Windows server which just acts as an FTP server (and nothing else). It happily boots and runs with a startup and minimum amount of 256mb ram.
Other virtual machines benefit from having higher startup ram amounts. I have never seen my TMG server under 2GB of ram – and have set the startup ram for this virtual machine to 2GB.

Why would I increase the startup ram for the TMG server? Well – we do not start adding & removing memory dynamically until fairly late in the boot process for Windows (basically we wait until the system is mostly up and running before we start doing anything fancy with memory). TMG loads a *lot* of processes before we start reacting with dynamic memory.

The result is that while this virtual machine will always run well at the end of the day (no matter what the startup ram value is) the amount of memory assigned for startup ram can have a profound impact on boot times. When my TMG server has a startup ram value of 512mb it consistently takes ~10 to 15 minutes from cold boot to fully functional. If I bump the startup ram to 2GB it boots and is functional in under 2 minutes.

The net result for me is that my system is fully functional a lot quicker after any servicing, and I have not had to give up any resource to enable this.

Cheers,
Ben

Backing up Hyper-V virtual machines from the command line

2013-02-26T00:26:04Z

Last week I posted about how you can now use Windows Server Backup in Windows Server 2012 to backup virtual machines. One of the first questions that people had was “how do I do this from the command-line?” So – let me show you!

The tool you will want to use is “wbadmin.exe”

Backing up a virtual machine is fairly straight forward. Your command will look like this:

wbadmin start backup –backupTarget:<location to backup to> –hyperv:<list of virtual machines to backup>

Which will result in something like this:

Some things to be aware of:

Wbadmin will always warn you that the virtual machine will be put into a saved state for backup. This is wrong. The virtual machine will only be put into a saved state if it is not running the latest virtual machine additions (or is not a Windows virtual machine).
You will be prompted before the backup starts. You can get around this by adding –force to the end of the command.
You can use either the virtual machine name or the virtual machine ID when selecting virtual machines.
You can list multiple virtual machines to backup.
If you are backing up to a SMB share – new backups will automatically overwrite old backups (i.e. there will only be one backup kept on the share). This will not happen if you are backing up to a local disk.

Once you have created the backup – you then need to know how to restore it. This is, unfortunately, more complicated. The first thing you will need to do is to find the version of the backup and the name of the virtual machine you want to restor. You can find the version of the backup by running:

wbadmin get versions –backupTarget:<location where you backed up to>

If the backup was taken a while ago – you may have forgotten the name(s) of the virtual machines that you backed up. You can find this by running:

wbadmin get items –version:<version string for the backup you want> –backuptarget:<location where you backed up to>

Once you have this information you can restore the backed up virtual machine by running:

wbadmin start recover –version:<version string for the backup you want> –itemType:hyperv –items:<list of virtual machines to restore> –backuptarget:<location where you backed up to>

Cheers,
Ben