xsummary.com

Alessandro Perilli of Virtualization.info:

Exactly one year ago two well-known virtualization experts Ruben Spruijt (Solution Architect and CTO at PQR) and Jeroen van de Kamp (Enterprise Architect and CTO at Login Consultants) releasedan independent, non-sponsored performance analysis comparing ESX 3.5, XenServer 5.0 and Hyper-V 2008.

The benchmark, specifically designed to measure desktop virtualization workloads (served by Terminal Services and VDI platforms), was so valid that Citrix decided to embrace the Virtual Reality Check methodology to measure XenDesktop 4 performance.

Twelve months later the two are back with a new comparison. This time they put side by side Citrix XenServer 5.5, Microsoft Windows Server 2008 R2 Hyper-V and VMware vSphere 4.0 Update 1, comparing them against their new workload simulator Virtual Session Indexer (VSI) 2.0.

The most interesting thing is that all tests were performed on HP hardware equipped with the new Intel Xeon 5500 Series CPUs (codename Nehalem), and compared to Virtual Reality Check 1.0 results obtained on previous generation processors.
Performance are almost doubled with both XenServer and vSphere, and with Hyper-V R2, performance are up 154%.

View Results

For whatever reason, my ability to successfully create bootable ESXi USB keys has been reliant on Mac OSX. As many know, OS X runs a flavor of BSD under the hood. Because of this, OSX has some great UNIX tools, one of those being dd. Unfortunately, Windows does not ship with an equivalent program. This is where WinImage comes in.

Here are the simple steps.

1. Open the ESXi ISO using 7-zip. Double click image.tgz. KEEP DOUBLE CLICKING UNTIL YOU GET TO THE .dd file.
   
2. Drag the .dd file from 7-zip to the Desktop. 7-zip will extract the .dd file (this can take a couple of minutes)
3. Open WinImage (run as Administrator for Vista/Win7). From the menu, Disk >> Use Removable Disk J: – or whatever drive letter the destination USB key is on. Finally, from the menu Disk >> Restore virtual hard disk image on physical drive. NOTE: By default, you may not see the .dd file in the Open File dialog box. Select all files and the .dd file should appear. That’s it.

Create the Shared Disk

1. Create a VM (don’t worry we are going to delete it, we just need the disk) 
1. Name: “VMCLUSTERSTORAGE”
2. Guest Operating System: "Windows 2003 Server” (doesn’t really matter)
3. Virtual Disk:
   1. Size: whatever
   2. DO NOT Check Allocate and commit space on demand (shared disks need to be thick NOT thin)
   3. Check Support clustering features such as Fault Tolerance (required if you want to share the disk)
4. Right click new VM Remove from Inventory
5. Browse Datastore >> Browse to new VM >> Delete all files but the VMDK file

Attach the Shared Disk to each VM

1. On each VM – Edit Settings >> Add >> Hard Disk >> Use Existing >> Browse to shared VMDK file
2. Choose new SCSI bus i.e. 1:0, 2:0,3:0, etc.
3. Change SCSI Controller to Paravirtual

Configure each Windows 2008 Server VM

1. My Computer >> Manager
2. Right click disk >> Online >> Initialize Disk >> Format >> NTFS
3. Install File Services Role on each Windows 2008 Server VM
4. Install Failover Clustering on each Windows 2008 Server VM
5. Open Failover Clustering Management
6. Validate each Windows 2008 Server VM
7. Create Cluster
8. Add Application / Services

VMWare ESX(i) VS. Microsoft Hyper-V. This comparison table, albeit bias, is BRUTAL. In some cases the VMWare writer doesn’t even soften the punch with some corporate dialect. The writer might as well say “You suck. We are better. So there!” I like it!!

• Hyper-V only supports Novell as a guest OS. No Linux.
• Hyper-V’s third-party hardware drives not written and reviewed for virtualization
• 4 processors ONLY Windows 2008 Server guest OSs
• No “native” NIC teaming
• No overcommitted on memory resources

