Testbeds

Figure 3: VNET test configurations for the local area (a) and the wide area (b). Local area is between two labs in the Northwestern CS Department. Wide Area is between the first of those labs and a lab at Carnegie Mellon.

Although VNET is targeted primarily for wide-area distributed computing, we evaluated performance in both a LAN and a WAN. Because our LAN testbed provides much lower latency and much higher throughput than our WAN testbed, it allows us to see the overheads due to VNET more clearly. The Client, Proxy, and Host machines are 1 GHz Pentium III machines with Intel Pro/100 adaptors. The virtual machine uses VMware GSX Server 2.5, with 256 MB of memory, 2 GB virtual disk and RedHat 7.3. The network driver used is vmxnet.

Our testbeds are illustrated in Figure 3. The LAN and WAN testbeds are identical up to and including the first router out from the Client. This portion is our firewalled lab in the Northwestern CS department. The LAN testbed then connects, via a router which is under university IT control (not ours), to another firewalled lab in our department which is a separate, private IP network. The WAN testbed instead connects via the same router to the Northwestern backbone, the Abiline network, the Pittsburgh Supercomputing Center, and two administrative levels of the campus network at Carnegie Mellon, and finally to an lab machine there. Notice that even a LAN environment can exhibit the network management problem. It is important to stress that the only requirement that VNET places on either of these complex environments is the ability to create a TCP connection between the Host and Proxy in some way.

We measured the latency and throughput of the underlying ``physical'' IP network, VMWare's virtual networking options, VNET, and of SSH connections:

$\bullet$

Physical: VNET transfers Ethernet packets over multiple hops in the underlying network. We measure equivalent hops, and also end-to-end transfers, excepting the VM.

$\bullet$

$Local \leftrightarrow Host$: Machine on the Host's LAN to/from the Host.

$\bullet$

$Client\leftrightarrow Proxy$: Analogous to the first hop for an outgoing packet in VNET and the last hop for an incoming packet.

$\bullet$

$Host \leftrightarrow Proxy$: Analogous to the TCP connection of a Handler, the tunnel between the two VNET servers.

$\bullet$

$Host \leftrightarrow Client$: End-to-end except for the VM.

$\bullet$

$Host \leftrightarrow Host$: Internal transfer on the Host.

$\bullet$

VMWare: Here we consider the performance of all three of VMWare's options, described earlier.

$\bullet$

$Host \leftrightarrow VM$: Host-only networking, which VNET builds upon.

$\bullet$

$Client \leftrightarrow VM$ (Bridged): Bridged networking. This leaves the network administration problem at the remote site.

$\bullet$

$Client \leftrightarrow VM$ (NAT): NAT-based networking. This partially solves the network administration problem at the remote site at the layer 3, but creates an asymmetry between incoming and outgoing connections, and does not support VM migration. It's close to VNET in that network traffic is routed through a user-level server.

$\bullet$

VNET: Here we use VNET to project the VM onto the Client's network.

$\bullet$

$Client \leftrightarrow VM$ (VNET): VNET without SSL

$\bullet$

$Client \leftrightarrow VM$ (VNET+SSL): VNET with SSL

$\bullet$

SSH: Here we look at the throughput of an SSH connection between the Client and the Host to compare with VNET with SSL.

$\bullet$

$Host \leftrightarrow Client$ (SSH)