Skip navigation
1 2 3 Previous Next

Brian Atkinson's Blog

43 posts

As part of diagnosing a recent PSOD on an ESXi host, I needed to report which VMs were on the failed host and restarted by HA. While log files are always the best bet for full insight into this scenario, I used a quick change in one of the default views in the vSphere Client to generate the list of affected VMs. Here's how:


1. Using either the VMs and Templates or the Host and Clusters view, select the HA-enabled cluster in the left pane of the vSphere Client.


2. Select the Virtual Machines tab in the right pane.


3. Right-click on any of the default column headers shown in the Virtual Machines tab, and then select the Uptime field from the context menu that appears.




4. Now sort the VMs by their Uptime value.



As always, thanks for reading!



I will be at the VMworld Bookstore on Tuesday August 28 from 1:30pm to 2pm to sign copies of the "VCP5 VMware Certified Professional on vSphere 5 Study Guide: Exam VCP-510" book. Plenty of copies will be available in the VMworld bookstore. So, if you have some time stop by and say hello. I am always happy to listen to any feedback about the book, and I am already thinking of ways to make the next edition even better. Thanks for reading!



There was recently a discussion in the communities about how to run the Dell DSET utility against an ESXi host. For the non-Dell readers, the Dell System E-Support Tool (DSET) is used to create a diagnostic report of the server. These reports are often requested by Dell support when working on  suspected hardware issues. If you want to know more about DSET, the download and information are both available from Dell. From my experience, I knew that the OMSA Linux LiveCD was always an option to generate the DSET reports, but this also meant taking the ESXi host down for an outage. In the discussion around using DSET, Nikhil Patwa posted a document from Dell that details how to create a DSET report for a remote ESXi host while the host remains up.


While the discussion and PDF from Dell are both available in the links above, the ultimate purpose of this post is to summarize the discussion and the posted PDF. This is mainly because I could not get the syntax included in Dell's PDF to work. I tested this with ESXi 5 build 721882 and 768111. I also tried the Dell offline VIB versions and The steps to download and install the Dell OpenManage Offline Bundle and VIB for ESXi and the Dell OpenManage Server Administrator Managed Node are frequently requested in the communities, so I decided to cover them in this post as well. The remainder of this post will be split into three parts.

Part 1 - Install the Dell OpenManage Offline Bundle and VIB for ESXi

The first step is to install the Dell OpenManage Offline Bundle and VIB for ESXi. The Dell OpenManage Offline Bundle and VIB for ESXi allows for server hardware monitoring, similar to what is available in Dell's OpenManage Server Administrator that is often used on Windows systems. The Dell OpenManage Offline Bundle and VIB for ESXi is also a necessary component that must be installed in order to generate DSET reports from the ESXi host. At the time of this writing, the latest version is 7.1.0 and it may be downloaded here. Once the Dell OpenManage Offline Bundle and VIB for ESXi is downloaded, use the datastore browser in the vSphere Client to upload this zip file to a datastore that the ESXi host has access to. Place the host in maintenance mode and then use the ESXi Shell to issue the following command:


esxcli software vib install --depot=/vmfs/volumes/DATASTORE/


Reboot the ESXi host and then exit maintenance mode. You may want to remove the Dell OpenManage Offline Bundle and VIB for ESXi zip file from the datastore, if it is no longer needed for installation on other ESXi hosts.

Part 2 - Install the OpenManage Server Administrator Managed Node software

This step is optional in regard to generating an actual DSET report. If you want to get directly to creating a DSET report, then skip this part on installing the Dell OpenManage Server Administrator Managed Node. At the time of this writing, the latest version of the Dell OpenManage Server Administrator Managed Node is 7.1.0 and it may be downloaded here. Always check the Compatibility section at the Dell website when downloading these utilities to ensure they work with your specific version of ESXi. The Dell OpenManage Server Administrator Managed Node software is installed on a Windows system with a simple install wizard. Once the software is installed, open the following URL:




