Inplace upgrading ESXi 5.0 host to ESXi 5.1

  1. Boot your server from the CD or USB drive containing the ESXi 5.1 installer.
  2. Press Enter to start the interactive installer. 
  3. When the files are loaded, press Enter to continue.
  4. Press F11 to accept the EULA.
  5. Select the disk containing previous installation of ESXi and press Enter
  6. When the scanning is completed you will be presented with the following message. Select the Upgrade option and press Enter to continue. 
  7. Press F11 to confirm the upgrade of your ESXi host. 
  8. When the installer finishes the upgrade, remove the installation media from the host and press Enter to reboot.
  9. When the hosts reboots, you should see the familiar screen with the software version , host name and IP address. 

That’s it! You are done. This process takes literally minutes to complete


Vsphere Support for Memory Hot Add and CPU Hot Plug

Following is the chart for supporting Hot Add memory and Hot Plug vCPU.





By default, virtual machines don’t support Hot Add (add RAM) and Hot Plug (add vCPU). You need to enable this capability on a per-VM basis in order to use it. To do so, you must first shut down the virtual machine since you can’t modify these settings while it’s running. Then, open the virtual machine’s properties, navigate to the Options tab and choose the Memory/CPU Hotplug option in the Advanced section. At the right-hand side of the window, note that there are two section – one for memory and one for CPU. Choose the options you like and then click OK.


Downgrading virtual machine hardware version 8 to version 7

  • Make sure you have a good backup of the VM
  • Power off the VM
  • Make sure the VM doesn’t have any snapshots before proceeding
  • From the ESX console or from a Putty session, edit the VMs VMX file, using your favorite editor
    vi /vmfs/volume/DS1/WIN2008srv/WIN2008srv.vmx
  • Change the virtual hardware version from:
    virtualHW.version = “8”


    virtualHW.version = “7”


6 ways to enable SSH on an ESXi host

Option 1: enable Remote Tech Support (SSH) via the DCUI

Enabling Remote Tech Support (SSH) is ideal production systems, because you can enable it and leave it turned on for an x amount of time, and after the time out SSH is being disabled automatically, so the system is secure again. One small drawback is that you need to have either a physical console access or a iLO, DRAC or some other remote console access.

If you’re running vSphere 4.1 you can also enable this via the vSphere Client, see option two for more details.

Once you have direct console access to the DCUI of the ESXi server you’re able to enable Remote Tech Support (SSH) on the ESXi host, but first you need to login with the right credentials, in most cases this will be the root account.

You will find the Remote Tech Support option under the Troubleshooting Options.

Select Enable Remote Tech Support (SSH) to enable the SSH service, be patient because it will take some time to enable it, if you press Enter twice you will disable Remote Tech Support :-) .

After a few second Remote Tech Support should be enabled, if not press the Enter key one more time until you see a screen as shown above. Sometimes it can be hard to enable it through the DCUI especially when using iLO, but maybe that’s because I’m not patient enough :-).

To enable a timeout on which the SSH service is turned on, select Modify Tech Support Timeout, and hit Enter to continue, this option is not required, it can be useful to provide someone access to the ESXi host for just a few minutes/hours. I recommend you to always set this time out on production systems, because you can’t forget to turn if off again.

Enter any value between 0 (zero) and (one day) 1440 minutes (where zero is to disable it, and 1440 is the maximum) to enable the SSH  time out, press Enter to activate it.

To test if it’s working, you can use Putty to connect to the ESXi host.

Once you’re enabled the Remote Tech Support feature you will receive a message within the vSphere Client (both if your directly connected to a ESXi host or through the vCenter Server) indicating that Remote Tech Support Mode is enabled. Personally I like this notification, because it will remind you that SSH is still enabled, so you can’t forget to turn it off :-) .

