2009
11.26

Hans Vredevoort asked what sort of network speed comparisons I was getting with Windows Server 2008 R2 Hyper-V.  With W2008 R2 Hyper-V you get new features like Jumbo Frames and VMQ (Virtual Machine Queue) but these are reliant on hardware support.  Hans is running HP G6 ProLiant servers so he has that support.  Our current hardware are HP G5 ProLiant servers.  I decided this was worth a test.

I set up a test on our production systems.  It’s not a perfect test lab because there are VM’s doing their normal workload and thing like continuous backup agents running.  This means other factors that are beyond my control have played their part in the test.

The hardware was a pair of HP BL460C “G5” blades in a C7000 enclosure with Ethernet Virtual Connects.  The operating system was Windows Server 2008 R2.  The 2 virtual machines were also running Windows Server 2008 R2.  I set them up with just 512MB RAM and a single virtual CPU.  Both VM’s had 1 virtual NIC, both in the same VLAN.  They had dynamic VHD’s. The test task would be to copy the W2008 R2 ISO file from one machine to the other.  The file is 2.79 GB (2,996,488 bytes) in size.

There were three tests.  In each one I would copy the file 3 times to get an average time required.

Scenario 1: Virtual to Virtual on the Same Host

I copied the ISO from VM1 to VM2 while both VM’s were running on host one.  After I ran this test I realised something.  The first iteration took slightly longer than all other tests.  The reason was simple enough – the dynamic VHD probably had to expand a bit.  I took this into account and reran the test.

With this test the data stream would never reach the physical Ethernet.  All data would stay within the physical host.  Traffic would route via the NIC in VM1 to the virtual switch via its VMBus and then back to the NIC in VM2 via its VMBus.

The times (seconds) taken were 51, 55 and 50 with an average of 52 seconds.

Scenario 2: Virtual to Virtual on Different Hosts

I used live migration to move VM2 to a second physical host in the cluster.  This means that data from VM1 would leave the virtual NIC in VM1, traverse VMBus and the Virtual Switch and physical NIC in host 1, the Ethernet (HP C7000 backplane/Virtual Connects) and then the physical NIC and virtual switch in physical host 2 to reach the virtual NIC of VM2 via its VMBus. 

I repeated the tests.  The times (seconds) taken were 52, 54 and 66 with an average of 57.333 seconds.  We appear to have added 5.333 seconds to the operation by introducing physical hardware transitions.

Scenario 3: Virtual to Virtual During Live Migration

With this test we would start with the scenario in the first set of tests.  We would introduce Live Migration to move VM2 from physical host 1 to physical host 2 during the copy.  This is why I used on 512MB RAM in the VMs; I wanted to be sure the live migration end-to-end task would complete during the file copy.  The resulting scenario would have VM2 on physical host 2, matching the second test scenario.  I want to see what impact Live Migration would have on getting from scenario 1 to scenario 2.

The times (seconds) taken were 59, 59 and 61 with an average of 59.666 seconds.  This is 7 seconds slower than scenario 1 and 2.333 seconds slower than scenario 2.

Note that Live Migration is routed via a different physical NIC than the virtual switch.

Scenario 4: Physical to Physical

This time I would copy the ISO file from one parent partition to another, i.e. from host 1 to host 2 via the parent partition NIC.  This removes the virtual NIC, virtual switch and the VMBus from the equation.

The times (seconds) taken were 34, 28 and 27 with an average of 29.666 seconds.  This makes the test scenario physical data transfer 22.334 seconds faster than the fastest of the virtual scenarios (scenario 1).

Comparison

Scenario Average Time Required (seconds)
Virtual to Virtual on Same Host

52

Virtual to Virtual on Different Hosts

57.333

Virtual to Virtual During Live Migration

59.666

Physical to Physical

29.666

Waiver

As I mentioned, these tests were not done in lab conditions.  The parent partition NIC’s had no traffic to deal with other than an OpsMgr agent.  The Virtual Switch NIC’s had to deal with application, continuous backup, AV and OpsMgr agent traffic.

It should also be noted that this should not be a comment on the new features Windows Server 2008 R2 Hyper-V.  Using HP G5 hardware I cannot avail of the new hardware offloading improvements such as VMQ and Jumbo Frames.  I guess I have to wait until our next host purchase to see some of that in play!

This is just a test of how things compare on the hardware that I have in a production situation.  I’m actually pretty happy with it and I’ll be happier when we can add some G6 hardware.

1 comment so far

Add Your Comment

Get Adobe Flash player