Monitoring the ESXi Upgrade Process

When doing manual host upgrades, either through the direct method or via a locally placed upgrade bundle, there is a distinct lack of progress information available after running the esxcli command.

Thankfully the ESXi host provides a running logfile of the upgrade process, which makes it much easier to keep track of what is going on and that the upgrade is indeed being performed.

The esxupdate.log is located in /var/log, and by issuing the following command in a terminal window you can have a rolling log showing you the upgrade status and progress:

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
~ # tail -f /var/log/esxupdate.log

By running the following command in one terminal window (this uses the VMware offline bundle to upgrade from ESXi 5.1 to 5.1 Update 1):

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
~ # esxcli software vib update -d /vmfs/volumes/[lunID]/

you get output like this in the secondary terminal window where the log file is being monitored:

[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
2013-06-26T10:24:51Z esxupdate: HostImage: INFO: Attempting to download VIB tools-light
2013-06-26T10:25:07Z esxupdate: vmware.runcommand: INFO: runcommand called with: args = ‘/sbin/ 0 /altbootbank’, outfile = ‘None’, returnoutput = ‘True’, timeout = ‘0.0’.
2013-06-26T10:25:08Z esxupdate: BootBankInstaller.pyc: INFO: boot config of ‘/altbootbank’ is being updated, 5
2013-06-26T10:25:08Z esxupdate: HostImage: DEBUG: Host is remediated by installer: locker, boot
2013-06-26T10:25:08Z esxupdate: root: DEBUG: Finished execution of command = vib.install
2013-06-26T10:25:08Z esxupdate: root: DEBUG: Completed esxcli output, going to exit esxcli-software

That sure beats waiting “blindly” for an upgrade/installation to finish, and in many ways this is also much better than a non-sensical progressbar.

Centrally Disable NAT in VMware Workstation

A fellow IT-professional, who works with the non-wired flavor of networking, contacted me with the following scenario:

A group of users, developers in this case, have VMware Workstation installed on their laptops. This makes it easy for them to manage, test and develop their applications in a closed environment without having to install a bunch of tools/services on their centrally managed laptop environment. An excellent use case for VMware Workstation if there ever was one.

So far, so good. The problem in this particular case was that due to security policies in the network infrastructure there was a need to disable the NAT networking possibilities in VMware Workstation.

Network address translation (NAT) configures your virtual machine to share the IP and MAC addresses of the host. The virtual machine and the host share a single network identity that is not visible outside the network. NAT can be useful when you are allowed a single IP address or MAC address by your network administrator. You might also use NAT to configure separate virtual machines for handling http and ftp requests, with both virtual machines running off the same IP address or domain. See Network Address Translation (NAT).

VMware Workstation NAT Configuration
VMware Workstation NAT Configuration

Since the VM shares the host MAC address and IP, blocking network access from the VM is not trivial in this scenario.

Thankfully, in VMware Workstation for Windows, NAT is provided through a Windows Service that we can manipulate. By disabling the “VMware NAT Service” we can ensure that NAT does not work, and that the only real alternative is to run the VM in “Bridged Mode”.

Bridged Mode makes it easier for network admins to manipulate access, since the virtual network adapter is exposed to the switches with their own MAC address, and thus possibly also their own IP address, and the VM is not “hidden” behind the hosts MAC. For instance, this makes it possible for the network gurus to limit the VMs physical network access to internet access only, and not exposing the internal network to the VM.

Running around disabling the “VMware NAT Service” on all clients that run VMware Workstation is no fun job, so naturally we need to find a way to automate this as well.

Enter Group Policy Preferences!

  1. On a computer that has VMware Workstation installed, run the Group Policy Management Console and create a new GPO.Group Policy Management Console
  2. In Computer Configuration > Preferences > Control Panel Settings select Services
  3. In the menu click on Action > New > Service and and click on  “…” next to the Service Name field
  4. Select the “VMware NAT Service”and click “Select”Services
  5. Set the Startup mode to “disabled”
  6. Assign this new Group Policy Preference to the OU that the clients that have VMware Workstation installed on resides in, and the next time the policies are refreshed, the “VMware NAT Service” should be set to disabled.Note: This might require a reboot of the client.
  7. Profit.

And there it is, a workaround on how to disable the possibility for VMs running in VMware Workstation utilizing NAT mode. A bit of a hack, but it works.


I really wish VMware would include the possibility to configure and manage multiple VMware Workstation for Windows installs, through Group Policy and Group Policy Preferences.

The ability to centrally manage configurations and settings would be a welcome addition to this already excellent piece of software, and I am sure that I am not alone in asking for this possibility. So how about it VMware, yay or nay?