Yellow Bricks

by Duncan Epping

update

vSphere 7.0 U2 Suspend VMs to Memory for maintenance!

· ·

In vSphere 7.0 U2 a new feature popped up for Lifecycle Manager. This new feature basically provides the ability to specify what should happen to your workloads when you are applying updates or upgrades to your infrastructure. The new feature is only available for those environments which can use Quick Boot. Quick Boot basically is a different method of restarting a host. It basically skips the BIOS part, which makes a big difference in overall time to complete a reboot.

When you have LCM configured, you can enable Quick Boot by editing the “Remediation Settings”. You then simply tick the “Quick Boot” tickbox, which then provides you a few other options:

  • Do not change power state (aka vMotion the VMs)
  • Suspend to disk
  • Suspend to memory
  • Power off

I think all of these speak for themselves, and Suspend to Memory is the new feature that was introduced in 7.0 U2. When you select this option, when you do maintenance via LCM, the VMs which are running on the host which need to be rebooted, will be suspended to memory before the reboot. Of course, they will be resumed when the hypervisor returns for duty again. This should shorten the amount of time the reboot takes, while also avoiding the cost of migrating VMs. Having said that, I do believe that the majority of customers will want to migrate the VMs. When would you use this? Well, if you can afford a small VM/App downtime and have large mem configurations for hosts as well as workloads. As the migration of large memory VMs, especially when they are very memory active, could take a significant amount of time.

I hope that helps, if you want to know where to find the config option in the UI, or if you would like to see it demonstrated, simply watch the video below!

Upgrading to vSphere 7.0b and not sure what the 7.0bs image is?

· ·

Are you upgrading to vSphere 7.0b and not sure what the difference is between 7.0b and 7.0bs? Well that isn’t strange, I had the same problem. I asked around internally and after a bunch of email exchanges, I was informed that the vSphere 7.0bs image is “security updates only”. After I brought it up the team has since quickly modified the release notes to include the following:

Name and Version Release Date Category Detail
ESXi 7.0b – 16324942 06/16/2020 Enhancement Security and Bugfix image
ESXi 7.0bs – 16321839 06/16/2020 Enhancement Security only image

Like I said on twitter if you didn’t know, now you know!

Changed advanced setting VSAN.ClomRepairDelay and upgrading to 6.7 u1? Read this…

· ·

If you changed the advanced setting VSAN.ClomRepairDelay to anything else than the default 60 minutes there’s a caveat during the upgrade to 6.7 U1 you need to be aware of. When you do this upgrade the default is reset, meaning the value is configured once again to 60 minutes.  It was reported on twitter by “Justin Bias” this week, and I tested in the lab and indeed experience the same behavior. I set my value to 90 and after an upgrade from 6.7 to 6.7 U1 the below was the result.

Why did this happen? Well, in vSAN 6.7 U1 we introduced a new global cluster-wide setting. On a cluster level under “Configure >> vSAN >> Services” you now have the option to set the “Object Repair Time” for the full cluster, instead of doing this on a host by host basis. Hopefully this will make your life a bit easier.

Note that when you make the change globally it appears that the Advanced Settings UI is not updated automatically. The change is however committed to the host, this is just a UI bug at the moment and will be fixed in a future release.

Where did ESXi 6.5.0 build 7526125 go?

· ·

I had two customers asking today what happened to ESXi 6.5 build 7526125. They downloaded patches and installed them in their test environment. Ready to patch some of their clusters they did a validation and found out that the patch (ESXi650-201801001.zip) has disappeared from the face of the earth. This patch included microcode for Intel processors, and Intel informed VMware that there was potentially an issue with their microcode. As such VMware decided to pull the patch as noted in the KB article. Those who had already downloaded the patches and are manually updating, make sure to delete these. Those who use VUM, make sure to exclude them from your baseline as mentioned in the KB:

Any baseline (including VMware Pre-defined Baseline), that includes one or more of  the bulletins that  correspond to patch VMSA-2018-0004, would experience the above listed error and hence, will not be able to proceed with the remediation process. For such customers, it is recommended to create dynamic or static baseline excluding the bulletins ESXi650-201801401-BG, ESXi650-201801402-BG,  ESXi600-201801401-BG,  ESXi600-201801402-BG ,ESXi550-201801401-BG and continue with the remediation process. For more information on Create and Edit Patch or Extension Baselines see vSphere 6.5 document.

Normally I don’t share these types of things anymore, but as I had two people asking on the same day I figured I would as it seems not everyone had seen that the patches were pulled and replaced. If you haven’t downloaded the patches yet, or haven’t patched your systems but want to, read this advisory first and use the patches mentioned it.

Cool tool update: RVTools 3.3 released!

· ·

Rob de Veij just published RVTools 3.3. I know many of you are using it and I definitely suggest downloading the latest version! RVTools has been downloaded more than 100.000, so definitely worth checking out if you had not so far! Here are the changes in this release:

Version 3.3 (April, 2012)

  • GetWebResponse timeout value changed from 5 minutes to 10 minutes (for very big environments)
  • New tabpage with HBA information
  • On vDatastore tab the definition of the Provisioned MB and In Use MB columns was confusing! This is changed now.
  • RVToolsSendMail accepts now multiple recipients (semicolon is used as separator)
  • Folder information of VMs and Templates are now visible on vInfo tabpage
  • Bugfix: data in comboboxes on filter form are now sorted
  • Bugfix: Problem with api version 2.5.0 solved
  • Bugfix: Improved exception handling on vCPU tab.
  • Bugfix: Improved exception handling on vDatastore tab.