VM /ETC

Archive for the ‘esx’ Category

Admins of heavily consolidated VMware VI 3 Clusters should make plans as soon as possible to download Update 5 of VMware vCenter Server to take advantage of increased performance and scalability. The latest update to vCenter 2.5 was released on July 10 and boasts improvements to support fail over management of up to 80 VMs per ESX/ESXi host in a HA (High Availability) Cluster.

The following details were taken from the VMware VirtualCenter 2.5 Update 5 Release Notes:

What’s New

Support for High Consolidation in VMware HA Clusters – VirtualCenter 2.5 Update 5 includes significant performance and scalability improvements to VMware HA. Use VirtualCenter 2.5 Update 5 for environments with more than 35 virtual machines (VMs) per host in an HA cluster.

For information on the ESX Server host settings required for this scalability improvement, see ESX Server host settings required for environments with up to 80 virtual machines per host in an HA Cluster (KB 1012002).

Upgrading or Migrating to VirtualCenter 2.5 Update 5

This release supports upgrading from VirtualCenter 1.4.1, VirtualCenter 2.0.2 (including Update 1, Update 2, Update 3, Update 4, and Update 5), VirtualCenter 2.5, VirtualCenter 2.5 Update 1, VirtualCenter 2.5 Update 2, VirtualCenter 2.5 Update 3, or VirtualCenter 2.5 Update 4, to VirtualCenter 2.5 Update 5. Review the detailed upgrade and migration instructions and guidelines that are provided in the Upgrade Guide.

Following the above link to KB 1012002 explains that upgrading vCenter 2.5 to U5 is just the start. VI 3 admins also need to make some additional configurations on ESX/ESXi hosts to achieve the 80 VMs per host improvements.

“Starting with the VirtualCenter 2.5 Update 5 release, an ESX Server host in an HA cluster can support up to 80 virtual machines. For all virtual machines to power on on other hosts in the cluster, if hosts within the failover capacity limit fail, you need to ensure that the following parameters in the ESX Server hosts are set with the following values:

Read the rest of this entry »

PHD Virtual added their latest VMware utility to it’s ever growing list of free tools for virtualization administrators. Patch Downloader 6.0 is best described as a tool that will “ease the pain” for dowloading ESX 3.X patches in environments without vCenter Update Manager (VUM). Designed to filter the list of ESX patches available by selecting the desired version of ESX/ESXi, Patch Downloader enables the administrator to review individual patch classifications and instructions. Patches are then easily downloaded to a configured repository where they are ready to be manually transferred and applied to each ESX/ESXi host. I assume support for ESX 4 patches will be added soon.

The following image is a screen shot of Patch Downloader downloading ESX 3.5 patches.

Patch Downloader is the fifth free tool from PHD Technologies. The following excerpt is from an email I received and provides links and and a brief explanation of the other tools already available.
Read the rest of this entry »

If you’ve ever had to manually trace the cables from servers to network switches in a rack you probably were not very happy about it. In fact, if you’ve ever had to trace 10 cables from each ESX host to multiple network switches you were most likely aggravated to say the least. The good news is that if you have ESX 3.5 and Cisco switches you can determine the switch ports in use via the Cisco Discovery Protocol (CDP). Even better, the VMware administrator doesn’t even need access to the network switch and can obtain the switch port information directly from the VI Client.
Read the rest of this entry »

VMware has released Update 4 (U4) of ESX and ESXi. There are some new features available with these latest builds, so check out the Release Notes of each product (linked below).

Although there are a lot of new enhancements, probably the biggest surprise for me was the experimental support for PXE booting ESXi U4. PXE boot allows stateless servers without local hard drives. For a “how to” on PXE booting ESXi 3.5 U4 check out VMware KB Article 1008971

“The main benefit of PXE booting ESX Server 3i version 3.5 Update 4 is that it allows you to run the deployment on systems with no disk or other local persistent storage. Furthermore, PXE booting greatly simplifies both the booting and upgrading processes. Therefore, scaling to many machines is greatly facilitated. No manual installation steps are necessary when the system is fully-realized.”