The most important thing to know on this screen is that you will need to click the link titled Manage Remote Node listed at the bottom of the screen. This will change the view to that of the Managed System Login. This change will allow us to connect to the remote ESXi host that has the Dell OpenManage Offline Bundle and VIB for ESXi installed on it. Enter the management address of the ESXi host and a set of valid credentials. Note that if you receive a login failure due to certificate failure, login again and this time place a check in the Ignore Certificate Warnings checkbox. After logging in, it is a good idea to spend some time navigating this interface and getting familiar with it. If you have used Dell OpenManage Server Administrator before, then there will be nothing new here.

Part 3 - Install and run the DSET utility

C:\Program Files (x86)\Dell\AdvDiags\DSET\bin>DellSystemInfo.exe -s [HOSTNAME] -u root -d hw -n root/dcim/sysman -r



As you can see in the image, the first thing that happens is the prompt for the root user's password. Then the DSET report is generated and saved. Note that if a full path is not specified with the "-r" option, the report will be saved to the current user's desktop. This file is a .zip file that you can send to Dell Support. You can also extract the files and view the information obtained by the DSET utility, if you like to see a lot of technical detail about your hardware.


As always, thanks for reading!



I'm a big fan of the VMware Labs flings. Flings are described by VMware Labs as "...a short-term thing, not a serious relationship..." and the Thinapped vSphere Client is one of the best flings available. If you have never used the Thinapped vSphere Client, then all you need to know is that it is a fully functioning vSphere Client delivered in a single executable file. And now version 5.0 U1 is out, which means I can start enjoying this fling in my vSphere 5 environments.


The Thinapped vSphere Client proves extremely useful for many of the users I work with who don't (or can't) install software on their machines. At 92MB in size, it can also be a much faster download than accessing the 350MB installer from vCenter Server. I also find it very useful on servers (think Windows backup servers) where I don't necessarily want to install any more software than I absolutely have to.


If you haven't checked out the Thinapped vSphere Client, then now might be a good time!


Thanks for reading,


I recently needed to create a Windows 2008 R2 template on a remote vCenter Server. Rather than start from scratch and create a new "golden image," I converted an existing Windows 2008 R2 template to a virtual machine and used VMware Converter to move it to the remote site. Both sites are using vCenter Server 5.0.0 build 623373 and ESXi 5.0.0 build 702118. After Converter had completed, I converted the VM to a template on the remote side and imported the exported Windows 2008 R2 guest customization specification. I then tried to deploy a virtual machine from this template. I chose the newly imported guest customization specification and was presented with the following error, after completing the deploy template wizard.


Customization  of the guest operating system 'windows7Server64Guest' is not supported  in this configuration. Microsoft Vista (TM) and Linux guest with Logical  Volume Manager are supported only for recent ESX host and VMware Tools  versions. Refer to vCenter documentation for supported configurations.


Since both vCenter Servers and all ESXi hosts were running the same versions, this error was confusing. The latest version of VMware Tools was also already installed in the template, which made this error message even more confusing. To troubleshoot, I converted the template back to a virtual machine and powered it on. After logging in, it was pretty obvious that something was wrong with the VMware Tools since the mouse behavior was very erratic. I uninstalled the VMware Tools, reboot the VM, and installed the VMware Tools again. After another reboot and power down, I converted the virtual machine back to a template. This time the deploy template wizard worked as expected and a new VM was deployed from the template.


This is another one of those weird events that I figured I would post in hopes of maybe helping others that run across it.



A large part of writing the VCP5 Study Guide was creating many exercises around the exam objectives. One of the items covered in exam objective 2.1 is to Add/Configure/Remove vmnics on a vNetwork Standard Switch. I thought it would be interesting to detail the steps I used to test this exercise.


This entire lab setup was running in VMware Workstation. For this exercise, there is a single ESXi 5 host and the vMA 5 is also used. The ESXi host has vSwitch0 for management traffic only and the VM Network port group has been removed from it. A vSwitch1 was built with a single NIC (vmnic1) and a single port group for virtual machine traffic. On this ESXi host are two VMs each with 256MB, 1 vCPU, and an e1000 NIC that boot to a Ubuntu 9.04 LiveCD and connect to the virtual machine port group on vSwitch1.


I first started by powering up each VM and waiting for Ubuntu to boot. I then set up continuous pings to the ESXi host's management address from the VMs running Ubuntu. I issued the resxtop command on the vMA and pressed the N key to view the network information. Here is what I saw.