Features	VMware ESX/ESXi 3.5	Microsoft Hyper-V RTM	Hypervisors Comparison
Thin and Purpose-Built Architecture
Small disk footprint			Hyper-V is fully dependent on a general-purpose OS(Windows 2008). Microsoft’s best-case disk footprint is 2.6GB (Hyper-V + Server Core), which is more than 80x times larger than ESXi’s (32MB). Hyper-V + Windows Server 2008 is even larger with a footprint of ~10GB. The large size of both options creates an easier target for security attacks and increasing performance overhead. Also, patches to Windows Server 2008 / Server Core will affect Hyper-V guests. VMware ESXi on the other hand is a fully functional hypervisor in a 32MB disk footprint, which reduces the risk of downtime and increases reliability.
OS independence			Hyper-V depends on Windows 2008 and is consequently biased towards Windows guests when it comes to making full use of the available hardware resources: Hyper-V support for non-Windows guest OSs is limited to only Novell SUSE Hyper-V support for 4-ways vSMP is limited to Windows Server 2008. For Windows 2003, Hyper-V only supports up to 2-way vSMP VMware ESX/ESXi is optimized for virtualization, offers thebroadest OS support (10 Windows versions, 16 Linux versions, 2 Novell Netware versions and 2 Sun Solaris versions) and allows all supported guest OSs to optimally utilize available resources (4-way vSMP is available on all supported server OSs)
Hardened drivers			Windows 2008 is a general purpose OS that relies on generic device drivers built by third parties that are not designed for virtualization. This fact dramatically increases the likelihood of performance problems, downtime related to driver patches, and system failures, even though the drivers go through Microsoft’s certification process. Windows drivers already go through Microsoft certification today and driver problems still exist. On the other hand, VMware works closely with IHVs to test and optimize their drivers for use with ESX/ESXi to ensure, overall reliability and performance when running concurrent virtualized workloads.
Resource Efficiency
Advanced memory management			System memory management is in most cases the dominant factor that determines the number of concurrent VMs that can run on a physical host. Hyper-V cannot overcommit host memory because it does not support features such as transparent memory page sharing and memory ballooning to reclaim idle physical memory. Consequently Hyper-V delivers lower virtual machine density, and low ratios of server consolidation compared to VMware ESX/ESXi.  VMware ESX/ESXi fully supports memory overcommit, enabling high rates of VM density while delivering consistent performance. VMware customers regularly use memory overcommit in their production datacenters at rates of 1.5X to 2.5X without any noticeable impact to end-users.
Advanced storage management			Hyper-V uses the NTFS file system for storage. NTFS is not a clustered file system. Therefore, Hyper-V does not provide native support for shared virtual disks and live migration. Hyper-V’s lack of a clustered file system means that with Microsoft quick migration (based on host clustering) all VMs on a LUN will be migrated at the same time. To avoid this unwanted result, a user must assign one VM per LUN, which creates a storage nightmare. The only other option is to purchase a third party clustered file system at additional licensing and support cost. VMware ESX/ESXi comes with VMFS, a clustered file system designed specifically for virtualization. VMFS fully supports live migration, and enables multiple VMs to share a single LUN and still migrate/failover individual VMs.
Advanced networking management			Hyper-V does not support native physical NIC teaming, instead requiring 3rd party drivers from IHVs (Intel, Broadcom). This limitation prevents Hyper-V from providing out-of-the-box, hardware independent protection from NIC failure. Additionally, Hyper-V drivers for supported NICs are not virtualization aware, cannot be controlled from within the hypervisor, and must be loaded in the parent partition. VMware ESX/ESXi fully supports NIC teaming, resulting in a simple, comprehensive out of the box solution for NIC failover.
Performance Acceleration
I/O scalability			Hyper-V uses an “indirect driver” model that keeps all device drivers in a Windows 2008 instance running in the Parent Partition of Hyper-V and relies on the general purpose OS to handle the I/O traffic. In Hyper-V’s model, all I/O requests from guest OSs must travel through Windows Server 2008 (or Server Core). This design negatively affects the efficiency of the process scheduler to manage I/O requests and results in higher latency. This impact is even more accentuated with virtual SMP as the number of processes handled by the scheduler must manage grows. The outcome is scalability issues when running many concurrent virtual machines under load, resulting in low consolidation ratios. VMware ESX/ESXi utilizes a direct driver model with a scheduler built specifically to handle the demands of multiple, high workloads. This scalability results in higher VM density ratios with while delivering consistent, high performance.
Distributed resource allocation			Hyper-V lacks many capabilities to optimally distribute hardware resources., based on real time workload conditions. Unlike ESX/ESXi, Hyper-V does not support: Network traffic shaping for load balancing Storage I/O prioritization to ensures that critical VMs receive priority access to storage devices Memory swap prioritization (memory ballooning) VMware ESX/ESXi has a proven solution for hardware resource distribution, including full support for network traffic shaping, I/O prioritization, and memory ballooning for memory management and prioritization.
Support for performance enhancing technologies			Hyper-V lacks support of several performance enhancing technologies such as: AMD RVI (nested page tables), included in the latest release of the AMD Barcelona CPU Large memory pages, which allows improved performance when virtualizing databases VMware ESX/ESXi supports both nested page tables and large memory pages and is therefore capable of superior performance even in the most demanding environments. Mission critical and intensive applications such as an Oracle database will perform better in a VMware virtual environment.
Linux paravirtualization support			Hyper-V supports the “old way” of doing Linux para-virtualization, where IT admins maintained two kernels, one for physical and one for virtual machines. This extra maintenance increased complexity and management costs.  On the other hand, VMware ESX/ESXi supports Linux para-virtualization through paravirt_ops / VMI (Virtual Machine Interface) – the new industry accepted way to para-virtualize Linux. This new way does not require IT admins to maintain and support separate kernels for physical and virtual machines – it’s all in one kernel. Currently, SLES 10, and Ubuntu 7 and 8 all support paravirt-ops/VMI.
Advanced Virtualization Features
Virtual security technology			Hyper-V does not provide dedicated capabilities for security vendors to extend their security capabilities to virtualized environments. VMsafe, an upcoming feature of VMware ESX/ESXi, will enable a rich ecosystem of third-party security solutions for virtualized environments. VMsafe is a virtual security technology that provides fine-grained visibility over virtual machine resources, making it possible to monitor every aspect of system execution and stop previously undetectable viruses, rootkits and malware before they can infect a system.