When the timeout expires, you see it is not possible to create a new SSH session to the ESXi hosts (Note: only if you’re entered an timeout value in the Timeout for Tech Support Mode Text, or if you manually disable it). However this timeout does not apply for connections that are still active, so it’s still possible that someone still have access to the ESXi host even while Remote Tech Support is already disabled, so keep that in mind.

Option 2: enable Remote Tech Support (SSH) via the vSphere Client

As mentioned before, with the introduction of vSphere 4.1 you will be able to enable the Remote Tech Support through the vSphere Client, either directly connected to the ESXi host or through the vCenter Server. Bellow I will only describe how to enable it if you’re connected through the vCenter Server. If your doing this by connecting the vSphere Client directly to the ESXi hosts, you can also use these steps because it’s not that different.

If you’re using vSphere 4.1, I recommend using this way to enable SSH for a production ESXi host, because it’s easy to do and it can be done without the need of a direct console connection.

The first step off cource is to open the vSphere Client and logon to you’re vCenter Server, if your not already done that:-).

Once you logged in, select the ESXi host on which you want to enable SSH, and click on theConfiguration tab, in the Software screen click on Security Profile. In the Services field click on Properties.

Select the service: Remote Tech Support (SSH) and click on Options.

Click on Start to enable the Remote Tech Support (SSH) service, you can leave the Start-up Policy as it is.

Verify that the Remote Tech Support (SSH) service is running and click on OK.

Once you have enabled the Remote Tech Support Mode you will receive a message on the ESXi host, that the service is enabled.

One (small) drawback of this method is, that it isn’t possible to use a timeout on the SSH service directly within the Services screen, to enable the timeout you need to go toSoftware/Advanced Settings.

Select: UserVars and enter the required timeout value in the UserVars.TSMTimeOut (note: the timeout is in seconds, in my example I have configured a timeout of 30 minutes –> 1800 seconds) click on OK to enable the timeout feature.

Option 3: enable the SSH service through the Busybox

This is a more old school way of turning on the SSH service, if I remembercorrectly this procedure is still more or less the same since VMware ESXi 3, but correct me if I’m wrong here.

Unfortunately to get this working you need to have a direct console access or via iLO, DRAC to open the console on the ESXi host.

One other (big) drawback is that you won’t know if the SSH service is enabled or not, unlike the two other ways there’s no warning message in vCenter that will let you know if SSH is enabled, so in my opinion this is not a great way to turn on SSH on production ESXi hosts, but could be useful for example in Labs where you want to have quick access to the ESXi host.

Once you have access to the console, press ALT + F1 to access the console (Busybox), and login with the root credentials.

If you receive a message like the one above here, you need to enable Local Tech Support, standard this is turned off so you need to turn it on before you can access the console of the Busybox.

Press ALT + F2 to get back to the ESXi DCUI console (the yellow-grey screen) and login and select Troubleshooting Options.

Select in the menu Enable Local Tech Support and hit Enter to enable this function, this could take some time before the service is enabled, so be patient otherwise you disable the function:-) .

Now you have enabled Local Tech Support, lets get back to the console of the Busybox by pressing ALT + F1 keys.

Login with the root account.

Edit the inetd.conf file located in /etc/inetd.conf, in this example I use the VI editor.

Once the file is opened in the VI editor, press the Insert key to edit the inetd.conf file.

Depending on if you’re use IPv4 or IPv6 you need to edit the correct line, for IPv4 you need to edit the #ssh line and remove the # to enable the ssh service in the configuration file. Press on Esc and exit with the command :wq.

The SSH service will only start until the inetd reads it’s changed configuration file, this can be done by rebooting the ESXi host, or even better by restarting the inetd process. To do so we first need to have the process id of inetd, this can be done by execute the following command;ps | grep inetd you will receive a number which is the process id of inetd, in my case the process id is 4860.

To kill the inetd process, execute the command; kill -hup 4860 (where 4860 is the process id of inetd).

