Windows Server 2012 Hyper-V Supports IPsec Task Offloading

IPsec has been around for a while now. In an ever more security conscious & regulated world you want and/or are required to protect your network communication by
authenticating and encrypting the contents of at least some of your network traffic. Think about SOX and HIPPA and you’ll see that trade or government security requirements are not going anywhere but up for us all. This is not just restricted to military of intelligence organizations.

We’ve seen the ability to offload IPsec traffic to the NIC for a while now. This is great as the IPsec processing is a very CPU intensive workload. Unfortunately it didn’t work for virtual machines . Until now IPsec offloads was only available to host/parent workloads in using Windows Server 2008 R2. The virtualization of high volume network traffic workloads that require encryption means a serious hit on the resources on the host. If you’re willing to pay you might get by by throwing extra host & CPU power at the issue. But what if the load means a single virtual machine with 4 vCPUs can’t hack it? Game over. Sure Windows Server 2012 Hyper-V allows for 32 vCPUs now,  but that is very costly, so this is not a very cost effective solution. So in some cases this lead to those workloads being marked as “unsuited for virtualization”.

But with Windows Server 2012 Hyper-V we get a very welcome improvement, that is the fact that a virtual machine can now also offload the IPsec processing to the physical NIC on the host. That frees up a lot of CPU cycles to perform more application-level work, resulting in better virtualization densities, which means less costs etc.

Let’s take a look where you can set this in the Hyper-V GUI where you’ll find it under the network adaptor /Hardware Acceleration.

image

IPsec offload is also managed by the Hyper-V switch, this controls whether the offloading will be active or not. This is to prevent that the IPsec offload stopping the services if insufficient resources are available. Please do note that IPsec when required in the guest will be done anyway creating an extra CPU burden. So this does not disable IPsec, just the offloading of it. On top of this and in the gravest extreme you can guarantee that IPsec servers can get the resources they need by sacrificing less important guest if needed. by using virtual machine prioritization. The fact that you can configure the number of security associations helps balancing the needs of multiple virtual machines requiring IPsec offload.

To conclude, this wouldn’t be Windows Server 2012 if you couldn’t do all this with PowerShell. Take a look at  Set-VMNetworkAdapter and notice the following parameter:

-IPsecOffloadMaximumSecurityAssociation<UInt32>

This specifies the maximum number of security associations that can be offloaded to the physical network adapter that is bound to the virtual switch and that supports IPSec Task Offload. The thing to notice here is that specify a zero value is used to disable the IPsec Offload feature.

image

Microsoft Private Cloud Computing–The Book

I’d like to mention the launch today of a new book Microsoft Private Cloud Computing written by a group of experts in this subject.

image

Take a look at the authors below. You probably know them from the community efforts they put in and might have read previous materials from them or heard them present.They bring a varied background and a mix of experiences and knowledge to the table needed to tackle any aspect of the private cloud and to a write complete book on the subject: hardware (servers, networking, storage), operating systems, hypervisors and the software stack.

Knowing these people and how busy they are this quite an achievement requiring a serious effort.  The technical reviewing was done by Kristian Nese (Cloud and Datacenter Management MVP,@KristianNese), who’s has been working on private clouds from day one.

Well done guys and thank you!

Windows Server 2012 Cluster Reset Recent Events Feature

There are various small improvements in Windows Server 2012 Failover Clustering that make live a little easier. When playing in the lab one of the things I like to do is break stuff. You know, like pull out the power plug  of a host during a live migration or remove a network cable  for one or more of the networks, flip the power of the switch off and on again, crash the vmms.exe process and other really bad things …Smile Just getting a feel for what happens and how Windows 2012 & Hyper-V responds.

As you can imagine this fills up the cluster event logs real fast. It also informs you in that you’ve had issues in the past 24 hours. Those recent cluster events could not be cleared or set to “acknowledged” up to Windows 2008 R2 except by deleting the log files. Now this has to be done on all nodes and is something you should not do in production and is probably even prohibited. There are environments where this is indeed a “resume generating” action. But it’s annoying that you can leave a client with a healthy looking environment after you have fixed an issue.

image

For the lab or environments where event log auditing is a no issue I used to run a little script that would clear the event logs of the lab cluster nodes not to be dealing with to much noise between tests or to leave a GUI that represents the healthy state of the cluster for the customer.

This has become a lot easier and better in Windows Server 2012 we now have a feature for this build in to the Failover Cluster Manager GUI. Just right click the cluster events and select “Reset Recent Events”.

image

 

The good thing is this ignores the recent events before “now” but it does not clear the event log. You can configure the query to show older events again. This is nice during testing in the lab. Even in a production environment where this is a big no-no, you can’t do this you can now get rid of noise from previous issues,focus on the problem you working on or leave the scene with a clean state after fixing an issue without upsetting any auditors.

image

Configuring Jumbo Frames with PowerShell in Windows Server 2012

During lab and test time with Windows Server 2012 Hyper-V some experimenting with PowerShell is needed to try and automate actions and settings. One of the thing we have been playing around with was how to enable and configure jumbo frames.

Many advanced features like Large Send Offload have commandlets of their own (Enable-NetAdapterLso etc.), but not all them and jumbo frames is one of the latter. For those advanced features you can use the NetAdapterAdvancedProperty commandlets (Network Adapter Cmdlets in Windows PowerShell). You can than set/enable those features via the registry keywords & values. Let’s say we want to enable jumbo frames on a virtual  adapter named “ISCSI” in a VM.

image

To know what values to use you can run:

Get-NetAdapterAdvancedProperty -Name ISCSI

image

As you can see Jumbo Packet has a RegistryValue of 1514 and a DisplayValue  of “Disabled”. You can also see that the RegistryKeyword to use to enable and configure jumbo frames is “*JumboPacket”. So to enable jumbo frames you run the following command:

Set-NetAdapterAdvancedProperty -Name “ISCSI” -RegistryKeyword “*JumboPacket” -Registryvalue 9014

image

The RegistryValue is set to 9014 and the DisplayValue is set to “9014 Bytes”, i.e. it’s enabled.

If you type in an disallowed value it will list the accepted values. Please note also that these can differ from NIC to NIC depending on what is supported. Some will only show 1514, 4088, some will show 1514, 4088, 9014.

image

Now to disable jumbo frames you just need to reset the RegistryValue back to 1514

Set-NetAdapterAdvancedProperty -Name “ISCSI” -RegistryKeyword “*JumboPacket” -Registryvalue 1514

The result of this command can be seen in the picture below. DisplayName Jumbo Packet has a DisplayValue of “Disabled” again.

image

Let’s say you want to enable jumbo frames on all network adapters in a host you can run this:

Get-NetAdapterAdvancedProperty -DisplayName “Jumbo Packet” | Set-NetAdapterAdvancedProperty –RegistryValue “9014

Or run

Set-NetAdapterAdvancedProperty -Name * -RegistryKeyword “*JumboPacket” -Registryvalue 9014

I didn’t notice much difference in speed testing this with measure-command.

If you mess things up to much and you want to return all DisplayName settings to a well known status, i.e. the defaults you can run:

Reset-NetAdapterAdvancedProperty –Name SCSCI –DisplayName *

If you’ve just messed around with the jumbo frame settings run

Reset-NetAdapterAdvancedProperty -Name ISCSI –DisplayName “Jumbo Packet”

Or you can do the same for all network adapters:

Reset-NetAdapterAdvancedProperty –Name * –DisplayName “Jumbo Packet”

There you go, you’re well on your way doing the more advanced configurations of your network setup. Enjoy!