Virtual Learning Lab Hypervisor Comparison

This article discusses the top requirements for a virtualized lab management system, as promised in my previous article about Virtual Lab Requirements. This is not a datacenter view on the different technologies.  I am not overly concerned about the "performance" of a given hypervisor, nor am I concerned about the management tools supporting the hypervisor. Our focus is building virtual educational lab infrastructure.  

 

Here are our top requirements for virtualized lab management: 

1. Remote Control Access
2. Student/Instructor Collaboration
3. Virtual Machine Control/Build API
4. Network Control
5. OS Support 
6. BIOS Clock Control
7. Virtual Machine Storage
   

The software used to provision the labs is called a hypervisor and its associated management software.  For each component that I discuss I am going to call out some of the strengths/weaknesses with Microsoft Virtual Server, Microsoft Hyper-V, VMWare Server, and Oracle's VirtualBox.  I haven't included XEN in this list of comparisons because the lack of an obvious remote control access technology discouraged me.  I looked at XEN quite a while back when we were having problems with the BIOS Clock Control and Microsoft Virtual Server, until we identified a hack to solve it.   I returned to look at XEN two years ago to solve our 64bit Guest OS problem, but it just wasn't a good fit.  Truth be known, I believe a type 2 hypervisor is the best choice as a training platform because of its portability and flexibility.    

Remote Control Access

In most scenarios duplicate lab machines are active at the same time.  This requires network isolation to eliminate errors from duplicate IP addresses and prevent people from interfering with each other's lab.  Remote control to the guest OS isn't really practical because you don't want to rely on configuring the Guest OS for remote control, and if you are doing many different operating systems, it becomes a burden.  Remote control needs to be done at the Guest OS console/BIOS level to control all aspects of a virtual machine and to provide consistent access regardless of the Guest OS. 

Remote control access is one of the pieces proprietary vendors guard to promote/protect their technology stack.  

 

