Wow, long time since early 2007.
As mentioned in last reply, the current philosophy on VM Patches has changed, and for the better.
1. As of August 12th, there won't be internal code hacks to prevent VMotion or VM startups after release by developers to production.
Comment: Well, it was disappointing that it was even possible, and I was one of the fortunate shops that did not update already from VMware 3.5 Update 1 to the initial bits for VMware 3.5 Update 2 when it first came out and was spared a major shock. I personally was grossly disappointed about the ousted of CEO Diane Greene. We should appaud those that are honest and give timely opinions. It wasn't an ultimatum or even news -- everyone knows VM market leadership will be up for grab next year. Just like the great VMware reaction and replacement of VMware 3.5 Update 2 'version 2' bits, I think EMC's reaction and use of an 'insider' like Paul Maritz as Diane's replacement was as good a choice as they could make quickly.
2. VMware Update Manager
On the surface, this is exactly what I want for patch management. The key parts of patch management are:
- stability of Virtual Machines after a new release is sent out from VMware
- minimized impact if ESX VI3 itself is affected (no kernel bugs or unknown EMC SAN errors to older ESX hosts during upgrade or addition of new ESX host versions to my SANs, etc).
- minimized impact (i.e., transparency) of update to VI3 Virtual Center between old and new VMs and different version of ESX VI3 Hosts during migration
- seamless / timely upgrade of VM Tools into all virtual machines
- stable patch management into each ESX VI3 Host
Comment: Okay, they read my mind with Update Manager. I am reading up on the rules on how to NOT update / patch VMs that were taken offline to preserve them 'forever' in their identical state for legal or whatever reasons. Once I have that figured out, I like the ability to patch VM's, VMtools, and the ESX VI3 hosts themselves.
Logistically, this ESX VI3 hosts solution will require a minimum of four ESX VI3 servers in a cluster to allow the ESX VI3 host update (i.e., part the seas process) to upgrade one ESX host after its VMs are VMotion'd to the other servers. Depending on the workload, a group of 28 to 48 VMs on the four ESX VI3 servers in the cluster will still yield a manageable performance footprint for the overall cluster.
The biggest area, despite Paul Maritz promisese, will be to ensure that there is "nothing automatic" about it. We'll bring down updates in an off-production ESX Host environment (which is why I bought multiple VI3 Virtual Center licenses) and determine stability of upgrades and patches before applying them.
With 3.0.1 and 3.0.2, we patches about 6 times and installed about 78 percent of the patches (some just didn't apply).
I want to see how I can review patches 'bundled' into these updates to see how granular my change control can be.
Thanks again,
VMSysProg (creating distributed applications on VM-based environments for 32 years (geesh, did I start young).
