VMwareTools installed in a virtual machine can be upgraded independently from the underlying VMware platform product. VMware Tools will gracefully degrade depending on the virtual machine hardware version and the VMware platform product's capabilities (forward and backward compatible).
Upgrading to newer versions of VMware Tools will provide bug fixes, enable access to new features and improve support for new guest operating system releases. Please see the release notes for VMware Tools versions for more detailed information.
VMware Tools releases and each VMware platform product release (vSphere, Workstation and Fusion) have independent support lifecycles. See the VMware Product Lifecycle Matrix (lifecycle - Support Portal - Broadcom support portal) for details. Upgrading to newer versions of VMware Tools may also be necessary to stay within the generally supported life cycle phase for VMware Tools.
VMware Tools includes components that enable optional VMware products and solutions, such as Horizon, NSX, and CarbonBlack. The guest operating system compatibility specified in this article only indicate the general minimum VMware Tools compatibility. Use of additional optional VMware products and solutions may require newer versions of VMware Tools beyond what is specified in this article. Please consult the documentation for the other VMware products.
VMware Tools for Windows is distributed as an ISO that is bundled with VMware platform products and is also available on-line. An MSI is used to install VMware Tools in the Windows operating system.
For Linux guest operating systems, VMware recommends the use of open-vm-tools, which is the open source implementation of VMware Tools. More detailed information about open-vm-tools is available here:
Most Linux vendors and communities provide open-vm-tools packages for their newer releases. If a Linux distribution of interest does not provide open-vm-tools or a specific version of open-vm-tools, then please contact the operating system vendor or community. The open-vm-tools packages are available in the following operating systems:
One of the key benefits of open-vm-tools is that updates and patches of the open-vm-tools packages are provided by the operating system vendors. Therefore, maintenance of open-vm-tools can be done at the same time as the underlying operating system. This simplifies maintenance burden and eliminates additional workload downtime.
For older operating system releases where the vendor does not provide open-vm-tools, then it is recommended to install VMware Tools for Linux in the guest operating system. VMware Tools for Linux is distributed on an ISO (linux.iso) in TAR format and installed using a perl script. The perl script can run on variety of Linux distributions. VMware Tools for Linux contains both user space application and kernel modules (drivers). The kernel modules are installed only if guest operating system kernel does not already contain the same kernel modules.
For RHEL, SLES and Ubuntu, VMware Tools are also available in the form of Operating system Specific Packages (OSPs) that may be downloaded and installed using the native package manager. OSP format tools have also been discontinued in favor open-vm-tools and is no longer available beyond version 10.3.x.
Additional considerations for Linux guest operating systems:
The following table details the compatibility of TAR and OSP format VMware Tools with Linux guest operating systems.
For older operating system releases where open-vm-tools packages are not available, then it is recommended to install VMware Tools for FreeBSD in the guest operating system. VMware Tools for FreeBSD is distributed on an ISO (freebsd.iso) in TAR format and installed using a perl script.
I believe VMware recommends not upgrading HW versions so that there is not conflicts or issues when a VM is used between different product platforms such as ESXi, Fusion, Workstation, etc. Different products have different maximum levels of HW version support.
The recommendation from VMware is to only upgrade the virtual hardware version if new features are needed. This is because upgrading the virtual hardware version can be the equivalent of swapping out the drive of one system and placing it into a new one, which can cause compatibility issues if the guest operating system is not resilient in the face of hardware changes.
While upgrading the hardware compatibility along with other components during a major version upgrade is a common practice, it is important to consider whether new features are actually needed before doing so. If there are no new features that require the hardware upgrade, it may be best to leave the virtual hardware version as is to avoid any potential compatibility issues.
Welcome back to the vSphere Upgrade Blog for the next piece of our Upgrade Journey. We began in Part 1 of this blog series by reviewing our prerequisites & compatibility, gathering our data. In Part 2 we upgraded vCenter Server & migrated VUM from vSphere 6.0 Update3 to 6.7. Part 3 guided us through preparing vSphere Update Manager (VUM) by creating an Upgrade Baseline and using that baseline to remediate our vSphere 6.0 Update 3 ESXi hosts to vSphere 6.7.
VMware Tools and Virtual Machine Compatibility comes in at Step 4 when upgrading a vSphere environment. Although both of these components hold much value for virtual machines (VM) when upgraded, caution should always be at the forefront of upgrading the VM Compatibility version. I mention caution because upgrading the VM Compatibility version may not always be necessary to perform unless specific features are needed.
VMware Tools can be upgraded manually, via vSphere Update Manager, PowerCLI, or by configuring virtual machines to check and install newer versions of VMware Tools when they reboot. The guest OS checks the version of VMware Tools when you power on a Virtual Machine (VM). The status bar of the VM displays a message when a new version is available.
In my vSphere 6.7 lab environment I will be upgrading VMware Tools on a Windows 2012 server VM via the vSphere Client (HTML5) which is considered a manual upgrade. I will begin by logging into the vSphere Client and check the current version of VMware Tools running on my VM.
Now we will review Virtual Machine Compatibility. Virtual machine compatibility determines the virtual hardware available to the VM, which corresponds to the physical hardware available on the vSphere host. Upgrading the compatibility level will allow the VM to take advantage of additional hardware features available to the virtual machine.
In vSphere 6.7, Virtual Machine Compatibility (Virtual Hardware Version) 14 was introduced. VM Compatibility version 14 includes support for features such as; Per-VM EVC, Virtual TPM 2.0, and Microsoft Virtualization Based Security (VBS). Note that when upgrading VM Compatibility some applications or the OS to may have issues working properly. I suggest only upgrading VM Compatibility if you require a feature that comes with the newer hardware version.
Step 3: Choose the VM Compatibility version desired (example: ESXi 6.5 and later or ESXi 6.7 and later). You may also choose to only upgrade after a normal OS shutdown versus when an OS crashes then reboots.
Step 4: Next we can review the status of the upgrade. When VM Compatibility is scheduled to be upgraded, you will notice the status of the upgrade is viewable under the VM Hardware section of the virtual machine.
As you have witnessed updating VMware Tools or Virtual Machine Compatibility are not complex tasks, but absolutely include steps that will require consideration prior to execution. It is always best to consult VMware Documentation pages for further details on VMware Tools as well as Virtual Machine Compatibility prior to upgrading. Also be sure to review the vSphere Upgrade Guide.
In the next vSphere Upgrade Series post, we will focus on upgrading Upgrading VMFS Storage in a vSphere 6.7 environment. Please do not hesitate to post questions in the comments section of this blog or reach out to me directly via Twitter @vCenterNerd.
The releases of the NVIDIA vGPU Manager and guest VM drivers that you install must be compatible. If you install an incompatible guest VM driver release for the release of the vGPU Manager that you are using, the NVIDIA vGPU fails to load.
You must use NVIDIA License System with every release in this release family of NVIDIA vGPU software. All releases in this release family of NVIDIA vGPU software are incompatible with all releases of the NVIDIA vGPU software license server.
When NVIDIA vGPU Manager is used with guest VM drivers from a different release within the same branch or from the previous branch, the combination supports only the features, hardware, and software (including guest OSes) that are supported on both releases.
For example, if vGPU Manager from release 17.3 is used with guest drivers from release 16.4, the combination does not support Windows Server 2019 because NVIDIA vGPU software release 17.3 does not support Windows Server 2019.
This release family of NVIDIA vGPU software provides support for several NVIDIA GPUs on validated server hardware platforms, VMware vSphere hypervisor software versions, and guest operating systems. It also supports the version of NVIDIA CUDA Toolkit that is compatible with R550 drivers.
VMware vSphere Hypervisor (ESXi) supports a mixture of different types of time-sliced vGPUs on the same physical GPU. Any combination of A-series, B-series, and Q-series vGPUs with any amount of frame buffer can reside on the same physical GPU simultaneously. The total amount of frame buffer allocated to the vGPUs on a physical GPU must not exceed the amount of frame buffer that the physical GPU has.
By default, a GPU supports only vGPUs with the same amount of frame buffer and, therefore, is in equal-size mode. To support vGPUs with different amounts of frame buffer, the GPU must be put into mixed-size mode. When a GPU is in mixed-size mode, the maximum number of some types of vGPU allowed on a GPU is less than when the GPU is in equal-size mode. For more information, refer to Virtual GPU Software User Guide.
3a8082e126