Looking for a way to quickly update your ESXi host? Currently, you can do this via; Update Manager, Scripted Upgrade, Auto Deploy, ESXi Installer ISO or ESXCLI. Using the CLI is awesome when only updating a few host, but I prefer Update Manager when working with a larger number of host and possibly a unattended upgrade.

Go ahead an obtain the ESXi 5.5 Update 3a Offline Bundle from VMware’s website. You may notice that I am using 3a instead of 3b. This is due to vCenter being at U3a in this customers environment. vCenter will not be able to manage ESXi 5.5 Update 3b, if you update ESXi before updating vCenter Server to version 5.5 Update 3b.

Note: Support for SSLv3 protocol is disabled by default. Refer to KB 2057795. Also note that VMware DOES NOT recommend re-enabling SSLv3 due to POODLE vulnerability. If you need to enable this for some reason, please refer to KB 2139396.

So let’s get into the steps.

Step 1: Copy the contents of the offline bundle (ESXi550-201510001.zip) to a datastore accessible by all host. I will be using WinSCP for this step. Also, I will assume that we don’t need to cover this step 😉

Step 2: SSH into the host via Putty.

Step 3: Run vmware -vl which will display the current version.

 

 

 

 

Step 4: Place host into maintenance mode | vim-cmd hostsvc/ maintenance_mode_enter

 

 

 

 

Step 5: List the updates that will be applied | esxcli software sources profile list -d /vmfs/volumes/datastore1/ESXi550-201510001.zip

 

 

 

Step 6: Execute the Update to 5.5 Update A | esxcli software profile update -d /vmfs/volumes/datastore1/ESXi-5.5.0-20151004001-standard

Step 7: Reboot host and you are done!

 

 

 

IMPORTANT: Please engage VMware Support on this if you don’t feel confident about performing these steps. So please use these commands with caution!

So, last week I had to increase a HDD on a virtual machine at one of our remote sites which requires stopping vSphere Replication before this action can take place. After noticing the virtual machines folder/files were still present on the DR target side after stopping replication, I then removed the files manually. Once I tried to reconfigure replication the following error was displayed: “There is another virtual machine ‘vm-name’ that has the same instance UUID ‘UUID of Virtual Machine’ as the one that you are attempting to configure.”

Apparently, the record of the virtual machine still existed in the VRMS database. Below are the steps that were preformed to remove the virtual machine from the database so replication could be reconfigured.

Step 1: Log into the vSphere Replication Appliance via Putty or any other SSH tool.

Step 2: Use the following command to move into the bin directory: cd /opt/vmware/vpostgres/1.0/bin/

Step 3: Type: ./psql -U vrmsdb

Step 4: Paste this command into your SSH session: SELECT a.group_movalue AS “SECONDARY GID”, b.name AS “VM Name”, ‘https://’ || c.address || ‘:8043/mob/?moid=’ || a.group_movalue || ‘&vodl=1’ AS “Link to Paste” FROM secondaryvirtualmachineentity a serverentity c WHERE a.movalue = b.movalue ORDER BY name;

See screenshot below for what information this command will return. Also, I’ve removed the server names and IP’s to protect the innocent 😉

You will notice that in the first list there are 17 rows, while the one below has 16 rows of data. This is because the first output contained the virtual machine that still existed in the VRMS database. Because I am unable to reveal the server names, this will have to do for the example.

Once you find the virtual machine paste the full link into a web browser ex: https://virtualmachine:8043/mob/?moid=GID-d6de6d8a-1ed3-411c-9121-85kdf99444kkddd&vodl=1

You will be prompted for credentials, in which you need to login with your root creds. Then, scroll down to “Destroy” !!!!Before clicking destroy, please ensure this is the virtual machine you would like to remove from the database!!!!

Click Detroy, then Invoke Method. Go ahead and refresh your browser to ensure the entry is removed.  Go back to your putty session and run: SELECT a.group_movalue AS “SECONDARY GID”, b.name AS “VM Name”, ‘https://’ || c.address || ‘:8043/mob/?moid=’ || a.group_movalue || ‘&vodl=1’ AS “Link to Paste” FROM secondaryvirtualmachineentity a serverentity c WHERE a.movalue = b.movalue ORDER BY name;

You should see that virtual machine is no longer present in the list and now you can move forward with reconfiguring vSphere Replication on that machine.