As expected, both VMs (VM2 and VM3) are using vmnic1.


The next step was to add a second NIC (vmnic2) to vSwitch1. I did this using the vSphere Client. Here is what I saw in the vMA.


Notice that VM2 is now using vmnic2. The Linux continuous ping ran uninterrupted throughout this process.


The final step was to remove a NIC (vmnic1) from vSwitch1. I did this using the vSphere Client. Here is what I saw in the vMA.


Notice that both VMs are now using vmnic2. And again, the continuous ping did not stop running!


Adding and removing vmnics from a vSwitch is a nondisruptive process, and the testing detailed above proves this.


As always, thanks for reading!


I recently set up an environment with two vCenter Servers using linked mode. The first vCenter Server 5 had been an existing vSphere install that had been upgraded several times and the second vCenter Server was a fresh install of vSphere 5 at a second site. Some time after this was completed, while connected to the first vCenter Server via the vSphere Client, I noticed that several of the larger datstores on hosts managed by the new vCenter Server at the secondary site had alarms triggered for datastore usage on disk. I eventually realized that the default values were still in use on the new vCenter Server, and this second environment regularly exceeds these defaults. I went to edit the alarm settings of the "Datastore usage on disk" alarm definition and clicked the Triggers tab. I was presented with the following message: The triggers for this alarm cannot be displayed or changed through the vSphere Client. Use the vSphere API to modify these alarm triggers.


My first thought was that this must be due to the clean install of vCenter Server 5 at the second site and that there was no way I was going to have to resort to using APIs to make this change. A quick Google search didn't turn up much in the way of results, and then I had a thought. What if linked mode was somehow behind this? I started up another instance of the vSphere Client and connected directly to the vCenter Server at the secondary site. Just as expected, everything works normally with this approach and the trigger values can be adjusted as expected. I made the changes and the warnings cleared on these datastores!


I tried several other alarm definitions and this behavior is not consistent. Some can be modified across vCenter Servers and others present the same message documented above. Hopefully this information will help anyone else that stumbles upon this condition.


Thanks for reading,


This entry isn't really VMware-specific and actually falls along the lines of an activity I have to perform occasionally and always forget the finer details of. I'm posting the steps here for me, but hopefully they will help others as well. Sometimes there is a need to change the edition of Windows. For example, to leverage those 32 vCPUs in virtual machine hardware version 8, Windows Standard won't work. Applications and their requirements grow, and it can be very useful to upgrade Windows editions in a simple and non-disruptive way.


Windows Server 2008 R2 contains a command-line utility called DISM (Deployment Image Servicing and Management tool). This tool has many features, but one of those features is the ability to upgrade the edition of Windows in use. Note that this process is for upgrades only and is irreversible. 


To get started, issue the following command to determine the current edition:

DISM /online /Get-CurrentEdition


Note the edition and then issue the following command to determine the edition upgrade options:

DISM /online /Get-TargetEditions


Now that we know what we have and what the upgrade options are, there is only a single command left to perform the edition upgrade. This is also the tricky part of this process and the part that I basically created this entry for.


Once ready to change editions, issue the following command:

DISM /online /Set-Edition:<edition ID> /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX


The <edition ID> field is the version information obtained in step 2. For example, ServerEnterprise or ServerDatacenter. The ProductKey field needs to be one of the KMS Client Setup Keys listed at This is the step that always gets me, as I want to just use a real KMS key that I control. These real KMS keys will not work for this step. Use the appropriate KMS Client Setup Key for the edition of Windows that was specified in the <edition ID> field. For example, if ServerEnterprise was used, then use the KMS Client Setup Key for Windows Server 2008 R2 Enterprise. For example, to upgrade Windows Server 2008 R2 Standard editionn to the Enterprise edition:

DISM /online /Set-Edition:ServerEnterprise /ProductKey:489J6-VHDMP-X63PK-3K798-CPX3Y


Shortly after this command is entered, follow the reboot prompts. Once the rebooting is complete, log back in to Windows and use the Activation Wizard to change the product key to your valid KMS key and activate the upgraded version of Windows.


Most of the content from this entry, along with a few important caveats, can be found at:


Thanks for reading,


