Virtualization.com

News and insights from the vibrant world of virtualization and cloud computing

VMotion

AMD demonstrates live migration across three generations of CPUs

by 1 Comment

AMD today released video and images of Live Migration (VMotion) across three generations of processors. Thanks to AMD-V Extended Migration instructions in the latest generations of CPUs, combined with VMware’s Enhanced VMotion Compatibility feature (released with ESX 3.5 Update 2 last summer) AMD is able to migrate machines running on 65-nm hardware from yesteryear to the latest six-core Opteron “Istanbul” line of processors, yet to be released. VMotion/live migration compatibility is a key in creating future-proof computing clusters running VMware or other virtualization software.

Check out the YouTube video:

AMD Istanbul live migration demo

Intel provides the same functionality under the moniker “FlexMigration”, that allows VMotion to the latest Nehalem CPUs from Xeon 5200 (“Wolfdale/Penryn”) and newer.

Update On ESX 3.5 Issue: A Letter from Paul Maritz

by Leave a Comment

—

New VMware CEO Paul Maritz has issued an official statement about the major bug plaguing customers who had updated to ESX / ESXi 3.5 Update 2 and experienced a serious problem yesterday due to a mistake in the licensing code.

The letter in full:

“Last night, we became aware of a code issue with the recently released update to ESX 3.5 and ESXi 3.5 (Update 2).

When the time clock in a server running ESX 3.5 or ESXi 3.5 Update 2 hits 12:00AM on August 12th, 2008, the released code causes the product license to expire.  The problem has also occurred with a recent patch to ESX 3.5 or ESXi 3.5 Update 2.  When an ESX or ESXi 3.5 server thinks its license has expired, the following can happen:

  • Virtual machines that are powered off cannot be turned on;
  • Virtual machines that have been suspended fail to leave suspend mode; and,
  • Virtual machines cannot be migrated using VMotion.

The issue was caused by a piece of code that was mistakenly left enabled for the final release of Update 2.  This piece of code was left over from the pre-release versions of Update 2 and was designed to ensure that customers are running on the supported generally available version of Update 2.

In remedying the situation, we’ve already released an express patch for those customers that have installed/upgraded to ESX or ESXi 3.5 Update 2.  Within the next 24 hours, we also expect to issue a full replacement for Update 2, which should be used by customers who want to perform fresh installs of ESX or ESXi.

I am sure you’re wondering how this could happen.  We failed in two areas:

  • Not disabling the code in the final release of Update 2; and
  • Not catching it in our quality assurance process.

We are doing everything in our power to make sure this doesn’t happen again.  VMware prides itself on the quality and reliability of our products, and this incident has prompted a thorough self-examination of how we create and deliver products to our customers.  We have kicked off a comprehensive, in-depth review of our QA and release processes, and will quickly make the needed changes.

I want to apologize for the disruption and difficulty this issue may have caused to our customers and our partners.  Your confidence in VMware is extremely important to us, and we are committed to restoring that confidence fully and quickly.

Thank You,

Paul Maritz
President and CEO
VMware”

Major Bug Kills VMware Powered Virtual Servers

by 1 Comment

Today’s a black day for VMware, and also (and maybe especially) VMware customers who upgraded their virtual servers with the new Infrastructure 3.5 Update 2. As of this morning, many could not power on VMotion or any of their Virtual Machines. The VI Client threw the error “A general system error occurred: Internal Error”.

This was first reported by a customer in a thread on VMware Communities. You can find the Knowledge Base article on this problem here.

The problem apparently exists within the software licensing code, rather than the functional part of ESX software.The license code falsely identifies many implementations as being out of license, prevents new virtual machines from launching, or existing VMs from migrating to new hosts.

Big oops indeed.

“An issue has been uncovered with ESX 3.5 Update 2 and ESXi 3.5 that causes the product license to expire on August 12,” says a statement from VMware’s public relations company in response to press inquiries. “VMware is alerting customers and partners of this issue. Updated product bits with correct licensing will be made available for download as soon as possible. VMware regrets any inconvenience to customers. VMware is working on an immediate patch for customers in production. VMware expects to fix the issue in code in the next 36 hours once QA testing has been completed,” the statement concludes.