• VirtualBox has a built-in VRDP server which allows direct RDP access to the guest OS console/BIOS level.
• Version 3.2 can optimize remote control by redirecting video streams from the guest to the RDP client (needs RDP 7). Video frames are compressed using the JPEG algorithm allowing a higher compression ratio than standard RDP bitmap compression methods.
• VirtualBox's reliance on generic RDP allows connectivity from any platform which has an RDP client (pretty much everything, even the iPAD has one).  
• no additional infrastructure required
• Microsoft Virtual Server (Grokworx's current lab platform) uses a VMRC control which is a proprietary derivative of VNC to achieve console level access.
• Requires a connection from a Microsoft Windows OS. 
• Microsoft Hyper-V can provide guest console access
• Requires a connection from a Microsoft Windows OS. 
• VMWare Server has a built in VNC server which gives you direct guest console access 
• VNC can be used by pretty much everything
• VMWare View/ESX can provide remote control to the Guest OS through their VMWare View client plus infrastructure.
• Requires additional infrastructure/licenses
• open source version which can run on a variety of different client computers. 
• It is too bad you can't use the Open View client to make a direct connection to an ESXi host. 

Winner:  VirtualBox, the ability to connect to the guest OS console from any type of client with the performance of RDP.  The ability to do redirected video is a very nice plus.

Note:  There is one downside to the VirtualBox RDP option and that is each virtual machine needs to have a unique port and it isn't firewall friendly.  Down the road we are going to look at connection brokers like No Machine (www.nomachine.com) which could help solve this problem.  VMWare View does provide a connection broker service as part of its stack.  

Student/Instructor Collaboration

Simultaneous access to the same console enables two scenarios:

• student lab assistance
• class level demos.

During lab time the instructor should be able to pull a student to the side and offer them one-on-one assistance similar to the physical classroom experience.  For demos we want the instructor to leverage the virtual lab infrastructure.  There is a scenario where instructors can use desktop sharing and share out a local copy of the software, but this is an unnecessary burden on the instructor and they may not have the hardware or software required to run the labs properly. 

 

• VirtualBox has a per VM setting which allows multiple connections
• Microsoft Virtual Server has a server setting which allows multiple connections
• Microsoft Hyper-V doesn't allow simultaneous connections because of a "security" precaution which can not be changed.  For some reason the Hyper-V team has decided to do its best to remove any functionality required for training.
• VMWare Server allows simultaneous connections
• VMWare View/ESX allows simultaneous connections

Winner:  They are all winners; except for Hyper-V, which is an epic FAIL. 

Virtual Machine control/build API

A Lab system should be able to support an "any lab, any time" mantra, which means you don't need to pre-build a student's lab before it is being requested.  When it is being requested, you need to be able quickly build and deploy the image template for use.  A good definition of quickly means a student should have something ready to  go within 60 seconds from the time they requested it.  After the time has expired for the student the resources should be released back into the pool for the next student to use. 

 

• VirtualBox has several different ways to control the virtual machine environment
• Web Services
• XPCOM
• Command line
• Microsoft Virtual Server uses Microsoft COM
• Microsoft Hyper-V uses Microsoft WMI
• VMWare 
• Command Line
• VIX API supports management of VMware Server and Virtual Infrastructure. Bindings are provided for C, Perl, and COM (Visual Basic, VBScript, C#).

Winner:  VirtualBox and VMWare both have a lot of connectivity options across platforms to interface the lab management control.  

Network Control

A lab environment needs to simulate real-world scenarios.  This means students may have complex lab configurations.  In a recent scenario we ran for Microsoft  Live Communication Server each student had seven virtual machines over three different network segments.  Obviously, this is an extreme case, but in the real world you frequently have more than one network segment; especially with any Internet configuration in the mix.  

 

• VirtualBox networking stack is very flexible by dynamically creating new networks as unique names are added to the virtual machine configuration. 
• Supports Virtual Distributed Ethernet (VDE) (Linux hosts only):  http://www.virtualbox.org/manual/ch06.html#networkingmodes
• Emulates different physical Ethernet cards to provide one that will work with your guest OS:  AMD PCNet PCI II, AMD PCNet FAST III, Intel PRO/1000 MT Desktop, Intel PRO/1000 T Server, Intel PRO/1000 MT Server and a Paravirtualized network adapter.
  
• Microsoft Virtual Server provides a viable option.  Dynamic networks can be created, and then attached to the Virtual Machine.  This is a two step process; where VirtualBox does this in a single step.
• Microsoft Hyper-V is similar to Microsoft Virtual Server
• VMWare Server
• Limited to only 8 virtual networks per physical server
• This is a show stopper for lab infrastructure
• VMWare View/ESX
• not sure what the network limitation is for VMWare View

Winner:  VirtualBox, because of the dynamic management of the virtual networks and extensive physical Ethernet card emulation. 

OS Support 

We want our lab system to run as many operating systems as possible based on the x86 architecture.  Having 64bit support is important, because newer Windows Server operating systems require 64bit support.

 

• VirtualBox is a type-2 hypervisor which means it runs on top of another operating system (which is called the Host OS).  
• 64bit guest support
• Host OS support:  Windows, Linux, Solaris, OpenSolaris, BSD, and OS X
• Guest OS support:  Windows, Linux, Solaris, OpenSolaris, OS X (yes it runs OS X inside a VM as well)
• Pretty much runs anything x86 based
• Microsoft Virtual Server
• only 32 bit guest support
• Host OS support:  Windows Server/XP/Windows 7 (with some prodding)
• Guest OS Support:  Windows, it says it supports OS's like Linux and Solaris but real-world shows otherwise
• Microsoft Hyper-V  is a type 1 hypervisor which means it runs directly on the host hardware along with the configured operating system, which is Window Server 2008 (R2)
• 64bit guest support
• Host OS support:  Windows Server 2008 and Windows Server 2008 R2
• Guest OS support:  http://www.microsoft.com/windowsserver2008/en/us/hyperv-supported-guest-os.aspx
• I am skeptical of it running anything other than Windows without some pain
• VMWare Server  (type 2 hypervisor)
• 64bit guest support
• Host OS support:  Windows and Linux
• Guest OS support:  Windows, Linux, Solaris
• VMWare View/ESX is a type 1 hypervisor inside VMWare's operating system
• 64 bit support
• Guest OS:  great list of supported operating systems from Windows, Linux, BSD, and Unix
  

Winner:  VirtualBox and VMWare are both committed to supporting as many operating systems as possible.

BIOS Clock Control

There are three good reasons why we don't want to rely on the current time and preset the bios clock before startup.  

 

1. Labs are designed to run in a non-production environment, which means, you are going to run some software which is designed to "expire".  The worst thing that can happen is starting a class and finding out your software has expired so the labs are useless.
2. Student activities which rely on a point in time reference point.  Let's say we are going to do a query on the activity over the past 30 days.  If you don't set the reference time, then the past 30 days will continually change.  
3. Some software like Microsoft Active Directory's replication system requires the machine to be active at least every 60 days (AD tombstone lifetime). 

• VirtualBox supports setting the bios clock on startup
• Microsoft Virtual Server allows setting the bios clock
• Microsoft Hyper-V
• For some reason that defies logic, the Hyper-V team has decided to prevent people from controlling the BIOS clock.  
• It may be piracy related, after all don't all pirates use virtualization and continually reset the clock back.  
• VMWare supports setting the bios clock

Winner:  Similar to the Student/Instructor collaboration, they are all winners; except for Hyper-V, which is an epic FAIL. 

Virtual Machine Storage

The last item, and the most complex part, is storing the virtual machine disks.   Being able to run "any lab, any time" and quickly provisioning virtual machines on request from students, while providing sufficient disk IO is a challenging puzzle.

• VirtualBox provides a lot of different storage options
  
• Support for vhd, vdi and vmdk files and raw disk partitions
  
• Differencing disks
  
• no programmatic support for managing differencing disks, which was initially a show stopper for us with VirtualBox because we wanted to do things the same way as Virtual Server (see blow in the Notes).  
  
• Directly connect iSCSI targets to the VM (unique to VirtualBox and a major win)
• Microsoft Virtual Server
• Support for vhd, raw disk access, direct attached storage, SAN, and locally attached iSCSI volumes.
  
• Support for shared storage on CIFS/SMB
  
• Differencing disks
• Hyper-V
• Support for vhd and raw disk access, direct attached storage, SAN, and locally attached iSCSI volumes.
  
• Differencing disks
• Doesn't support storage of disk on CIFS/SMB shared storage
• VMWare
• VMDK disk files and raw disk partitions
• support for shared storage on NFS shares, direct attached storage, SAN, and locally attached iSCSI volumes.
• Differencing disks
  

Winner:  VirtualBox, the ability to directly connect an iSCSI target to a VM is a huge win for dynamic lab provisioning and allowing students to "save" their lab work.  

Note:  Our current design on Microsoft Virtual Server solves a lot of problems, except for easy lab publishing and allowing students to save their work. Right now we use a DFS read-only share to store the base vhd file load balanced across a couple of file servers with lots of RAM for cache to provide the read IO.  When we dynamically build a virtual machine, we create a local differencing disk to handle all of the writeable disk IO.  The local server is configured with a raid10 on small, fast 15k disks to handle the write IO.  When the lab is completed, the local differencing disks are wiped. 

See you next time when I go into more details around VirtualBox and storage management. If you want to view my other articles please visit http://blog.grokworx.com or www.grokmarket.com.