Back in August of 2011 I announced that I had signed on with Sybex to write their VCP5 Study Guide. It is now May of 2012 and after at least three different editors, two technical editors, a name change and more work than I ever thought possible the book is finally available. The schedule was aggressive, and the book took a solid five months of writing, revising and development. Once the content was delivered, it went through typesetting and proofreading and various other production processes. Each one of these steps seemed to involve me reading and/or reviewing the content one more time. If my count is correct, I have read this entire book no fewer than 7 separate times!


I stuck to my original intent of having the book follow the VCP5 exam blueprint and cover each of the objectives in detail. Some of the objectives had to be organized differently, to make the content flow better but each and every VCP-510 exam objective is covered. The book is also heavy on exercises. The purpose of these exercises is to build experience using the vSphere products and features. The book also includes assessment questions, review questions, practice tests and flashcards.


Good Luck to all of those taking the VCP5 and let me know what you think about the study guide!



The vSphere Configuration Maximums constantly come up in VMTN discussions about the VCP5 exam. Many people report that they received no configuration maximum questions on their VCP5 exam, but I don't think that this is entirely true. I think what people are implying is that they didn't receive any of the old VCP3-style questions that just centered around knowing a specific configuration maximum value. The exam has evolved and so have the questions.


I would venture to bet that nearly every one that takes the VCP5 will receive questions where knowing values from the configuration maximums will be required to answer the question. I know that when I took the VCP5 BETA, there were many questions that required knowledge of configuration maximums. The questions were not the simple "how many X are supported" type questions, but more involved questions where you couldn't arrive at the correct answer without knowing a value from the configuration maximums.


Objective 4.3 of the VCP5 exam blueprint lists the required knowledge of "Identify the vCenter Server managed ESXi hosts and Virtual Machine maximums." This objective guarantees that configuration maximums are included in the VCP5 exam. My advice is to not let anyone else's exam experience sway you into thinking that you do not need to know the configuration maximums for the VCP5 exam. Also remember this: Knowing the configuration maximums could be the difference between passing the VCP5 or not. It would definitely be better to spend some time with this document, before you take the VCP5 exam.


Good Luck!



This is a modernized version of the "Single use vihostupdate How To for ESXi 4.x, which was a modernized version of the "Single use ESXUPDATE How To for ESX 4"  post I wrote a long time ago. With vSphere 5, vihostupdate and esxupdate are not applicable for ESXi 5. We instead will need to use the esxcli command to apply the updates to our ESXi 5 hosts.


01: Make sure you have the vMA 5.0 or the vCLI installed and configured or that you have ESXi Shell access on the ESXi 5 host.


02: Download the patch bundle directly from VMware Support. This download will be .zip file.  Do not extract it.


03: Upload the .zip file to a datastore that is accessible on the ESXi host you wish to update. The syntax below will use /vmfs/volumes/datastore1, and you may need to adjust as necessary. Note that the .zip file is uploaded to the ESXi host.


Note:  In the examples below, the syntax is specific for the vMA. Adjust accordingly, if you are using another approach.

04: Obtain local console access to the vMA and login with the vi-admin account.


05. To determine if the host needs to be placed in maintenance mode, issue the following command:


esxcli --server= --username=root software sources vib get -d /vmfs/volumes/datastore1/ | grep "Maintenance Mode Required: True"


06.  If grep returns "Maintenance Mode Required: True" results, then issue the following command to place the host in maintenance mode:


vicfg-hostops --server --operation enter


07. Verify that the host is in maintenance mode, by issuing the following command:


vicfg-hostops --server= --operation info


Note: You could also use the vSphere Client to put the ESXi 5 host in maintenance mode.


08. To verify which VIBs are already installed on the ESXi 5 host, issue the following command:


esxcli --server= --username=root software vib list | more


09. To find out which VIBs are available in the depot (the downloaded .zip file), issue the following command:


esxcli --server= --username=root software sources vib list --depot=/vmfs/volumes/datastore1/ | more


10. To update the ESXi 5 host with the VIBs included in the depot, issue the following command:


esxcli --server= --username=root software vib update --depot=/vmfs/volumes/datastore1/


11. When the update is complete, verify the information presented. If prompted, reboot the ESXi 5 host by issuing the following command:


vicfg-hostops --server --operation reboot