A work-around has been offered whereby customers should manually set the date of all ESX 3.5u2 hosts back to 10 August as a temporary fix. Brian Madden has more on the actual glitch and the workaround, as does Matthew Marlowe.

It looks like ESXi 3.5 and even some versions of Infrastructure 3.5 Update 1 with some patches have been affected. New downloads of all affected products has been disabled, and according to VMware patched products will be made available starting tomorrow.

This will hurt VMware in any event, even if we don’t really know how many customers have already downloaded Update 2, and how many of those were using it in a live environment.

VMware

DataSynapse Extends Dynamic Service Management Tools for VMware Infrastructure Support

by Leave a Comment

DataSynapse, maker of dynamic application service management software, today announced that it is working with VMWare to provide customers with simplified deployment and operational management of application platforms and services to facilitate always-on, always-responsive virtualized applications.

As a member of the VMware Technology Alliance Partner (TAP) program, DataSynapse plans to integrate its FabricServer dynamic application service management software specifically with VMware VirtualCenter. This integration will allow IT organizations to automate deployment and provisioning and optimize service levels of server applications in a virtualized infrastructure, helping them to reduce capital and operating costs while delivering order of magnitude improvement in time to market for critical business applications.
DataSynapse FabricServer software is an enabling platform for standardizing and automating the configuration, activation, scaling and aligning application service levels with planned business policies, which minimizes downtime, automates service level management and improves enterprise application performance. Combined with VMware VMotion technology, VMware’s live migration capability, FabricServer provides responsive horizontal scalability.
DataSynapse

Hyper-V Quick Migration Breaks Network Connections, Says VMware

by 2 Comments

Check out the following demo by Blip.tv account ‘VMware TV‘, expressing the difference between moving a VM from one physical server to another with downtime (Hyper-V Quick Migration) and VMware’s Vmotion, which offers zero downtime when transferring virtual machines.

Keith Ward over at Virtualization Review picked up the demo and writes about what happens in the video:

“The demo shows a Quick Migration of a Windows Server 2003 VM from one physical machine to another. At the same time, a Microsoft Dynamics client is trying to access a database residing on the VM. Through a constant ping of the VM, we can see how a) the connection to the VM is dropped for a time, and b) how the Dynamics client fails in its attempt to get the database information (an error box pops up, showing a TCP failure). Shortly thereafter, another popup informs us that the VM has actually been deleted. It’s re-started a few moments later.”

To be balanced, here’s what ‘Jeff’ recently posted on the Windows Virtualization Team blog:

After my last blog I received almost two dozen email telling me that VMotion was far superior for unplanned host downtime and that it was a much better HA solution because it could live migrate virtual machines. I’ve heard this fallacy espoused for many years and, folks, this simply isn’t the case.

In the case of unplanned downtime, VMotion can’t live migrate because there is no warning. Instead you must have VMware HA configured and the best it can do is restart the affected virtual machines on other nodes which is the same as what is provided with Windows Server 2008 Hyper-V and Failover Clustering.

Here are a couple of quotes from VMware’s own document, Automating High Availability (HA) Services with VMware HA.

Page 1 paragraph 2 states:

Using VMware HA, virtual machines are automatically restarted in the event of hardware failure…

Page 8 states:

How does VMware HA work?

VMware HA continuously monitors all ESX Server hosts in a cluster and detects failures. An agent placed on each host maintains a “heartbeat” with the other hosts in the cluster and loss of a heartbeat with the other hosts in the cluster and loss of a heartbeat initiates the process of restarting all affected virtual machines on other hosts.

HA monitors whether sufficient resources are available in the cluster at all times in order to be able to restart virtual machines on different physical host machines in the event of host failure.

The point being VMware HA and Hyper-V with failover clustering accomplish the same thing: virtual machines are RESTARTED on another node. No better, no worse. If you still don’t believe me, find one of your ESX Servers and go pull out the power plug. (Just don’t say I didn’t warn you.)

So what do you think about all this?