The votes are in: Favorite vSphere enhancements

Now that users have started using vSphere, I wanted to know which new technologies in the latest ESX platform release are most popular. I ran two polls on my website, and the survey results are in: Thin provisioning is the favorite new major enhancement and alarm improvements are the favorite smaller enhancement. Both features existed in VMware Infrastructure 3 (VI3) but were very limited and difficult to use.

In VI3, thin provisioning could only be used when creating virtual disks via the command-line interface, but in vSphere it is fully integrated into the vSphere client, which makes is much easier to use. Additionally, new alarms and reporting helps manage your thin-disk usage.

Continued »

Virtualizing Microsoft SQL? Consider per-processor licensing

In a recent SearchVMware.com tip, I outlined situations where it does not make sense to have SQL or Exchange virtualized. The bottom line is that licencing depends on many factors, and you need to consider licencing when virtualizing such applications or you could end up spending more money than necessary. One point worth noting that is not in the tip is if you opt to license Microsoft SQL Server per-processor, it may carry additional benefits.

Continued »

Three ways to kill a frozen vSphere ESXi host virtual machine

At some point, you may need to know how to kill a stuck or frozen VMware vSphere 4.0 ESXi host virtual machine when the traditional power controls do not work. As with VMware ESX, there are several methods, which I covered in a previous post, killing a virtual machine (VM) on a VMware ESX host in vSphere.

The methods for ESXi are very similar to that of ESX, but the execution is different as ESXi doesn’t have a service console like ESX’s. The methods below are listed in order of usage preference, beginning with using normal VM commands and ending with a brute force method.

Method 1: Use the vmware-cmd command in the vSphere command-line interface (CLI) Continued »

More details on VMware’s Fault Tolerance feature

This week’s VMTN Community Roundtable podcast was about Fault Tolerance (FT). Henry Robinson and Karen Ritter of VMware joined to provide information about the development and future of FT.

Here’s a summary of some interesting details from the podcast, but if you haven’t listened to it yet, I recommend that you check out the recording as it provides a lot of valuable technical information.

• VMware spent a lot of time working with Intel/AMD to refine their physical processors so VMware could implement its vLockstep technology, which replicates non-deterministic transactions between the processors by reproducing the CPU instructions on the other processor. All data is synchronized so there is no loss of data or transactions between the two systems. In the event of a hardware failure you may have an IP packet retransmitted, but there is no interruption in service or data loss. Continued »

Killing a frozen VM on a vSphere ESX host

Occasionally virtual machines (VMs) get stuck in a zombie state and will not respond to a power-off command using the traditional vSphere client power controls. Rebooting a host will fix this condition — but rebooting is usually not an option. Fortunately, there are a few methods for forcing the VM to shut down without rebooting the host.

I previously documented these methods with VMware Infrastructure 3 (VI3) and wanted to make sure they all worked with vSphere. The methods below are listed in order of usage preference starting with using normal VM commands and ending with a brute force method.

Method 1 - Using the vmware-cmd service console command (the command-line interface equivalent of using the vSphere Client) Continued »

The key to successfully virtualized Domino servers

Although there are several tech notes that suggest otherwise, most Lotus Domino workloads can be successfully virtualized. I thought I’d review some of the tech notes as they seem to be discouraging people from virtualizing Domino servers. Both of the notes I’ll review blame the virtualization layer as the cause of poor performance, but as Domino servers are resource intensive, the issue could very well have been improper architecture or the versions of Domino and vSphere. If you do virtualize Domino, make sure that the underlying architecture is sufficient and make sure to have the latest versions of Domino and vSphere, as the latest versions provide I/O and performance enhancements.

The first tech note, High CPU usage by router and poor performance of Domino under VMware, is about two years old. Here’s a summary of the problem, cause and solution. Continued »

VMware’s hardware compatibility list

VMware publishes a guide called the Hardware Compatibility List (HCL). The HCL lists all of the hardware components that are supported by each version of ESX and ESXi. This very important guide is divided into different sub-guides, which include systems (server make/models), storage devices (SAN/iSCSI/NFS) and I/O devices (NICs/atorage controllers), and is updated frequently with new hardware added and older hardware removed. I was curious about the inner workings of how this guide is maintained, so I contacted VMware for some answers.

First, you might wonder why this guide is important? There are two reasons. The first is that ESX/ESXi has a limited set of hardware device drivers that are installed and loaded into the VMkernel, and while it is possible to install additional unsupported device drivers, it is not recommended. Consequently, if you use a network or storage adapter that is not on the HCL, there is a very good chance that it might not work because the driver for it is not included.

The second reason is that VMware only provides support for server hardware that is listed on the HCL. Just because server hardware is not listed on the HCL doesn’t mean it will not work with ESX/ESXi, however. There is a lot of older hardware and other hardware brands/models that are not listed on the HCL that work just fine but are not supported by VMware. So if you are using hardware that is not listed on the HCL and call VMware’s Global Support Services for assistance with an issue, you might wonder if they will help you at all. What VMware will do is assist customers in problem analysis to determine whether or not the issue is related to the unsupported hardware. If the issue is suspected to be hardware-related, VMware reserves the right to request that the unsupported hardware be removed from the server. If VMware determines that the problem is related to the unsupported hardware, they will request that you open a support request with the hardware vendor instead.

