It's no secret that VMware's Virtual Infrastructure platform and ESX server provide excellent network isolation and 802.1Q virtual LAN (VLAN) trunking support. So when virtual network security is a concern, ESX server is an easy choice. While I see ESX as a known commodity, I was curious to see how the other server virtualization platforms stacked up against ESX in terms of network isolation. To be fair, I decided to evaluate the three leading freely available server virtualization platforms:
- VMware Server
- Microsoft Virtual Server 2005 R2
- XenSource XenExpress
I used the following setup and criteria to test isolation:
- Two VMs (Windows Server 2003 OS) bridged to the physical LAN on the same virtual network
- Run a
- WireShark capture in promiscuous mode from VM1
- Initiate network communications from VM2 and from the physical host system while the capture is running on VM1
Note that for each tested virtualization platform, I used the product's default setup.
I must admit that the results of the VMware Server test were shocking. After staging the two VMs, I started the promiscuous WireShark capture on VM1. As a simple test, I opened the web browser on VM2 and connected to SearchServerVirtualization.com. Every frame from VM2 was captured (see Figure 1). I then started a second capture on VM1 and initiated a remote desktop connection from the physical host system to another server on the LAN. Surprisingly, VM1 was able to capture every frame to and from the physical host system (shown in Figure 2). In terms of isolating traffic from one VM to another and from the VMs and the physical host, VMware Server was not able to do either.
Figure 1: VM1's capture of VM2's DNS query (VMware Server)
Figure 2: VM1's capture of RDP traffic to and from the physical host system (VMware Server)
Microsoft Virtual Server
Moving to Microsoft Virtual Server 2005 R2, I ran the exact same tests as I did on VMware Server. Once again, network isolation between the VMs was nonexistent, as VM1 was able to capture all of the frames between VM2 and another server on the LAN. I then decided to see if this behavior would change if I bound VM2 to another virtual switch that was bridged to the same physical NIC on the physical host. Even with each VM on a separate virtual switch that connected to the same physical interface, one VM could capture all traffic going to and from the other VM. However, unlike VMware Server, Microsoft Virtual Server VMs could not capture any traffic going to and from the physical host system. So while there was no network isolation between the VMs bridged to the same physical NIC, network isolation did exist between the VMs and the physical host.
Figure 3: VM1's capture of VM2's DNS query (Microsoft Virtual Server)
As with the previous two server virtualization platforms, I performed identical tests on a XenSource server. This time, I was able to witness a virtual layer 2 switch that fully behaved like a physical layer 2 switch. VM1 was not able to capture any unicast traffic from VM2 (see Figure 4). Furthermore, VM1 could not capture any unicast traffic to or from the physical host. Like VMware ESX Server, Xen Express also supports 802.1Q VLAN trunking, which would bring additional network security and isolation to the outstanding isolation that is already present. More information on Xen 802.1Q VLAN configuration can be found in the Xen Wiki.
Figure 4: Only broadcast traffic was captured on the Xen platform
Virtual switch comparison
Table 1 summarizes the differences in default virtual switch security with VMware Server, Microsoft Virtual Server, and XenSource XenExpress.
|Product||VM traffic isolation||Physical host traffic isolation|
|Microsoft Virtual Server R2||No||Yes|
While the default virtual switch isolation in VMware Server and Microsoft Virtual Server is limited, there are other ways to isolate virtual switch traffic.
One way to isolate traffic is to place each VM on its own virtual network and assign each virtual network to a dedicated physical NIC. Another alternative would be to use network teaming drivers such as the Broadcom Advanced Control Suite. Using the Broadcom approach, for example, would allow you to divide a single physical NIC into multiple virtual NICs on the physical host system, with each virtual NIC assigned to a separate VLAN. You could then bind virtual networks in the server virtualization platform to each Broadcom virtual NIC on the physical host system. While this approach does require more work than is needed with Xen, it would allow VMware Server and Microsoft Virtual Server platforms to realize network isolation that is equal to that of Xen.
About the author:Chris Wolf is a Microsoft MVP for Windows Server – File System/Storage and is a MCSE, MCT, and CCNA. He's a Senior Analyst for Burton Group who specializes in the areas of virtualization solutions, high availability, enterprise storage, and network infrastructure management. Virtualization: From the Desktop to the Enterprise (Apress), Troubleshooting Microsoft Technologies (Addison Wesley) and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press). Reach him at firstname.lastname@example.org
This was first published in February 2007