More about Chimney and TCPOffload in Hyper-V

Here are some definitions that help to clarify the TCPOffload and Chimney thing really well.

I have Don from the Hyper-V networking team to thank for the detail.  Being a hard-core networking guy he knows his packets.

Chimney, also known as TCP Chimney Offload, is the offloading of all IP and TCP processing to the NIC.  This means the NIC receives the packet, processes the headers, generates the ACKs, and keeps all the state.  On the outbound side it receives a block of data from the app, packetizes it, generates the headers, generates the IP layer, and ships it.  Chimney is available on some Broadcom NICs.

Checksum offload is the offloading to the NIC the responsibility for generating the header checksums (outbound side) and verifying the header checksums (inbound side).  No header processing is done other than the checksum processing.  No state is maintained in the NIC.  Nearly all server class NICs support checksum offload.

Large Send Offload (LSO and LSOv2) is the offloading, on the send side, of the packetization and header generation.  The hardware takes a large data block and, using state information from the stack, generates appropriate size data packets (including the headers).  The state is kept in the stack.  LSO and LSO v2 are different versions of this feature.  LSOv2 is supported in R2.

In summary: if you are using Chimney you receive the benefits of the other two.  Disabling Chimney does not disable either LSO/LSOv2 or checksum offload.

Chimney and TCPOffload on Hyper-V

Lately there have been a bunch of issues that folks are running into regarding TCPOffloading on Hyper-V server.

This is not a new issue to Windows Servers.  This is an old tweak that goes back a long time.  And disalbing the TCPOffloading options on Application Servers, Terminal Servers, SQL Servers, etc. has been a pretty common practice for years.

The biggest confusion of late has come form Chimney offloading and TCPOffloading – they are not the same thing.

Chimney is a new feature with Windows 2008 R2 and adds a great deal of performance improvement in a very few cases – it does not kick in all the time or for all traffic.

Chimney and the TCPOffloading that we are referring to is not the same thing.  The cases where Chimney actually kicks in are really pretty small, the vast majority of the time it is never touched.
Leaving Chimney on very rarely has a negative impact.
TCPOffloading (checksum, large send, etc.) can cause problems.  As it does more to affect how packets flow.

TCPOffloading includes the older functions; checksum, large send, etc.

To disable TCPOffload on Hyper-V Server or Server Core:

Check this out:
http://social.technet.microsoft.com/Forums/en-US/winservercore/thread/d0c55df9-a27c-4876-bc5a-8ac7f1b46462

http://msdn.microsoft.com/en-us/library/aa938424.aspx

Chimney and the TCPOffloading that we are referring to is not the same thing.  The cases where Chimney actually kicks in are really pretty small, the vast majority of the time it is never touched.

Leaving Chimney on very rarely has a negative impact.
TCPOffloading (checksum, large send, etc.) can cause problems.  As it does more to affect how packets flow.

To disable Chimney (which you most likely would never need to do):

netsh interface tcp set global chimney=disabled

Terminal Server on Hyper-V

Microsoft is finally (publically) talking about Terminal Server on Hyper-V.

Please note that it isn’t Terminal Server anymore, but “Remote Desktop Services”. This is closer to the way that Citrix talks about desktops and delivery of desktops and applications.

However, in this case it is rather confusing as Remote Desktop Service (without the s) is what has been referred to as the server side of RDP (the protocol) or the remote desktop client.  Just remember, MSFT uses RDP all over the place now.  If it is remote, RDP is involved.

Enough of that, here is the RDS Team blog post I am referring to:

http://blogs.msdn.com/rds/archive/2009/06/24/running-ws08-terminal-server-as-a-virtualized-guest-under-windows-server-2008-r2-hyper-v.aspx

And a snippet:

Running WS08 Terminal Server as a virtualized guest under Windows Server 2008 R2 Hyper-V

One question that the RDS team is asked is whether running Terminal Server virtualized is supported and recommended.  To answer this question we’ve recently conducted some performance testing of this configuration using WS08 Terminal Server running as a guest on Windows Server 2008 R2 Hyper-V.   To answer the first part: this is a supported scenario.

Linux vm from VMware to XenServer the videos

If you have been following, you will note quite a few posts related to importing / migrating Linux virtual machines from VMware to XenServer.

I realize that many folks don’t use XenServer – but the basic steps of repairing after migration apply to Hyper-V just as well as to XenServer – the steps are the same if you want your VM to boot. However, PV enablement on Hyper-V does not exist, you just need to install the vm tools.

Here are the links in case you missed them:

• PV enabling an HVM from VMware on XenServer (CentOS RedHat)
• PV enabling an HVM from VMware on XenServer (SLES and Debian)
• Migrating Debian from VMWare ESX to XenServer
• Migrating SLES from VMWare ESX to XenServer
• Migrating CentOS from VMWare ESX to XenServer
• Migrating RedHat from VMware to XenServer

I have turned three of these into short (less than 10 minutes) video presentations, just to add a bit more information than in the articles.

• Repairing SLES 10 boot loader after import to XenServer
• PV enabling SLES 10 vm after import to XenServer
• PV enabling CentOS VM after import to XenServer