VMware vCenter Appliance 5.0 U1a update process

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.


vCenter Appliance 5.0 U1 and more

After so many months of wait, the new vCenter 5 U1 is now out.  There’s not much articles that talks about it yet other than the fact that it now uses PostgreSQL compared to the old IBM DB2.  Funny, Vmware pubs had notes regarding the U1 long before its official release.  This made me a little confuse trying to look for the download page thinking it is already out for consumption but it’s not.

I am currently downloading the update right now and I will have to report back if I had any issues with the update process.  Again, there are no articles out there regarding the do’s and don’ts when it comes to the update process.  Typically, I would wait for the dust to settle down but I am feeling adventurous.  Besides this is Vmware’s own appliance and they have full control of what is in it so I don’t see how they can screw this up.  Unless the client did some customization to the appliance, which I did but my customization is not that risky.  I made the db partition 60gig instead of the default 20 gig.  I had an issue with the 20 gig db getting to 100% so the vpxd daemon would not start.  I am using this particular vCenter for my View 5 full clone desktop (non linkclone), out of Vmware’s suggested limitation of 5hosts and 50 vm’s.  Obviously I have more than 50 vm’s.  Honestly, if I were to redo it again I will still choose the appliance than the windows version.  I would have to be force to switch to the Windows version once I start doing Vmware linkclone but not for a while.  I have to lab linkclone out and see how it is going to behave with Mcafee EPO (GUID issue) and all its plugins (HIPS, AV, PA, etc).  Then I have to present and justify the extra license cost which is the easy part.  Who knows by the time I am ready to linkclone the appliance version figures out to support the feature.

I am looking forward to update tomorrow.