Patching and software updates have always been a part of IT, but with the evolution of virtualization, the way...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
you approach patching and software updates has changed. For example, VMware and hypervisor software aren't traditional OS software platforms. They're often regarded as infrastructure, which puts them in a different category than software updates. Infrastructure updates are closer to firmware updates. They aren't done as often as traditional patches and are more critical in nature. VMware, after all, is more of an infrastructure than an OS; the challenge is that both VMware and admins still treat VMware patches as OS updates.
Central management creates a larger area of effect
The ability to use vMotion and other live migration tools to move guests and data without interruption should render any updates moot, but that's only a small part of the puzzle. Patches and other upgrades can now affect items that span a large number of hosts, and even simple upgrades can affect a large footprint when they involve vCenter or another central management hypervisor tool. It's a major concern when upgrades don't go smoothly, because virtualization's large footprint can mean the scale of the damage is more significant. This is what makes VMware patches more like firmware updates than software updates.
The complexity of VMware's interconnections
To make things a little more challenging, you can normally back out of guest-focused software or single application software if the changes result in a bad upgrade, but the same can't be said for virtualization software. It's not that VMware patches are bigger than traditional updates; it has more to do with the complexity and interconnections of the software with other aspects of the system.
Unlike other software platforms, VMware's software stack involves a lot of moving pieces. Each of the pieces comes with its own name and build number. This means that all of the products that make up a software infrastructure install -- such as NSX, vRealize and vSAN -- all need to be the proper version before a larger update can be performed. This fracture and dependency challenge administrators by requiring several smaller upgrades. This can be harder to manage and get approved, as opposed to a larger outage window where you can do everything at once.
Should you consolidate updates or handle them individually?
Despite this not being ideal for critical infrastructure, not patching at all is a dangerous option that can leave your entire infrastructure vulnerable to security hazards and instability. While the monolithic approach to VMware patches can save time and consolidate testing, the recovery process can be difficult -- if not impossible -- in the event of something not working.
The piecemeal approach requires more steps, more paperwork and shorter, but more frequent, downtimes. This approach is more controllable, and since you have to address the fractured nature of the VMware product stack, it's a more natural fit. You can start with key pieces, such as hosts or supporting products, and do safe upgrades before you get to the larger and more complex products, such as vCenter or NSX. This also helps with the fractured natured of the VMware product stack. It's important to know that a piecemeal approach won't protect you if a larger product, such as a vCenter or NSX, fails to upgrade and breaks your environment. It does, however, remove some of the doubt and risk leading up to that point.
Complex upgrades require careful coordination
You need to find a middle ground between environments that patch as a last resort and ones that patch too often. If you compare the firmware of your data center, it's often patched on a quarterly or biannual schedule. This should work for VMware patches, too -- unless it's to address an immediate problem or critical security issue. If you can, always start small, and do the less critical aspects first; even better, start with the test and dev environments, if possible. Use the migration tools as needed, but remember that these tools aren't true backups or disaster recovery products. So, in the event you upgrade a core system component and something breaks your entire infrastructure, you can still find yourself down and in recovery mode.
Use VM service windows to schedule maintenance
Coordinate patches with vSphere Update Manager
Implement an ESXi upgrade with these steps