• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

upgrade

vSphere 7.0 U2 Suspend VMs to Memory for maintenance!

Duncan Epping · Mar 17, 2021 ·

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!

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

Duncan Epping · Feb 6, 2019 ·

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.

VSAN Health checks disabled after upgrade to vCenter 6.0 U2

Duncan Epping · Mar 18, 2016 ·

Yesterday at the Dutch VMUG I was talking to my friend @GabVirtualWorld. Gabe mentioned that he had just upgraded his vCenter Server to 6.0 U2 in his VSAN environment, but hadn’t upgraded the hosts yet. Funny enough later someone else mentioned the same scenario and both of them noticed that the VSAN Health Checks were disabled after upgrading vCenter Server. Below a screenshot of the issue Gabe saw in his environment. (Thanks Gabe)

vsan health checks disabled

So does that mean there is no backwards compatibility for the Healthcheck, well yes and no. In this release we made our APIs public, William Lam wrote a couple of great articles on this, and in order to deliver a high quality SDK backwards compatibility had to be broken with this release. So if you received the “health checks disabled” message after upgrading to vCenter Server 6.0 U2, you can simply solve this by also upgrading the hosts to ESXi 6.0 U2. I hope this helps.

** Update March 23rd **

Please note that ESXi 6.0 Update 2 is also a requirement in order to enable the “Performance Service” which was newly introduced in Virtual SAN 6.2. Although the Performance Service capability is exposed in vCenter Server 6.0 Update 2, without ESXi 6.0 U2 you will not be able to enable it. When trying to enable it on any version of ESXi lower than 6.0 U2 the following error will be thrown:

Task Details:

Status: General Virtual SAN error.
Start Time: Mar 23, 2016 10:55:35 AM
Completed Time: Mar 23, 2016 10:55:38 AM
State: Error

Error Stack: The performance service on host is not accessible. The host may be unreachable, or the host version may not be supported

This is what the error looks like in the UI:

Awesome Fling: vCenter 5.1 Pre-Install Check

Duncan Epping · Mar 22, 2013 ·

One of the things that many people have asked me is how they could check if their environment was meeting the requirements for an upgrade to 5.1. Until today I never really had a good answer for it but fortunately that has changed. Alan Renouf has spent countless of hours developing a script that validated your environment and assesses if it is ready for an upgrade to vSphere 5.1.

This is a PowerShell script written to help customers validate their environment and assess if it is ready for a 5.1.x upgrade. The script checks against known misconfiguration and issues raised with VMware Support. This script checks the Windows Server and Active Directory configuration and provides an on screen report of known issues or configuration issues, the script also provides a text report which can help with further trouble shooting.

Is that helpful or what? Instead of going through the motion your just run this pre-flight script and it will tell you if you are good to go or not, or if changes are required. If you are planning an upgrade or are about to upgrade make sure to run this script.

Awesome job Alan, lets keep these coming!

Upgrade vCloud Director 1.5 on vSphere 5.1 to vCD 5.1.1?

Duncan Epping · Jan 7, 2013 ·

One of my colleagues, Matthew Meyer, posted a list of cool videos he produced. These videos show how to upgrade vCloud Director 1.5 on vSphere 5.0 to vCloud Director 5.1.1 running on vSphere 5.1.  Nice right?! Thanks Matt for creating these, awesome work. (I normally don’t use the “read more” option, but as there are 8 videos in total I will only show two on the front page. Hit “Continue Reading” if you want to see the rest!)

VMware vCenter Server 5.0 to 5.1 Upgrade

VMware vCenter Single Sign-On Installation

[Read more…] about Upgrade vCloud Director 1.5 on vSphere 5.1 to vCD 5.1.1?

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Interim pages omitted …
  • Go to page 6
  • Go to Next Page »

Primary Sidebar

About the Author

Duncan Epping is a Chief Technologist in the Office of the CTO in the Cloud Infrastructure Business Group (CIBG) at VMware. Besides writing on Yellow-Bricks, Duncan co-authors the vSAN Deep Dive book series and the vSphere Clustering Deep Dive book series. Duncan also co-hosts the Unexplored Territory Podcast.

Follow Me

  • Twitter
  • LinkedIn
  • Spotify
  • YouTube

Recommended Book(s)

Advertisements




Copyright Yellow-Bricks.com © 2023 · Log in