Using a Standard Switch in VMM

system_center_2012_logo

Sometimes it’s useful to be able to use a Standard Switch in System Center 2012 with SP1 – Virtual Machine Manager (VMM). When you look at the Hardware Configuration for a VM guest the option to select is greyed out:

VMM Standard switch greyed with highlight 

To configure a Standard Switch select network adapter, and click Browse on the VM Network, and then Clear Selection:

VM Network - clear selection with highlight

Back on the network adapter properties page the Standard Switch selection is no longer greyed out:

VMM Select Standard Switch

Select the required Standard Switch and click OK to commit the configuration change.

System Center 2012 Service Pack 1 – Update Rollup 3 Released

system_center_2012_logo_thumb2

In case you hadn’t seen the announcement already Update Rollup 3 (UR3) has been released. There’s a brief announcement from JC Hornbeck at Microsoft here

The update applies to the following components:

  • App Controller (KB2853227 & KB2823452);
  • Data Protection Manager (KB2853210);
  • Operations Manager (KB2852565);
  • Virtual Machine Manager (KB2858509, KB2858510 & KB2858511)

The full description is available is available under KB2836751 here

What switch are your VM’s using?

system_center_2012_logo

In System Center 2012 SP1: Virtual Machine Manager (VMM) there are two types of virtual switch:

  1. Standard; and
  2. Logical.

Rather than duplicate information that’s already available. MVP Thomas Maurer has a good description of the two switches here. For more detail on networking VMM check out Nigel Cain from Microsoft’s series of posts, starting with Networking in VMM 2012 SP1 – Logical Networks (Part I)

I tend to remove the Standard Switch’s from my Hyper-V hosts in favour of the functionality and consistency provided by Logical Switch’s.

The Challenge

When removing a Standard Switch from a Hyper-V host I received an error advising that the switch was in use by a virtual machine. With over 25 VM’s on the host I wanted a fast way to see what VM was connected to what switch.

The Solution

Executed on the Hyper-V host:

   1: Import-Module Hyper-V

   2: Get-vm | GetVmNetworkAdapter

The SwitchName column in the results below identify that I have two VM’s attached to the Dev switch.

Get-VMNetworkadapter - highlighted

Editing the configuration for those VM’s to a different switch removed the dependencies allowing me to remove the Dev switch from the host.

VMM drops host management IP Address

system_center_2012_logo

If you’ve been implementing System Center 2012 SP1: Virtual Machine Manager you might have noticed a rather unpleasant quirk. If you apply a logical switch to a physical NIC being used for host management (i..e it has a static IP address) you might experience a situation where during VMM pushing the configuration to the host the IP address information is lost.

The Configuration

The logical switch is applied to the physical NIC used for host management, the first vNIC that is added must be the management vNIC with the tick box selected as highlighted in the image below.

Management vNIC - highlighted

The issue

The issue of the management IP address information being dropped was resolved in Update Rollup 2, however there is still a scenario where the symptoms of this problem persist. I say symptoms because it isn’t actually the same issue.

If the host NIC is connected to a port that is trunked to allow connectivity for multiple VLAN’s the static IP address information is applied however the VLAN ID is not applied leaving the host partially configured.

The workaround

The VLAN used for management communication should be a native VLAN on the physical switch. The reason is that hyper-V API’s do not support VLAN configuration on vNIC’s at the time of switch creation. VMM loses connectivity to the host before it can complete the switch operation. As a workaround, can you try setting the VLAN as native VLAN on the switch port and retry the operation. This is a limitation in the current release of VMM.

Thanks to Karthik at Microsoft for explaining the root cause of the issue.

In situations where this isn’t possible I’ve used a separate NIC for host management which I’ve not managed through VMM.

KMS autodiscovery with multiple Activation Servers

Quote

Microsoft currently have two KMS clients: one in the Operating System (since Windows Vista and Server 2008) and most recently one for Office 2010. The environment I’m working in already has an existing KMS server which is registred in DNS and has a channel B activation key installed and managed by the organisations Systems Integrator (SI). As part of our project we planned to implement a second KMS server with the Windows 7 and Office 2010 activation keys installed which would be managed by a different team within the organisation.

As per the TechNet page on choosing the right volumen license key, each channel group activates the downstream group:

Knowing that the channel B key would activate the client OS but not Office, the question I had was:

“How would the KMS clients handle having two activation servers with different activation keys?”

I had a dicussion on a mailing list at Microsoft and was pleased to find out that the client’s autodiscovery behaved as I hoped they would which is:

  • The client queries DNS for a list of KMS servers;
  • The client works through the list of servers until it can successfuly activate; and
  • The successful activation server is cached and tried first on next activation.
  • This was good to confirm as there was concern that the KMS client would activate the OS agianst one server and then fail to activate Office and leave the workstation in an undesireable state.

    DNS was configured using the steps outlined in the Volume Activation Deployment Guide and tested using:

    nslookup
    set q=srv
    ._VLMVS._TCP

    Both KMS servers were returned.

    A quick check of the respective KMS clients (on 64-bit Win7) using the following:

    cscript "C:\Program Files\Microsoft Office\Office14\ospp.vbs" /dhistorykms
    csscript "C:\Windows\System32\slmgr.vbs" /dli

    confirmed that activation was working as expected.

    #Winning ;-)