VMFS Upgrade

Blog: Automating Upgrade of VMware Tools and VM Compatibility

Next up in our Automating your vSphere Upgrade blog series is your VMware Tools and VM Compatibility. Upgrading these both have different requirements so we will cover when and how you should upgrade your VMware Tools and VM compatibility in the below post.

Upgrading VMware Tools

When it comes to keeping your VMware Tools up to date we have a few options but I will focus on two of my favorite methods. Keeping VMware tools up to date is very important as VMware includes drivers and tools to make sure your VM’s run optimally with the latest features.

Eric Gray of our CPBU Technical Marketing Team covers a few considerations and methods in depth in the following blog post Six Methods for Keeping VM Tools Up to Date.

Checking VMware Tools Compliance

Before we can start to update our VMware Tools it might be a good idea to understand which VMs in our environment are currently out of compliance, the easiest way to check if a VM if out of compliance is to view it via the vSphere Client and it will show you details such as the version and compliance.

However, since we are talking about automation lets show this another way using PowerCLI.

 
 1  Get-Folder -name Testing | Get-VM | % { get-view $_.id } | select name, @{Name=“ToolsVersion”; Expression={$_.config.tools.toolsversion}}, @{ Name=“ToolStatus”; Expression={$_.Guest.ToolsVersionStatus}}|Sort-Object Name

Using this PowerCLI one-liner we are able to see more information at scale, we can see that within our folder we actually have 3 VMs that are out of compliance. To remediate these to the latest version its actually quite simple with PowerCLI as well.

To make the information clearer on what needs an update we will use the same search only looking for VMs where ToolStatus is guestToolsNeedUpgrade. To do that we will use the following one-liner.

 
 1  Get-Folder -name Testing | Get-VM | % { get-view $_.id } |Where-Object {$_.Guest.ToolsVersionStatus -like "guestToolsNeedUpgrade"} |select name, @{Name=“ToolsVersion”; Expression={$_.config.tools.toolsversion}}, @{ Name=“ToolStatus”; Expression={$_.Guest.ToolsVersionStatus}}| Sort-Object Name

Upgrading VMware Tools via PowerCLI

Now that we know which VMs need tools update we can actually go forth and upgrade tools. That is quite simple we can do this using the Update-Tools PowerCLI cmdlet. Using our existing one-liner from above we will just append Update-Tools to update the VMs with tools currently out of compliance.

 
 1  Get-Folder -name Testing | Get-VM | % { get-view $_.id } |Where-Object {$_.Guest.ToolsVersionStatus -like "guestToolsNeedUpgrade"} |select name, @{Name=“ToolsVersion”; Expression={$_.config.tools.toolsversion}}, @{ Name=“ToolStatus”; Expression={$_.Guest.ToolsVersionStatus}}| Update-Tools -NoReboot -VM {$_.Name} -Verbose

You may have noticed that all the VMs had their updates kicked off at the same time and this may not be ideal, this is one way that the Update-Tools cmdlet works, however we can get around this by storing the VMs within a variable and then using a loop process them one at a time. This is definitely preferable as it will limit the impact to the environment.

$OutofDateVMs = Get-Folder -name Testing | Get-VM | % { get-view $_.id } |Where-Object {$_.Guest.ToolsVersionStatus -like "guestToolsNeedUpgrade"} |select name, @{Name=“ToolsVersion”; Expression={$_.config.tools.toolsversion}}, @{ Name=“ToolStatus”; Expression={$_.Guest.ToolsVersionStatus}}ForEach ($VM in $OutOfDateVMs){Update-Tools -NoReboot -VM $VM.Name -Verbose}

Now our tools are up to date!

For more information on upgrading your VMware Tools via PowerCLI you can find more information here.

Upgrading Tools Automatically on Reboot

Using VM options to keep VMware Tools up to date is also another method to automatically keep VMs up to date. Enabling the “Check and upgrade VMware Tools before each power on” advanced setting use to not be used because of the additional reboot it would cause for virtual machines. Keep in mind that with Windows Server 2016 VMware Tools no longer need a reboot on upgrade, it can be safe to enable this setting and have VMs stay up to date on every reboot. However this may not be applicable to all situations, so another recommendation would be to enable this for a lab environment or non-critical workloads.

The easy way to enable this option is to log into the vSphere Client, edit the VM settings and enable the setting.

After all this a post on automation, so lets see if we can find a way to use PowerCLI to modify the VM’s setting so this gets easier when we have a large environment.