I have been reading a ton of info on “automated” cloning in ESXi. Of course, most threads inform the inquiring user that “templates” and “cloning” are NOT supported ESXi and this sort of functionality is offered in Virtual Center – which is not FREE.

Then there are the slew of automation scripts written in perl, to utilize vmkfstools, OR the shell scripts ran under ESXi’s “secret” console, once SSH has been enabled. There must be sleeker more simplified way. Turns out there may be.

1. Log in using VMWare vSphere Client.
2. Browse the Datastore
3. Create a new folder
4. Copy the .vmdk and .vmx file from source VM’s folder.
5. Paste the contents in the new folder.
6. Right click the .vmx file and click “Add to Inventory”
7. Right click the new VM and “Open Console”
8. Power On
9. When prompted, inform ESXI, that the new VM is a “copy” of the old VM.
10. Rinse and repeat.

A tad old, but noteworthy – a good read over at “The Register” on Microsoft’s new release of Hyper-V R2 and the fact that Microsoft is giving it away for FREE. Oh, and the little fact that Microsoft waited to make this announcement at VMWorld 2009.

Several of my collegues feel that VMWare has one foot already in the grave. Why? If Microsoft, Oracle, IBM and others begin to bake virtualization into their OS stacks, why would anyone else need VMWare. It’s a valid point and as the above article states, the fight will continue until we have a winner.

And then there is the matter of Citrix Systems and XenServer – not to mention Red Hat and Enterprise Virtualization. Maybe even Oracle and its Xen implementation.

UPDATED: An article by PC World about the virtualization readiness analysis performed by Burton Group involving Hyper-V, ESX and Xen.

I ran into this little snag when installing the vSphere Client on Windows 2008 Server. Here is the error:

“Error 1046. Could not write value ProductLanguage to key \Software\Vmware, Inc.\VMWare Virtual Infrastructure Client. Verify that you have sufficient access to that key, or contact your support personnel.”

Fiddling with the registry permissions didn’t get me there. I ended up exporting the [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.\VMware Virtual Infrastructure Client] from my Windows 7 box and importing onto the Windows 2008 Server box and click “Ignore”. Note: My Windows 7 install is x64 and so was my Windows 2008 Server install. If you have a Windows 2008 Server in x86, then you will want to grab the equivalent folder from a working x86 workstation.

Of course, the final step required is the same in steps required to enable the client to run on Windows 7. The PowerShell fixed outlined here.

Downloading ISO images from Micorosoft Technet or various Linux mirrors sites is an action performed quite often under ESXi environments. I will normally store all my downloads and ISO files under a Datastore folder entitled “ISO” (shocking). However, getting the ISO files to the Datastore can be somewhat of a pain.

I will either start the download from my machine, wait until I get into the office to upload the file to the Datastore OR start a download on one of the boxes at the office and upload to the Datastore later. It would really be nice if I could start the download right from within the Datastore. Guess what? You can!!!

Thanks to Ray Burkholder @ One Unified, here are the steps.

VMMWare ESXi is installed and started with SSH disabled. To enable it is an unsupported option, as it allows a user access to the console, operating system and associated file system.

My primary reason for accessing the VMWare ESXi file system (vmfs), is the ease in which one can get ISO images on to the system. When running the VMWare Infrastructure Client, during the creation of a virtual machine, the virtual CD Drive can be attached to an ISO image resident in the DataStore, with the DataStore basially being the vmfs file system.

So to get read/write access to vmfs, one needs to activate SSH on VMWare:

• At the console of ESXi host, press Alt-F1 to access bypass the simple management window and gain access to the console window.
• There is no prompt and no text echo, but type unsupported and hit the enter key.
• Enter the password you’ve assigned for root.
• A prompt of ~ # will become visible.
• Use vi to edit /etc/inetd.conf.
• Find the line that begins with #ssh and remove the #, and save the file.
• Use ps | grep inetd to find the existing inetd process id.
• Restart the process with kill -HUP id.
• You will now have access via SSH.

After logging in, the default datastore can be found at /vmfs/volumes/DataStore1. I created a sub-directory there named ISO to hold my ISO images. The directory and files are accessible from the VMWare Infrastructure Client when creating a new Virtual Machine. ISO files can be retrieved with the wget command.

I havn’t done it yet, but one could add a .ssh directory on /root, do the appropriate magic (covered in another article), and login with an ssh key rather than root password.

Much of the information here was extracted from a couple of web sites, with VM-Help being the primary one. It’s forum entries have additional useful information.