12. Verify the patch bundle was installed, by issuing the following command:


esxcli --server= --username=root software vib list | more


13. If applicable, take the ESXi 5 host out of maintenance mode using the vSphere Client or with the following command:


vicfg-hostops --server --operation exit


As always, thanks for reading!

This question of what happened to the vCenter Converter plug-in has been coming up a lot lately in the communities, and here are some official/unofficial references about what happened.


(1) The vSphere 4.1 release notes from July 13, 2010 announced that "VMware vSphere 4.1 and its  subsequent update and patch releases are the last releases for the  VMware vCenter Converter plug-in for vSphere Client. VMware will  continue to update and support the free Converter Standalone product,  which enables conversions from sources such as physical machines, VMware  and Microsoft virtual machine formats, and certain third-party disk  image formats."


(2) A discussion showed up from in the Converter forum stating the following:

"With the release of vSphere 5.0,  we will no longer provide vCenter Converter Integrated however, vCenter  Converter Standalone will continue to be available as a stand-alone,  public software binary. We will continue to provide support for vCenter  Converter Integrated on the existing vSphere platforms per the VMware support policy and we will continue to provide vCenter Converter Standalone as a free  download. You can find out more about vCenter Converter Standalone here:


Best regards,
VMware Product Management"


(3) The vCenter Server Installer application does not list the vCenter Converter plug-in, and the media does not contain it.


The standalone version of Converter 5.0 was released on September 8, 2011 and may be downloaded at


Thanks for reading,


It has been a long time in the works, but I am happy to announce that I am currently in the process of writing Sybex's VCP5 study guide. The book is tentatively titled "VCP: VMware Certified Professional on vSphere 5." This book will be a complete rewrite with 100% new content to focus on the VCP5. I am also pleased to announce that Troy Clavell has signed on to be technical editor for this project.


The goal of the book is to follow the VCP5 exam blueprint and cover each of the objectives in detail. I also hope to impart real world practical knowledge along the way, using many of the things learned here in the VMTN forums. The book will also include many hands-on exercises, 20 review questions at the end of each chapter, a glossary and plenty of helpful tips. There will also be a companion CD that will include two 75-question bonus exams and at least 100 flashcards.


The book will be available in the first quarter of 2012, but I will announce the actual availability when I know for certain. If you have any feedback on what you think would make a great VCP5 book, I would love to hear it.



The subject of partition alignment comes up in the communities on a fairly regular basis.  VMware's "Recommendations for Aligning VMFS Partitions" performance study is the classic reference for this topic, but it is also stated in this document that "Aligning the boot disk in the virtual machine is neither recommended nor required. Align only the data disks in the virtual machine."  The logic here historically was around the idea that OS partitions would not have high IO demands and the hassle of creating an aligned OS volume in Windows XP or 2003 was a frustrating process involving usually GParted or other 3rd party utilities.  With Windows 7 and Windows 2008, this is no longer an issue, as the partitions are all aligned by default.  For those still running older versions of Windows, the easiest solution for aligning the OS volumes is to use the newly released public BETA of VMware Converter 5.0.  The latest release of VMware Converter offers optimized disk and partition alignment and cluster size change as options.


To test these new features, I started with a plain vanilla Windows XP install in VMware Workstation.  In the screenshot below, notice that the value for "Partition Starting Offset" is 32,256.  This is clearly a volume that is not aligned.


After a quick V2V using VMware Converter 5.0, notice that the value for "Partition Starting  Offset" is now 1,048,576.  This is a volume that is aligned on a 1 MB boundary.


In comparison to the other methods I have seen for accomplishing this task, it just doesn't get much easier than this!


Thanks for reading,


vSphere 4.0 introduced virtual hardware version 7, which added hot plug support for virtual devices and hot add support for memory and virtual CPUs.  Finding the operating systems that could be used with hot add was a somewhat difficult process, and there wasn't a readily available "official" resource that could be used for reference.  With the release of v 2.0 of the VMware Compatibility Guide, finding this information just got a lot easier.  So, what operating systems can be used with hot add memory and vCPU?






There are many!  Rather than posting large tables that would require constant updating, I posted the direct link to the VMware Compatibility Guide.  This way the results shown will always be current.


Thanks for reading.