If everything is working fine you should be able to access the ESXi host via SSH, like in the example above I accessed the ESXi host via Putty and I’m able to login with the root account. Don’t forget to disable it once your work has been done :-) .

Option 4: Enable SSH through PowerCLI

Big thanks to Alan Renouf over at and Arne Fokkema over at for pointing me at a great blog post written by Alan Renouf himself. As Alan mentioned in his blog, it is possible to enable ESXi hosts services via the PowerCLI, here’s how you can do it.

You can show the running services by execute the command: Get-VMHostService as shown here above.

To enable it you can execute this line of code:

Get-VMHost | Foreach { Start-VMHostService -HostService ($_ | Get-VMHostService | Where { $_.Key -eq “TSM-SSH”} ) }

As you can see here above the service is now started.

Option 5: Enable SSH with help of a Perl script

Also a big thanks to William Lam over at, he has written a very cool perl script to enable services, on one or multiple ESXi hosts which can be run from the vSphere CLI or the vMA.

As mentioned here above this script can be run from the vMA or the vSphere CLI, in this example I run it locally from my notebook through the vSphere CLI, but it works the same on the vMA.

Start the vSphere CLI and browse to the folder which contains the script (the script can be found here) and execute the following command to get a over view of the services: –server [hostname] –operation query

To enable the Remote Tech Support (SSH) service we need to use the TSM-SSH service, which is not running at the moment.

To enable the Remote Tech Support service you need to execute the following command: –server [hostname] –operation start –service TSM-SH

Run the query command and you will see that the service is started correctly, I recommend you to read William’s blog post about this because you can also do this on multiple ESXi hosts, which can be very handy in large environments.

Option 6: Enable SSH within the kickstart script

William Lam also pointed me at a another way to turn on SSH during the installation, by adding a command line to the kickstart script.

This could be useful if you want to configure or check some items on the host just before you take it in production, but remember disable it once it’s running production load.

You just need to add the following two lines to the kickstart script:

vim-cmd hostsvc/enable_remote_tsm  (this will change the startup policy to “start and stop with the host”, if you don’t add this line and the host will reboot you won’t have SSH access anymore)

vim-cmd hostsvc/start_remote_tsm     (this will start the service)

One last note, I see an ESXi host more like an appliance, so I don’t want to have any unnecessary ports to be open on the host itself, because each open port is a potential security risk. That’s why I recommend not to enable SSH on a production ESXi hosts, just for security reasons. In a lab environment where security is not always a big issue you can enable SSH to get quick access to the host, or to check or test things out.

Personally I’m moving more and more over to the vMA (vsphere Management Assistant) which is a nice little appliance that’s capable of doing everything that you could do on the ESXi console and even more. The vMA is somewhat like a ”distributed” service console (dSC – Distributed Service Console, I wonder when VMware will use that term :-) ) from which, you can access any ESXi host and execute tons of commands just like your accessing an ESX(i) hosts.

Set vSphere VMs To Power Up Automatically

The setting in vSphere is a property of the ESX(i) host, found within the configuration tab in the Virtual Machine Startup/Shutdown options section. Fig. 1 shows how to set automatic startup for VMs on a host.

A VM startup sequence can be set with timing for each host.
Figure 1. A VM startup sequence can be set with timing for each host. 

The properties section will allow the startup options to be configured. It is a good idea to shorten their startup time if the hosts power up and are ready to go

Downgrading VM hardware version 8 to version 7

Make sure you have a good backup of the VM
Power off the VM
Make sure the VM doesn’t have any snapshots before proceeding
From the ESX console or from a Putty session, edit the VMs VMX file, using your favorite editor
vi /vmfs/volume/Datastore/srv-1/srv-1.vmx

Change the virtual hardware version from:
virtualHW.version = “8”
virtualHW.version = “7”

Change the virtual hardware version from:
ddb.virtualHWVersion = “8”
ddb.virtualHWVersion = “7”

You should now be able to power on the VM as virtual hardware version 7.