Windows Server Virtualization unwrapped
Last week, Microsoft released Windows Server 2008 Release Candidate 0 (RC0) to a limited audience and, hidden away in RC0 is an alpha release of Windows Server Virtualization (the two updates to apply from the %systemroot%\wsv folder are numbered 939853 and 929854).
I’ve been limited in what I can write about WSV up to now (although I did write a brief WSV post a few months back); however at yesterday’s event about creating and managing a virtual environment on the Microsoft platform (more on that soon) I heard most of what I’ve been keeping under wraps presented by Microsoft UK’s James O’Neill and Steve Lamb (and a few more snippets on Tuesday from XenSource), meaning that it’s now in the public domain and I can post it here (although I have removed a few of the finer points that are still under NDA):
- Windows Server Virtualization uses a totally new architecture – it is not just an update to Virtual Server 2005. WSV is Microsoft’s first hypervisor-based virtualisation product where the hypervisor is approximately 1MB in size and is 100% Microsoft code (for reliability and security) – no third party extensions. It is no more than a resource partition in order to provide access to hardware and not opening the hypervisor to third parties provides protection against theoretical hyperjacking attacks such as the blue pill (where a rootkit is installed in the hypervisor and is practically impossible to detect).
- WSV requires a 64-bit CPU and hardware assisted virtualisation (Intel VT or AMD-V) enabled in the BIOS (often disabled by default).
- There will also be two methods of installation for WSV:
- Full installation as a role on Windows Server 2008 (once enabled, a reboot “slides” the hypervisor under the operating system and it becomes virtualised).
- Server core role for the smallest and most secure footprint (with the advantage of fewer patches to apply).
- Initial builds require a full installation but WSV will run on Server Core.
- The first installation becomes the parent, with subsequent VMs acting as children. The parent has elevated permissions. The host/guest relationship no longer applies with the hypervisor model; however if the parent fails, the children will also fail. This may be mitigated by clustering parents and using quick migration to fail children over to another node.
- Emulated drivers are still available with wide support (440BX chipset, Adaptec SCSI, DEC Ethernet, etc.) but they have a costly performance overhead with multiple calls back and forth between parent and child and context switches from user to kernel mode. WSV also includes a synthetic device driver model with virtual service providers (VSPs) for parents and virtual service clients (VSCs) for children. Synthetic drivers require no emulation and interact directly with hardware assisted virtualisation, providing near-native performance. XenSource drivers for Linux will be compatible with WSV.
- There will be no USB support – Microsoft see most USB demand for client virtualisation and although USB support may be required for some server functions (e.g. smartcard authentication), this will not be provided in the initial WSV release
- Microsoft views memory paging to be of limited use and states that over-committing RAM (memory ballooning) is only of practical use in a test and development environment. Furthermore it can actually reduce performance where applications/operating systems attempt to make full use of all available memory and therefore cause excessive paging between physical and virtual RAM. Virtual servers require the same volumes of memory and disk as their physical counterparts.
- In terms of operating system support, Windows Vista and Server 2008 already support synthetic device driver (with support being added to Windows Server 2003). In response to customer demand, Microsoft has worked with XenSource to provide a platform that will allow both Linux and Windows workloads with near native performance though XenSource’s synthetic device drivers for Linux. Emulation is still available for other operating systems.
- Virtual Server VMs will run in WSV as the VHD format is unchanged; however virtual machine additions will need to be removed and replaced with ICs (integration components) for synthetic drivers using the integration services setup disk (similar to virtual machine additions, but without emulation) to provide enlightenment for access to the VMbus.
- Hot addition of resources is not included in the initial WSV release.
- Live migration will not be included within the first WSV release but quick migration will be. The two technologies are similar but quick migration involves pausing a VM, writing RAM to a shared disk (saving state) and then loading the saved state into RAM on another server and restarting the VM – typically in around 10 seconds – whereas live migration copies the RAM contents between two servers using an iterative process until there are just a few dirty pages left, then briefly pausing the VM, copying the final pages, and restarting on the new host with sub-second downtime.
- WSV will be released within 180 days of Windows Server 2008.