I am happy to announce that update process was a success. I have 3 appliance that I updated with 1 minor obstacle. The first one gave me issue but now that I am looking back I think part of it was just me being impatient. The DB2 to vPostgres database updated flawlessly (impressive). Anyways here are some tips for a successful update process.
1. If you want to test it on a non production appliance to see if you’re going to run into problems here’s what you do. Shutdown the vm appliance and copy the entire folder to a another folder. Add the vmx file to the inventory. By the way, you are doing this directly to ESXi vice vCent (for obvious reason). Move the nic to a different vlan and copy the mac address from the original machine and hard code it to this replica. For some reason it will not boot with the nic if I don’t hardcode the original mac. It is very important that you put it on a different vlan otherwise you will have a duplicate mac on your management vlan and the switch will get confuse which is the real one. Once done, take a snapshot for this replica and practice update with this.
2. If you are feeling lucky then just shutdown the vm and take a snapshot and begin updating.
The update process takes a while depending on the database. My second and third appliance took 15 and 20 minutes, but the first appliance took more than an hour, this is where I became impatient and rebooted the vm and messed up the database. Snapshot to the rescue and it was fine after that.
Final tip, this one is very useful since the update process does not give you any progress bar so you’re in the blind trying to figure out what is going on. To find out the progress of the update, login to vCent console and issue “tail -f /opt/vmware/var/log/vami/updatecli.log”, this will give you a running status of the update process.
As far as the update method, I used the iso method copied to the the datastore and mount it on vCent drive outlined on VMware pubs (http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.upgrade.doc_50%2FGUID-6A5C596D-103E-4024-9353-5569263EB427.html).
Final thoughts. I knew that having a controlled appliance like this that VMware can almost guarantee patching success. It is very easy for them to test the process on a lab, granted that you did not mess with any of the underlying appliance OS which is not supported anyway. The update process became like a firmware update process compared to the traditional individual patches with lots of dependencies. The huge benefit of this architecture is that the regoruous testing that normally falls on the local site administrator, now falls on the back of VMware staff engineers. This makes perfect sense since it is their own product so VMware design engineers should know which patch will brake or not brake the system. I could see vCent future following the path of the traditional ESX path. That in the future we will have a locked down vCent and not have access to the root file system of the appliance. I will predict it in two years since for this to happen they have to build all the automated functionality on the web GUI, they’re still missing disk file system monitoring tool which lets you know if vCent partition are running at full capacity; Also system, config and db backups; linkclone support; and those are naming a few.