Applying patches to a virtualization host isn't usually a problem because tools apply patches to the C: drive - and VMs reside elsewhere. Patching a host server almost always requires a reboot, and cluster-aware updating architectures can migrate VMs from host to host as necessary during patching.Įven still, patching can be disruptive. This same architecture is also useful for patching. This is primarily for fault tolerance if a cluster node fails, the VMs that run on the cluster node can fail over to healthy nodes where VMs run uninterrupted.

In production environments, virtualization hosts are almost always clustered. You might have to use a proprietary tool from your hardware vendor to check for, download and deploy firmware updates. Not every automated patch management system can deploy firmware updates. Firmware updates for virtual hard disks might address newly discovered vulnerabilities, correct bugs related to iSCSI or Fibre Channel connectivity, or optimize storage performance. Virtual hard disks typically reside on a cluster shared volume, which is normally hosted on external storage arrays. Storage vendors tend to release firmware updates more frequently than server vendors. Virtualization host servers seldom require firmware updates, but virtual hard disks do. This includes domain controllers and DNS servers, but it can also include additional components that must be addressed as part of your patching strategy. If your organization groups its virtualization hosts into a separate domain, you must patch the domain components alongside the virtualization hosts. This domain is separate from the one where user accounts and other production resources live. In some organizations, virtualization hosts are joined to a management domain to make the infrastructure easier to manage and secure. Patch management in virtualized environments is often centered on VMs and the software that runs on them, but host servers and supporting infrastructure need patching, too.

Apply patch licence screen appears