Posts Tagged ‘Documentation’

Saturday Grab Bag

September 12th, 2009

Here’s a collection of quick hits I’ve been meaning to get to. Individually, their content is a bit on the short side for the length I normally like to write so I thought I’d throw them together in a single post and see how it comes out.

Tasks and Events List Lengths

First up is the listing of Tasks and Events in the vSphere Client. Have you ever started troubleshooting an issue in the vSphere client by looking at the Tasks or Events and the chronological listing of events doesn’t go back far enough to the date or time you’re looking for? Not finding the logs you’re looking for in the vSphere Client usually means you need to open a PuTTY session and start sifting through logs in /var/log/ or /var/log/vmware/ in the Service Console. The reason for this is that the vSphere Client, by default, is configured to tail the last 100 entries in the Tasks or Events list. You can find this setting in your vSphere Client by choosing “Edit|Client Settings” then choose the “Lists” tab:

Simply increase the value from 100 to whatever you’d like, with 1,000 being the highest allowable value. Notice that when this number is increased, you will immediately see more history. In other words, you don’t have to necessarily wait for time to pass and more historical events to accumulate to see the additional rows of information. Also note that this is a vSphere Client setting which is retained client side and applies to both vCenter Server and ESX(i) host connections.

Collecting diagnostic information for VMware products

Like any offering from a software or hardware vendor, VMware products aren’t perfect. During your VMware experience, you may run into a problem which requires the intervention of VMware support. More often than not, VMware is going to ask you to generate a support bundle which consists of a collection of diagnostic and configuration files and logs. Following this paragraph is a link to VMware KB1008524 which contains links to creating support bundles for various VMware products. Note that in some cases there are different methods for different versions of the same product. If you choose to create a VMware SR online, it is helpful to have created these log bundles in advance so you can attach them to the SR. If you’ve done VMware support long enough, you already know how to FTP log bundles to VMware after an SR number has been generated.

Collecting diagnostic information for VMware products

New VMware Update Manager won’t download ESX(i) patches

Scenario: You’ve built a new VMware vCenter Server in addition to a new VMware Update Manager Server (VUM). After properly configuring Update Manager as well as the necessary internet, proxy, baseline, and scheduled task settings, VUM proceeds to download Windows, Linux, and application patches, but it won’t download ESX(i) host patches. As I found out by trench experience, the cause is because no ESX(i) hosts have been added to the vCenter Server and thus no hosts are being managed by VUM. You need to add at least one ESX(i) host to vCenter Server before VUM will be triggered to suck down all the host updates. One might then ask why guest patches are being downloaded. The only answer I have for the inconsistent behavior is due the fact that ESX(i) host patches are downloaded from VMware, while guest OS and application patches are downloaded from a completely different source, Shavlik. The mechanics behind the download processes obviously differ between the two.

What vCenter Server is this ESX(i) host managed by?

Scenario: You administer a large VMware virtual infrastructure with many vCenter Servers. You need to manage or configure a host or cluster but haven’t the slightest idea what vCenter Server to connect to. You can easily find out by attempting a Virtual Infrastructure Client connection to the host in question. Shortly after providing the necessary host credentials, the IP address of the vCenter Server managing this host will be revealed:

Now in theory, you could establish a Virtual Infrastructure Client connection to the IP address, however, I don’t like this because it dirties up the cached connection list with IP addresses which are meaningless short of having them all memorized. I prefer to take it a step further by opening a Command Prompt and using the command ping -a <IP_address> to reveal the name of the vCenter Server managing the host:

The command above reveals jarjar.boche.mcse as the vCenter Server which is managing the ESX(i) host I was wanting to manage via the vCenter Server.

I’m sure a PowerShell expert will follow up with a script which makes this process easier but this a good example to follow if you don’t have PowerShell or the VI Toolkit (Power CLI) installed.

Hidden Virtual CPU Limit Restriction in ESX 3.5

August 18th, 2009

Here’s something interesting to watch out for if you’re running ESX 3.5 Update 1 or newer clusters. In particular, clusters densely populated with running VMs or VMs with 2-way or 4-way vSMP.

Prior to ESX 3.5 Update 1, the supported and configured maximum number of vCPUs on a host was 128 by default. This meant that VMs totaling up to 128 vCPUs could be powered on within a single host.

With the release of ESX 3.5 Update 1, the supported maximum number of vCPUs on a host was raised to 192. This meant that VMs totaling up to 192 vCPUs could be powered on within a single host. Effectively, VMware is allowing higher consolidation ratios on a single host. However, according to KB article 1006393, ESX 3.5 Update 1 and newer hosts will still be configured to run a maximum of 128 vCPUs! Through my experience, this applies to both new installations of ESX 3.5 Update 1 and newer, as well as ESX 3.5 hosts that have been patched/remediated with Update 1 or newer.

