Vm Hardware Compatibility Upgrade Available
Annabella Wasik
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.
What version of OneView VM appliance are you using?
OneView 4.10?
OneView 4.20?
OneView 5.00?
We need hardware version 9 for OneView 4.10 and OneView 4.20
We need hardware version 11 for OneView 5.00
So the later HW version support guests with more memory, more IO adapters, more NVMe controlles, more NICs etc. etc. Bottom line: nothing that OneView needs.... Version 7 was kosher for OneView UNTIL Spectre/Meltdown. At that point, a guest needed to be at HW version 9 or later in order for ESXi to present/virtualize the new host microcode fixes to guests. OneView could have stayed at 9 until the next thing that came along that required a move. OneView V5.0 went to 11 because VMware retired older versions and OneView V5.0 requires ESX 6.x or later (11 was the version introduced with ESXi 6.0).
@PeterWolfeMy question more relates to the process and timing of upgrading the vm hardware to 11 as required for OneView 5.0. My OneView 4.20.02 vm is still at hardware version 7 (I apparently missed or overlooked the guidance to upgrade to vm version 9 for Spectre/Meltdown) and I am interested in upgrading to OneView5.0. Is it really as simple as powering off the OneView VM, upgrading the vm to version 11 and powering the vm back on? And whould I do that while the vm is still at version 4.20.02 in preparation for the upgrade to OneView 5.0? Or do I upgrade to 5.0 first and then upgrade the vm version during the power cycle that happens during the upgrade process?
> And whould I do that while the vm is still at version 4.20.02 in preparation for the upgrade to OneView 5.0? Or do I upgrade to 5.0 first and then upgrade the vm version during the power cycle that happens during the upgrade process?
Technically it shouldn't matter. You can do it before or after upgrading. In reality, it matters a little in this specific case There is a release note for V5.0 where the VM console doesn't display correctly until after the version 11 upgrade. The maintenance console works fine, just not the console's browser interface. Knowing that, just upgrade the hw revision at 4.20.x and then upgrade. That nicely sidesteps the issue entirely.
The following table lists the compatibility matrix for all NetScaler hardware platforms and the software releases supported on these platforms. The base platform is listed. For information about the models for each platform, check the data sheet.
For keeping VMware Tools up to date, there are six different approaches that vSphere administrators can use to accommodate nearly any workflow required for flexible datacenter operations. These different techniques allow optimizing either for automation and standardization or for separation of responsibilities. A previous article provides an overview of the three types of VM Tools.
Each ESXi host has a storage location for VM Tools installers, which is a configurable option and visibly referenced by the /productLocker symlink. The target can be either local to each host or point to a centralized repository of VM Tools on a shared datastore. For more information about setting up a shared Tools repository, see this earlier post or KB 2004018.
In vSphere 6.5, the version of VM Tools running on each guest is compared to the version associated with the underlying ESXi host on a periodic schedule. In vSphere 6.0 and prior this check is performed when certain virtual machine events occur, such as power-on or vMotion,. If the host has a newer version, the VM is considered out of date.
The easiest way to keep VM Tools up to date is to check a box and forget about managing this element of infrastructure. Upon VM reboot, such as after installing guest OS patches, the VM Tools status will be checked and updated when necessary. In many cases, this will result in one additional reboot after the VM Tools installation completes.
This approach may be viable for less-critical workloads, such as labs or test/dev environments. Imagine a scenario where VMs are rebooting unexpectedly due to a widespread infrastructure outage. After scrambling to get applications back online, administrators could find themselves facing unanticipated subsequent reboots if a VM Tools update happened to be available. This is an edge case, but one to keep in mind.
Important note for guests other than Windows and Linux: Solaris, FreeBSD, and Mac OS - VM Tools can only be updated using the manual interactive method. Currently, there is no automatic Tools update for these guests.
The second role VUM has in managing VM Tools is to trigger updates for individual VMs in accordance to baselines. Keep in mind that VUM does this work by leveraging the vSphere methods described in the two previous sections. In one mode, VUM can be used to make various configuration changes to multiple VMs so that a Tools update is checked and performed as necessary on each guest reboot, just like an administrator can do using the technique shown in #1 above. The advantage of using VUM is that many VMs can be configured or un-configured for this option at once.
The other mode VUM uses is to trigger a VM Tools update either immediately or at a scheduled time, just as an administrator can do manually as described in #2 above. One added benefit of using VUM to initiate these updates in this way is the ability to also remediate powered-off or suspended VMs, subsequently returning them to their initial state after update.
For scenarios where application owners demand tight control over activities that occur in the guest OS, there is an option to allow in-guest updates of VM Tools. A tray icon in Windows will indicate that an update is available, and the VM Tools configuration dialog box will permit interactive initiation of an update at a convenient time.
For equivalent functionality from a command-line utility, vmware-toolbox-cmd is offered for Linux as well as Windows guests. Keep in mind that for Linux this is only for the VM Tools ISOs, since OVT and OSP use a different process, as described in #6 below.
For very large environments or for those that have established more mature operational processes, PowerCLI provides a powerful option for updating VM Tools. This approach can target particular groups of VMs in many convenient ways, such as by cluster, by guest OS version, tags, VM state, or other vSphere attributes.
By nature of their design, Linux guests running OSPs or OVTs update VM Tools as part of a broader patching and updating workflow used for other components. This allows administrators to leverage existing Linux package managers or broader patch management and monitoring solutions without the need to coordinate with vSphere administrators.
With these flexible means of updating VM Tools, there is a suitable approach for any VMware datacenter, whether the requirement is centralized control, automation, delegation to app owners, or integration with existing patch management processes.
On the current screen you can set the default settings for VM Rollback. This includes whether or not a snapshot should be taken of the VM and the time to retain the snapshot. Let's navigate to VMs and Templates view to begin our VM Tools Upgrade
On the current screen you can set the default settings for VM Rollback. This includes whether or not a snapshot should be taken of the VM and the time to retain the snapshot. Let's navigate to VMs and Templates view to begin our VM Compatibility Update.
When it comes to keeping VM Tools up to date, there are six different approaches that vSphere administrators can use. That may sound like a lot, but after seeing each of the various options, it is clear that the intention is to accommodate nearly any workflow customers require for flexible datacenter operations. These different techniques allow optimizing either for automation and standardization or for separation of responsibilities. A previous article provides an overview of the three types of VM Tools.
Recall that each ESXi host has a storage location for VM Tools installers, which is a configurable option and visibly referenced by the /productLocker symlink. The target can be either local to each host or point to a centralized repository of VM Tools on a shared datastore. For more information about setting up a shared Tools repository, see this earlier post or KB 2004018.
When certain virtual machine events occur, such as power-on or vMotion, the version of VM Tools running on that guest is compared to the version associated with the underlying ESXi host. If the host has a newer version, the VM is considered out of date.
The simplest way to keep VM Tools up to date is to check a box and forget about managing this element of infrastructure. Upon VM reboot, such as after installing guest OS patches, VM Tools status will be checked and an update installed if needed. In many cases, this will result in one additional reboot after VM Tools installation completes.
This approach may be viable for less-critical workloads, perhaps labs or test/dev environments. Imagine a scenario where VMs are rebooting unexpectedly due to a widespread infrastructure outage. After scrambling to get applications back online, administrators could find themselves facing unanticipated subsequent reboots if a VM Tools update happened to be available. This is an edge case, but one to keep in mind.
e59dfda104