VM-Net

VMotion is one of those features of  VSphere, and of VMware infrastructure 3, that is quite simply amazing the first time you watch it move a live vm from one ESX server to another with any disruption. However to achieve this magical feat VMotion requires a network link of at least LAN speed to complete the task.

As cool as this is, one question often asked is, “How do we take that one step further, and perform VMotion between datacentres?” This, of course, is a non-trivial thing to do.  There is the challenge of moving a VM over distance (which involves some degree of additional latency) without dropping sessions. To maintain sessions with existing technologies means stretching the L2 domain between the sites, not pretty from a network architecture standpoint. And then there is the storage piece. If you move the VM, it has to remotely access its disk in the other site until a Storage VMotion occurs.  

Last year, Cisco and VMware began the task of trying to solve these long distance VMotion issues with the target of seamlessly migrating a VM between two  separated by a reasonable distance. The joint Cisco/VMware lab in San Jose has run number of tests over varying distances (simulated with reels of optic fiber) as a proof of concept.

This was demonstrated at Cisco Live in San Francisco. The demo as it stood incorporates a distance of 80km (50 miles). See above the above diagram.

This proof of concept is aimed at the following requirements:

1. Load balance compute power over multiple sites: Migrate VMs between datacentres to “follow the sun”  or to simply load balance over multiple sites. Enterprises with multiple sites can also conserve power and cooling by dynamically consolidating VMs to fewer datacenters (automated by VMware Dynamic Power Management (DPM))—another enabler for the Green datacenter of the future.
2. Avoid downtime during DC maintenance:applications on a server or datacenter infrastructure requiring maintenance can be migrated offsite without downtime.
3. Disaster Avoidance: Data centers in the path of natural calamities (e.g. hurricanes) can proactively migrate the mission critical application environment over to another data center.

Use cases #2 and #3 above also require a Storage VMotion to move the disk image to the alternative datacentre.

With the  release of vSphere 4 looming (21st of May)  Cisco has made its Nexus 1000v virtual switch available to the general public in the form of a 60 day trial. Priced at $695 per CPU on top of the cost of a vSphere Enterprise Plus CPU licence some VMware customers might find Cisco’s vNetwork Distributed Switch a little too expensive, especially when you consider that Enterprise Plus is approximately $600 more expensive than Enterprise.

Whilst the $600 per socket is actually discounted by %50 if you upgrade before December 15, 2009 some VMware customers are arguing that the current pricing and licencing tiers  may negatively impact sales, not only of  Cisco’s  Nexus 1000V but also vSphere itself.  When you consider  Citrix’s recent decision to give away XenServer for free VMware may have opened the door to the competition. I for one feel that the creation of the Enterprise Plus licencing tier, in fact all of the proposed licencing tiers makes little sense and hope, just like in the past, VMware realign/reduce/simply their licencing tiers in a manner that make sense. Starting May 21, we’ll see if customers will  consider the Cisco virtual switch over the VMware distributed switch or even pay the price to replace the basic VMware virtual switch at all.

Up until recently VMware released very little information about how it uses virtualisation internally. The first time VMware released any information was during its VMware US event in September 2008. However during this years VMworld Europe 2009 event, held in Cannes, Tayloe Stansbury VMwares CIO, in his presentation (DC35),  provided a further interesting insight to the extent VMware uses its own products to support its day to day operations.

According to Tayloe Stansbury VMware has an internal VDI deployment of over 550 users, covering most of its departments. The client configuration includes Wyse V10 Thin Clients, Dell 24 inch monitors (configured at 1920×1200 pixels, 15bit resolution), keyboard and mouse.

The server configuration runs on HP c7000 blade systems, EMC Clariion CX3-80 storage and Cisco 3020s switch modules for the HP blades. The entire infrastructure is powered by VMware Virtual Desktop Manager (VDM) 2.1 for US and View 3.0 for Europe.

VMware has an internal virtualized mail server deployment serving 7800 mailboxes. The entire infrastructure is powered by 29 virtual machines (split in two data centers) running Microsoft Exchange 2007 Enterprise Edition. 22 of them are just for the mailboxes, the other 7 work as Client Access Servers (CAS).

VMware virtualizes its entire ERP infrastructure except Oracle Real Application Clusters (RAC).  With 97% of the company servers are virtualized across one Tier 4 and two Tier 2 data centers just two applications are missing (one is Oracle RAC). EMC DMX4 is used as the storage backend of choice for mission-critical applications, otherwise EMC CX3-80 is the choice.  The front-end servers of choice are HP c7000 blades everywhere.

A couple of days ago VMware released an important security update for its ESX 3.5 and EX 3.5i products. According to KB article 1009852, updated on April 10th 2009,  a critical vulnerability in the virtual machine display function might allow a guest operating system to run code on the host.  The Common Vulnerabilities and Exposures Project (cve.mitre.org) has assigned the name CVE-2009-1244 to this issue.

This issue is different from the vulnerability in a guest virtual device driver reported in VMware security advisory VMSA-2009-0005 on the 3rd of April 2009. That vulnerability can cause a potential denial of service and is identified by CVE-2008-4916.

For those of you not using update manager to download and patch your infrastructures regularly you can download the patch from here and apply it after fully testing it of course!