Here we can see which VMs have the automatic upgrade set and which ones are configured for manual. Utilizing a filter we can look for objects that are set for manual and then configure them to be set for upgradeAtPowerCycle

 
 123456789  $ManualUpdateVMs = Get-Folder Testing|Get-VM|Get-View | Where-Object {$_.Config.Tools.ToolsUpgradePolicy -like "manual"}|select name,@{N='ToolsUpgradePolicy';E={$_.Config.Tools.ToolsUpgradePolicy } }Foreach ($VM in ($ManualUpdateVMs)) {$VMConfig = Get-View -VIObject $VM.Name$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec$vmConfigSpec.Tools = New-Object VMware.Vim.ToolsConfigInfo$vmConfigSpec.Tools.ToolsUpgradePolicy = "UpgradeAtPowerCycle"$VMConfig.ReconfigVM($vmConfigSpec)}

If we do a final check we can see that all VMs are now set to upgradeAtPowerCycle.

Upgrading VM Compatibility

When it comes to upgrading your VM Compatibility this is something that should be done with caution. Upgrading VM Compatibility aka VM Hardware is like pulling out the motherboard and replacing it with a new one, so this should only be done when features and functionality in a higher level are needed. Our current recommended level is Hardware Version 11 as it handles remediation from current security threats.

Prior to upgrading your VM Compatibility you should always make sure VMware Tools are up to date first as new drivers can be required for the new virtual hardware.

As I mentioned previously prior to upgrading your VM Compatibility I recommend taking a snapshot or a backup of the virtual machine in case a rollback is needed.

Checking VM Compatibility Version

Its quite easy to see the current version of VM Compatibility via the vSphere Client, however when checking the current levels across our entire vCenter Server we may want to automate this Below you will find a quick and easy one-liner to identify the VMs and their current VM Compatibility version.

As we can see above a few VMs are currently running v14 which is compatible with vSphere 6.7 only. This was needed for us to take advantage of VBS and TPM security features.

Again, we should only upgrade VM Compatibility when additional functionality is needed.

Upgrading VM Compatibility Version

We have identified a need to upgrade VM08 also to v14 to take advantage of Per-VM EVC so we can handle the automation of the VM compatibility upgrade. We can do this again quite easily with PowerCLI.

If you wish to do this via the vSphere Client my colleague Nigel Hickey covers this in his blog series here. However, we are talking automation here so lets jump into the quick script to accomplish this.

 
 12345678910  $HardwareUpdateVMs = Get-Folder Testing | Get-VM VM08Foreach ($VM in ($HardwareUpdateVMs)) {$VMConfig = Get-View -VIObject $VM.Name$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec$vmConfigSpec.ScheduledHardwareUpgradeInfo = New-Object -TypeName VMware.Vim.ScheduledHardwareUpgradeInfo$vmConfigSpec.ScheduledHardwareUpgradeInfo.UpgradePolicy = “always”$vmConfigSpec.ScheduledHardwareUpgradeInfo.VersionKey = “vmx-14”$VMConfig.ReconfigVM($vmConfigSpec)}

This will not automatically upgrade the VM Compatibility, unlike VMware Tools this can not be done with the virtual machine Powered On. The next time the VM is rebooted it will be shutdown, the compatibility will be upgraded and then be powered back on.

More information on upgrading VM Compatibility can be found here.

Conclusion

Automating your VMware Tools and VM Compatibility upgrades do not need to be hard, we have quite a few ways to help you with this and help this blog has helped educate you on some additional methods. For more information on Automating your vSphere Upgrade be sure to check out the full series here.

 Article: https://blogs.vmware.com/vsphere/2018/09/automating-upgrade-of-vmware-t…

 Date: 2018-10-29

https://blogs.vmware.com/vsphere/2018/09/automating-upgrade-of-vmware-t…

Blog: vSphere Upgrade Series Part 5: Upgrading VMFS Storage

• vSphere 5.5 End of General Support Reminder • 

If you are running vSphere 5.5, please be advised that End of General Support (EOGS) for vSphere 5.5 occurred on September 19, 2018. Read the 5.5 EOGS blog for more details.

Today brings us Part 5 of the vSphere Upgrade series which will cover Upgrading VMFS Storage. Upgrading storage is key to take advantage of the new features of VMFS as well as running a supported version of the storage filesystem. With the introduction of vSphere 6.7, filesystem version VMFS-3 is now deprecated and now supports just two versions, VMFS-5 and VMFS-6. If you have been following this blog series or not, you can recap what we have covered by starting with the first blog “vSphere Upgrade Series Part 1: Preparing to Upgrade“.

