Citrix was in to present and discuss the technical merits of XenDesktop. I am considering VDI, which requires XenDesktop Enterprise and their provisioning server. Citrix's technology sounds impressive. Still, the question looming large in my mind is what XenDesktop + Provisioning brings to the table that Hyper-V + SCCM lacks. It is impressive yet the proof is in the pudding. I may do a pilot Q1 or Q2 2009.

I am seeing an odd issue with Hyper-V vms on pass-thru disks. Say an event occurs on the storage array that causes the disks on the Hyper-V server go offline momentarily. They can be brought back online afterwards. Hyper-V then loses the handle on the disk. There are four broad categories of symptoms that then occur:

1) Very broadly speaking, if the disk contains server-specific information such as a paging file, then the server behaves erratically when it goes offline.

2) If the disk in question goes offline and it contains the vm definition files (.bin, .vsv), then the vm disappears from the Hyper-V console.

3) If the disk goes offline and it contains vm disks (.vhd), then the vm in question crashes.

4) If the disk is directly mapped to a vm as a host resource, then the vm is shutdown. Sometimes the state is saved. The settings show that the physical disk cannot be found. The vm’s saved state has to be deleted and then the physical disks reselected in the vm settings dialog.

I am still troubleshooting. More details to follow.

VMware's ESX KO's a roughly built Hyper-V package

"When the dust settled in the lab after two long months of testing Microsoft's Hyper-V and VMware's ESX in the areas of performance, compatibility, management, and security, it all boiled down to two issues: experience and religion."

I spent quite a bit of time with both VMware and Hyper-V. I agree with some of what is in this article. VMWare is a more mature product and hence its vm management tools are more robust. VMWare also supports a wider array of non-Windows OS vms. All true. Yet all of what I am virtualizing at this point is Windows, and all of the management I need can be done thru the Hyper-V UI. Hence the question comes down, in my mind, to performance over dollars. In the bang for the buck factor, my bet is still on Hyper-V.

The article in CIO magazine, How Microsoft Hyper-V Helped My IT Shop Revamp Disaster Recovery, details my efforts to reorganize network and recovery operations around storage and server virtualization. It also mentions the year-long virtualization study that I did in 2007/2008.

Using virtualization as a disaster recovery strategy can in one of two scenarios:

First scenario is vm to vm. Put a hypervisor at the production site and another at the recovery site. Run the production server in a vm. Replicate the vm drives to the recovery site. During a disaster, boot the vm up on the recovery hypervisor.

The second scenario is bare metal to vm. Put a physical server running on bare metal at the production site. Stage the physical server with the necessary vm drivers (in Hyper-V, this is called the Integration Components.) Put a hypervisor at the recovery site. Replicate the disks. During a disaster, boot the server up as a vm on the recovery hypervisor. The second scenario requires block level replication and the ability for the hypervisor to read native disks. If both of these requirements are not possible, an alternative solution exists. This is to restore the production server into a vm using software that supports VM P2V DR. Examples of this software include Acronis, Arcserve, and Backup Exec. The downside is that this option takes significantly longer.

Some quick thoughts on using server virtualization for disaster recovery. The key metrics in using VMs for DR is RTO and RPO. These are defined during the BIA process. One question that I wrestled with was how to get a near time RTO (within minutes before the disaster) and a rapid RPO (within 1hours after the disaster).

Traditional P2V techniques rely on a live system or a nightly backup, so RTO is up to 24 hours. Traditional P2V also relies upon writing the data back out into virtual disks, so the RPO for our average server was up to 7 hours. We addressed these challenges by keeping the storage on a backend SAN and pointing the disk into the VM in the event of a disaster. The RTO is then near time and the RPO is an hour or less.

The DR strategy requires native NTFS disk access and SAN support. Both VMware ESX and Hyper-V support this type of DR. Linux based hypervisors such as Xen do not.

I am testing out XenServer for server virtualization, and Acronis for physical-to-virtual conversions. When booting on the Acronis restore CD, the vm displays:

cirrus-compatible VGA is detected
Processor 1: Xen(R) Virtual CPU
XS Virtual IDE Controller  Hard Drive (16384MB)
Unknown device
Unknown device
XS Virtual ATAPI-4  CD-Rom/DVD-Rom

Boot device: CD-Rom - success.
Starting Caldera DR-DOS...
HIMEM.SYS: Cannot control address line A20.

Caldera DR-DOS 7.03
Copyright (c) 1976, 1998 Caldera, Inc. All rights reserved.

It then hangs with the processor consuming 100% of the resources. I notice the same behavior when booting from a DOS 6.22 disk with Himem.sys loading, even if I specify /a20control:off.  I found an article from Microsoft that describes the problem. Submitted it to Acronis to get a fix. They wrote back “We have confirmed this behavior with the Xen Virtualization platform with the DR process. Right now it has been logged as a defect in our bugtracker. Right now I do not have an ETA on this being resolved.”

 The "Unable to control A20 Line" error message
http://support.microsoft.com/kb/73713

There are two workarounds for this problem:

Add the /M:x switch to the HIMEM.SYS line in the CONFIG.SYS file, where x is number from the valid range of 1-14 and 16, and then restart your computer. For example: DEVICE=C:\DOS\HIMEM.SYS /M:1

Upgrade your computer's BIOS or contact your computer vendor for help with the modification of your CMOS settings. You may need to disable a FastGate (or similar) option.

The A20 line is the start of the first 64K of extended memory, known as the high memory area (HMA). The HIMEM.SYS device driver must control the A20 line to manage extended memory. The HIMEM.SYS driver reports the error if it incorrectly identifies the extended memory handling mechanism of the computer or if the handling method of the computer's BIOS is unknown.