So how does this impact a cluster? As I said in the beginning, you’ll run into problems on highly populated clusters or clusters with large numbers of VMs with vSMP CPUs enabled. You’ll see a few different but closely related scenarios:

  1. VMs will not VMotion onto a host which would cause it to exceed a 128 running vCPU limit
  2. DRS will not move running VMs onto a host which would cause it to exceed a 128 running vCPU limit
  3. Maintenance Mode for a host will never complete if evacuation of the running VMs would cause all other hosts in the cluster to exceed a 128 running vCPU limit
  4. HA will not power on VMs which would cause a host to exceed a 128 running vCPU limit
  5. You will not be able to power on a VM which would cause a host to exceed a 128 running vCPU limit

To configure an ESX 3.5 Update 1 or newer host to support the maximum number of running vCPUs (192), follow the instructions in the KB article above which I will repeat here:

In the VI Client, go to the Configuration tab and choose Advanced Settings.

In the Advanced Settings window, change the value for Misc.RunningVCpuLimit to 192.

The increased maximum limit takes effect immediately and is retained after rebooting the host.

Repeat the steps above for each host.

VMware made a change for the better in vSphere. ESX 4.0 supports a maximum of 512 vCPUs and this is the way the host is configured in a default installation, thus, no hidden restriction as we find in ESX 3.5 Update 1 and newer.

Update 8/19/09: VMTN community member William Lam read this article and published a Perl script which will query a specific cluster and extract out the number of vCPU for the given cluster, each individual host and the advanced configuration Misc.RunningVCpuLimit set for each host. Thanks a lot William!!

vSphere 4 Reference Card now available

August 10th, 2009

Forbes Guthrie has done it again! His wildly successful VI3 reference card is now available in vSphere format.  Head over to his site, vReference, and download your copy today.  Be sure to thank him for his hard work! I for one appreciate all that he does. Thanks Forbes and I look forward to meeting you in a few weeks.

8-10-2009 11-05-11 AM

VI3 ATDG Book Full Download Available 7/19/09

July 18th, 2009

I have it on good authority that the VMware Infrastructure 3 Advanced Technical Design Guide and Advanced Operations Guide book will be made fully available for download in .PDF format tomorrow. The authors over at had previously been releasing two chapters at a time (one chapter in each of the two sections of the book), but a decision has been made that the next release will include the entire book.

Watch for the release at and grab your copy. If by chance they don’t make the Sunday release date, give them a break, these authors are among the hardest working in the business. I’m sure they’ll have it up very soon.  This is a very generous contribution to the virtualization community as the book is only about a year old.  Kudos to Scott Herold, Ron Oglesby, and Mike Laverick.

VMware ESX Configuration Maximums Comparison Matrix

July 7th, 2009

Some of the this blog’s readers may know that one of my favorite VMware documents is the Configuration Maximums.  I’ve mentioned it a few times.  Sid Smith over at Daily Hypervisor put together a very nice consolidation of configuration maximums for ESX3, ESX3.5, and vSphere (ESX4.0).

The .PDF is assembled in a matrix format making comparison of the various VMware hypervisors easy to differentiate, compare, and contrast.  Sid, you read my mind.  Well done.  Thank you for the early birthday/Christmas present!

VMware vSphere Cheat Sheet

April 22nd, 2009

I’m not exactly sure where this document came from – I was unable to locate it on the internet, but it looks to have been generated by VMware for the partner or sales channels. I’m an end user so I typically don’t have my hands on sales material. The document summarizes vSphere features, licensing, tiers, and more. It’s not marked VMware company confidential so I’m going to go ahead and post it.  Hopefully I won’t find myself begging for forgiveness.

I love the virtualization product comparisons. There’s a lot of smoke in the air coming from all three major virtualization camps. I think the product comparison charts really help answer the questions “Why VMware?” “Why not MS or Citrix?” “Is VMware’s price point worth it?” You bet it is. The data below speaks for itself.

4-22-2009 9-25-40 PM

4-22-2009 9-26-09 PM

4-22-2009 9-26-41 PM

VMware documentation library updates

April 2nd, 2009

Quick note:  In case you missed it (like I did), VMware has updated most of their VMware Infrastructure 3 documentation.  If you’re a documentation junkie (like me), you’ll want to re-download all of VMware’s VI3 documentation.  About 75% of the documents have new file names as well.