vSAN Components on ESXi host

[root@esx11:~] esxcli vsan debug limit get
   Component Limit Health: green
   Max Components: 9000
   Free Components: 8982
   Disk Free Space Health: green
   Lowest Free Disk Space: 55 %
   Used Disk Space: 216048599040 bytes
   Used Disk Space (GB): 201.21 GB
   Total Disk Space: 480092618752 bytes
   Total Disk Space (GB): 447.12 GB
   Read Cache Free Reservation Health: green
   Reserved Read Cache Size: 0 bytes
   Reserved Read Cache Size (GB): 0.00 GB
   Total Read Cache Size: 0 bytes
   Total Read Cache Size (GB): 0.00 GB

How To Find My Public IP Address From Command Line

https://www.cyberciti.biz/faq/how-to-find-my-public-ip-address-from-command-line-on-a-linux/

dig +short myip.opendns.com @resolver1.opendns.com

Power Cycle a VM on Guest OS Reboot

There are a number of times in a virtual machine’s life where it needs to be power cycled (graceful OS shut down, VM powered off,  and then powered on again). For example:

1. Remediations for CPU vulnerabilities like Spectre, Meltdown, L1TF, and MDS all require a customer to power a VM off and then back on to pick up CPU instruction updates (MDCLEAR, etc.).
   
2. EVC changes, where a customer wants to alter cluster EVC settings but would require large-scale effort and/or downtime, which is untenable.
   
3. EVC changes, where a customer wishes to make a VM able to migrate seamlessly between discrete vSphere installations and/or VMware Cloud on AWS locations.
   
4. Changed-Block Tracking (CBT) enablement on VMs, where VMs need to be power-cycled to start CBT as part of a backup system install (Veeam, Rubrik, Cohesity, et al all require this).

For most customers this is the hardest part of any of these tasks because our products don’t make it easy to do. To get it done the customer needs to do it manually or automate it themselves (difficult for many), and then schedule & coordinate it outside of other maintenance windows, which is almost impossible for many of our customers.

Many customers do have regular maintenance windows, though, where patching of guest OSes occurs. However, guest OS patching causes the OS to reboot, but does not change the power state of the virtual machine/virtual machine monitor itself.

The scheduled VM hardware upgrade shows us that there’s already something in vSphere that can do this. That hardware upgrade process WILL power-cycle a VM when the guest OS is rebooted, and the customer, when scheduling the upgrade, has the choice to only do it on graceful shutdowns. That’s wonderful because it can then be seamlessly worked into regular OS patching cycles and it's low risk.

What if that power-cycle-on-shutdown functionality were exposed more generally to customers, as something they could ask vSphere to do for them at any time, for whatever reason the customer might have? It would certainly solve the four huge examples above, as well as enable what Mr. Blair Fritz dubbed “lazy EVC changes” which would make EVC more flexible and improve its use. VAC shows 21% EVC usage, which is staggeringly low considering how powerful a tool EVC is for expansion, migration, and vulnerability mitigation.

Let’s make EVC changes, CBT enablement, and all these CPU vulnerabilities – present and future – be frictionless for our customers and their millions of VMs!

Just a note.  James Yarbrough did the engineering to add this to 6.7U3.

This powerCLI snippet should do it for you:

       Get-VM  | New-AdvancedSetting -Name “vmx.reboot.powerCycle" -value $true

It will be included in upcoming releases of 6.5 and 6.0 patches as well.

How to use vSAN Observer

1/ SSH somewhere where you have RVC. It can be for example VCSA or HCIbench appliance

ssh root@vc01.robo-p6.uw.cz

2/ Run RVC command-line interface and connect to your vCenter where you have vSphere cluster with vSAN service enabled

rvc administrator@vc01.robo-p6.uw.cz

3/ In RVC CLI go to your vSphere cluster with vSAN service enabled

cd localhost/
cd ROBO-P6
cd computers
cd vSAN

4/ Start vSAN Observer

vsan.observer ./ --run-webserver --force

or one-liner

vsan.observer -r /localhost/ROBO-P6/computers/vSAN

5/ Go to vSAN Observer web interface

vSAN Observer is available at https://[IP-ADDRESS-OF-RVC-HOST]:8010

In my case, it is running at https://vc01.robo-p6.uw.cz:8010


For further info
https://kb.vmware.com/s/article/2064240