This sounds like an obvious Cloud enabling technology to me!

In the past, Chris Wolf and Mike Dipetrillo both gave us glimpses of a PXE boot future for ESXi. As both bloggers have described, it appears VMware architect Lance Berc is the man to thank for this new feature. Check out their posts for more info on what is possible and how it is done.

Another major enhancement of Update 4 in my opinion is the expanded and improved Enhanced VMXnet virtual network driver. Improved network performance is now possible for the 32 bit versions of Windows Server 2003 as well as Windows XP. Update 4 appears to make my recent post on enabling the VMXnet driver obsolete!

I’ll highlight (using cut and pastes) what else caught my attention from the Release Notes of both ESX and ESXi in this rest of this post. Read the rest of this entry »

So, who wants free VMware High Availability? That’s the title of a post created by Leo Raikhman on his Leo’s Ramblings blog. In this post, Leo has published the steps and scripting necessary to simulate VMware’s VI3 High Availability (HA) feature. Leo’s script works without VirtualCenter (VC), so VMware customer’s who have not implemented VC can manually create “HA -like” awareness between 2 ESX hosts. If one of the ESX servers goes offline then the virtual machines (VMs) are auto restarted on the other host. Of course, the VMs must be created on shared storage for this to work.

Before considering this script as a replacement understand the major differences between VirtualCenter HA and Leo’s HA:

• Leo’s script only works between 2 ESX hosts while VC HA can be configured with up to 32 ESX hosts as of VI 3.5 (actually using 32 host HA clusters is another topic, but it can be done)
• Leo’s script needs the ESX Service Console as written. It would need to be ported for the RCLI to work with ESXi. VC HA works with both ESX and ESXi
• VC provides a visual status for the health of your HA cluster via the VI Client
• VC HA provides HA fail over capacity for more than 1 ESX host at a time

I’ve held this post in my drafts because I wanted to try this configuration myself, but alas, I have never gotten around to it.  For those that can benefit from VC -less HA and give this script a test, let me (and Leo) know your results.

Leo’s post says: Read the rest of this entry »

A new patch for VMware ESX 3.5 Update 3 was released last week that fixes the previously reported iSCSI and FC Alert – “Queue for device has been blocked” issue. The fix was part of a bundle of patches released for ESX 3.5, ESXi 3.5 and ESX 3.0.x products.

Duncan’s summary post over at yellow-bricks.com pointed me to the new VMware KB article specific to the patch with the I/O alert fix: VMware ESX 3.5, Patch ESX350-200901401-SG: Updates VMkernel, VMX, and hostd

Upon reading the KB article I noticed that the VI Client NTP configuration issue I have posted about, and continue to run into, has also been fixed.

Read VMware’s KB for all “the other issues” corrected along with some information about applying the patches with or without Update Manager.

Jason Boche’s post titled Idle Memory Tax is a great read if you are trying to understand ESX memory allocation between virtual machines (VMs). Specifically, the post does a great job explaining how it works when you over commit your physical host’s memory. In other words, the sum of all the RAM assigned to the VMs running on a host is greater than the actual physical RAM of the ESX server.

Here’s a quote from Jason that briefly explains part of the technology that makes over commit possible: the Idle Memory Tax (IMT).

“Quite simply it’s a mechanism to take idle/unused memory from guest VMs that are hogging it in order to give that memory to another VM where it’s more badly needed. Sort of like Robin Hood for VI. By default this is performed using VMware’s balloon driver which is the more optimal of the two available methods. Out of the box, the amount of idle memory that will be reclaimed is 75% as configured by Mem.IdleTax under advanced host configuration. The VMKernel polls for idle memory in guest VMs every 60 seconds.”

Read the entire post for much more technical details and examples.

I’ve blogged before about the symptoms when the IMT and the ESX balloon driver can no longer keep up and it’s time to add another ESX host and spread the VM load.

I believe that ESX 3.x changed the need to Read the rest of this entry »