So you might be wondering how the hardware on the guide is selected? Hardware vendors have to test and certify that their hardware works properly with the latest versions of ESX and ESXi. Once this has been completed, VMware will add them to the guide. VMware works with hardware vendors as part of their Technology Alliance Partner (TAP) program, and any vendor can apply to have its hardware added to the HCL. Once an application is received, the vendor is responsible for completing the certification criteria and submitting its results to VMware for review and approval. The first step of this process requires vendors to submit a VMware Compatibility Analysis for the hardware that they intend to certify. After VMware reviews and approves the analysis, the next step is for the vendor to engage with a third-party testing lab (currently VMware works with AppLabs or Cognizant for this) to certify that its hardware works properly with ESX and ESXi. VMware will not disclose the specific testing criteria that is used for certifying hardware for the HCL, but it does use the same certification criteria for all vendors that apply.

You’ll probably notice that the HCL contains mostly newer hardware and that older hardware is periodically removed from it. VMware does not enforce an expiration period for hardware added to the HCL, but it is up to each vendor to certify its hardware for the most current VMware product releases. Vendors are free to initiate the certification process at any time it needs to have new hardware added to the HCL. Additionally, each vendor can choose to remove older hardware from the HCL as it releases newer hardware versions.

So while using hardware not listed on the HCL may be OK for labs, it is highly recommended that you only use hardware on the HCL for production use. Be sure to check the HCL periodically, especially if you plan to upgrade to a newer ESX/ESXi version, as you will want to make sure your hardware is listed before upgrading. You should check this guide before you purchase any server hardware to use with ESX/ESXi. Also, be sure all your server components are listed in the guide, including NICs and storage adapters. Often it may take a short period of time before newer hardware is added to the HCL. If you have newer hardware and it is not yet listed on the HCL, try contacting the vendor to see where it is at with getting its hardware certified by VMware.

The guide format was recently changed and is now searchable via an online form. Additionally, you can download the full guides in PDF format for each hardware component. Make sure you bookmark the guide and periodically check it — you don’t want to find out when you call VMware support that you’re using unsupported hardware.

Special thanks to John Troyer, who got me in touch with the right person at VMware to talk to, and to Nick Fuentes, who found the answers to my questions.

VMware: the new bully on the block?

VMware architect and virtualization expert Gabe van Zanten wrote an interesting post on his blog, “Gabe’s Virtual World” pointing out that VMware appears to be following in Microsoft’s footsteps by bullying partners and customers.

“Several stories have emerged that made it look like VMware has learned from Microsoft and is now practicing the same strategy. Maybe Paul Maritz’s tricks for Microsoft are now reused against VMware competitors,” van Zanten wrote. “First, there was a change in their VMworld policy reported by Brian Madden which according to VMware in an official response was just to prevent competitors from trashing VMware like Microsoft did at VMworld 2008. Although that is a viable explanation, the text now is in the legal documents and can be used as VMware pleases.”

Here’s another dirty move; VMware asked Veeam to remove its Backup & Replication support for VMware ESXi free edition in its latest Essentials Bundle, Acceleration Kits for VMware vSphere 4. Alex Barrett also wrote a great story on that, and how this kind of move might push ESXi users - which are mostly small and medium sized businesses - right into Microsoft’s arms.

These tactics raise the question of whether VMware plans to block more ESXi tools, forcing people to upgrade to a paid version of their software. As van Zanten wrote in his blog, “It is obvious they want ESXi Free to be “unmanageable”, since it is difficult to manage an ESXi free host with a read only remote administration kit. But why? Does VMware think that a small company will now switch to VMware’s vSphere Essentials edition just to be able to manage ESXi? Is VMware afraid that customers start building large clusters of ESXi Free hosts and use third party products to manage them?”

These concerns and others have yet to be answered. In the meantime, I’ll leave you with a couple text book characteristics of bullies:

Those who bully have personalities that are authoritarian, combined with a strong need to control or dominate… If aggressive behavior is not challenged in childhood, there is a danger that it may become habitual.

And the result of “habitual” bullying behavior, VMware, is alienation. In this case, of your customers.

Upgrading production servers to vSphere: When and why

I wanted to know when current VMware users are planning to upgrade their existing VMware production environments to vSphere, so I ran a poll on my website. I then ran additional polls to find out the primary reasons that users are holding off on upgrading to vSphere, and to see if they are planning on upgrading their Enterprise licenses to the new Enterprise Plus licenses.

What I discovered is that while people are eager to upgrade to vSphere, there are reasons why others are waiting; and while some will upgrade from Enterprise to Enterprise Plus licensing before the end of the year, a number of respondents indicated that they have no plans to upgrade at all.

When will you upgrade?

The first poll clearly indicated that many existing customers will be quick to upgrade to vSphere to benefit from the new technologies. Out of 140 responses, 32% are planning to upgrade within 3-6 months and another 25% of users are planning on upgrading within 0-3 months.

Only 12% had already upgraded to vSphere, so my second poll was to find out the primary reason that users were holding off on upgrading to vSphere. Continued »

Should you upgrade to VMware vSphere 4?

Since I am an independent consultant and VMware Communities Guru, I have recently been asked many questions about whether or not to upgrade to VMware vSphere 4. My answers depends on the following items:

• The hardware involved. VMware vSphere has certain hardware requriements, if your target hosts do not support these minimal requirements, then they are not good candidates for running VMware vSphere. The basic requirements are:

- 64 Bit CPU support. This does mean that some EMT64 machines will work. However they may not be on the VMware Hardware Compatibility Guides.

- Intel-VT or AMD-V support. This pretty much goes without saying; it is impossible to use VMware vSphere if these features are not enabled within the BIOS.

- No eXecute (NX) or eXecute Disable (XD) support within the BIOS. In some cases you are required to enable this bit to allow VMware vSphere to run.

• Continued »