Upgrade VMFS

vSphere 6.5 brought us a new filesystem version VMFS-6. VMFS-6 contains many great new features such as support for new larger capacity 4K disk drivesextended system resource files (*.sf files), separate journal resource blocks, Automatic Space Reclamation, as well as allowing multiple concurrent transactions at a time per host which brings improved IOPS for multi-threaded workloads. The below chart outlines some of the differences between VMFS-5 & VMFS-6.

Here is something to consider for those that are on older versions of the VMFS filesystem. ESXi uses different approaches for VMFS5 and VMFS3 upgrades. Upgrading a VMFS5 version datastore to VMFS6 is not how we remember it used to be when moving from VMFS3 to VMFS5. Back in those older vSphere versions it was as simple as a right click to upgrade the datastore. This is not the case for VMFS5 datastores. If you have a VMFS5 datastore in your environment, you must create a new VMFS6 datastore and migrate virtual machines from the older VMFS5 datastore to fresh VMFS6 datastore.

ESXi no longer supports VMFS3 datastores as of vSphere 6.5. An upgraded ESXi host will automatically upgrade VMFS3 storage to VMFS5 when mounting any existing datastores. Consider that at the first boot after the vSphere Host upgrade to 6.7, all discovered VMFS3 datastores get upgraded to VMFS5. This also applies if you manually mount a VMFS3 datastore after the boot.

The following considerations apply to VMFS3 datastores:

  •  
  • If you use an ESXi .iso image to upgrade your legacy host through vSphere Update Manager, and the upgrade is not successful, the VMFS3 datastore is upgraded to VMFS5 if the installation process passes the mount phase.
  •  
  • In the mixed environment of the 6.5 and 6.7 ESXi hosts, the VMFS3 datastore upgrades when the 6.7 host attempts to mount it. The 6.5 host can continue to access the datastore even when the upgrade is unsuccessful.
  •  
  • When you mount the VMFS3 datastore after its resignaturing, it does not upgrade to VMFS5. You must perform the upgrade manually.
  •  

Upgrading VMFS Storage

When upgrading VMFS versions, there are a few options to choose from such as making the changes via the GUI or via CLI. In this example I will be using the GUI method to upgrade VMFS.

NOTEDavid Stamen of our vSphere Technical Marketing team is working on an upgrade automation blog series that will cover the CLI methods for upgrading VMFS as well as vCenter Server, ESXi hosts, Networking, etc.

There is not too much behind this process because essentially what we are doing is creating a new VMFS6 datastore and then migrating any VMs off of the VMFS5 storage. Next would be moving those workloads to the newly created VMFS6 datastore. I will step through the process of creating the new datastore & removing the old one.

Step 1: Verify the current datastore type by moving the the Datastore view, then selecting a datastore to review. We can see that this is a VMFS5 type datastore. At this point you should evacuate any VMs from the datastore to another location before the new VMFS6 datastore is created.

Step 2: Next we will begin the creation of the VMFS6 datastore. From the Actions menu navigate to Storage and then New Datastore…

Step 3: The New Datastore wizard comes up for you to choose a datastore type. Choose VMFS and click Next.

Step 4: Fill out the name of the new datastore and select the disk/LUN to use also. Click Next to continue.

Step 5: Choose VMFS6 for the version and click Next to continue.

Step 6: Review the partition configuration for the disk layout and make any necessary changes if required. Once edits are complete, click Next.

Step 7: The last step here in the wizard is to review the settings that you have selected and click Finish to create the datastore.

Step 8: Review the new Datastore type and confirm it is VMFS6.

NOTE: If you have any VMs to move to the new VMFS6 datastore, now is the time to migrate them over before deleting the older VMFS5 datastore.

Step 9: The final steps will be to delete the old VMFS5 datastore. Begin by selecting the datastore, from the Actions menu choose Delete Datastore.

Step 10: Confirm the deletion of the VMFS5 datastore and when ready, click Yes to continue with the removal operation.

Step 11: As a visual confirmation we review that the VMFS5 datastore has been deleted.

Conclusion

After these steps you now have a new VMFS6 datastore and have removed the older version VMFS5 storage. To learn more or review other features of VMFS, please review the VMware KB 2147824 and also VMware Documentation for VMFS.

In the next and final vSphere Upgrade Series post, we will focus on upgrading Upgrading vSphere Networking 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.

 Article: https://blogs.vmware.com/vsphere/2018/09/vsphere-upgrade-series-part-5-…

 Date: 2018-10-29

Filter Tags