VMworld 2016 Keynote

Pat Gelsenger kicked off another VMworld with a keynote that was focused on hybrid cloud computing introducing a cross-cloud architecture called VMware Cloud Foundation. I remember last year having a focus on their on vCloud Air product, but this year it seems that they are seeing that shift in the market that has accelerated dramatically over the last 6-12 months. 

I think a lot of this comes down to automation – more specifically, how IT is delivering its services. It just seems that there are certain subsets of organizations that need services delivered in a different fashion. We also saw a number of companies hit the stage that talked about this challenge.

Nonetheless, I think this was one of the better keynotes I’ve seen in a while and VMware clearly understands where the market is shifting to. They made numerous references to the year 2006 and where they were positioned at that time. Taking into account what they’ve done to date, I think they have that vision down.

There was a slide that showed that they estimate 2021 being the year that we hit 50% of workloads being served out of public clouds. As application delivery changes (and it is rapidly), I can see us hitting that before that year. 


vSAN Node Removal Disk Cleansing

Hyperconvergence is great and now gives us the ability to not be dependent on a centralized storage array (SAN) like we’ve all been accustomed to. Adding nodes to
scale our vSAN environment is simple to do (depending on your switch infrastructure) and can be done on the fly.

Removal of those nodes is a fairly straight forward process but there are some cleanup steps that need to be done in order to repurpose those nodes for other environments.
You can validate that your node is no longer part of Virtual SAN Clustering by issuing the following command:

[root@machinename:~] esxcli vsan cluster get
You should see “Virtual SAN Clustering is not enabled on this host” if the host has been properly removed from Virtual SAN.

Ok? Great, you can now proceed to the fun part.

Warning: Make sure that your vSAN node is out of the cluster and that you’ve remove the vmkernel interface from the host!

Once a system has been removed from the vSAN cluster, the storage is no longer
considered as a “part” of the array. But, in order for you to reuse those nodes
for something else, you need to clean up the remnants of what vSAN has left
behind on those local disks.

If you attempt to put that node into an new or different environment, you’ll
quickly notice that none of the disks are usable since they still have the old
vSAN partition information on them. We can find this out by issuing the following
command on the node via the console/ssh session:

[root@machinename:~] esxcli vsan storage list

This produces a list of all the disks that are claimed and you will see each one
with a “naa.xxxxxxxxx” format as the identifier. You’ll also notice that each one
is identified as being SSD or HDD through the line “Is SSD:” with a value of true
or false.

Cleaning these drives can be done by collecting the identifier of the disk and
issuing the following command for removal:

[root@machinename:~] esxcli vsan storage remove –disk=naa.xxxxxxx <where xxxxxxx
is the identifier of your disk>

This is done for spinning disks only. If you want to remove an SSD, you need to
use the –ssd switch to specify. Again, you can derive this information from the
storage list mentioned above.

The Shortcut!

In a hybrid vSAN environment, there is a requirement for at least one SSD for each
disk group. When the disk groups are formed, the spinning drives are “tied” to the
SSD drive and are dependent on it while the node is standalone.

This can be used to our advantage when doing disk cleaning since we don’t have to
remove each HDD individually and can simply call out the SSD in the vsan storage
remove command! Simply collect all “IS SSD: true” disks from your storage list
output and issue the esxcli vsan storage remove –ssd=naa.xxxxxxx command!

Bam! Now all disks are free from old partitioning and ready to use in your new

P.S. – You’ll probably notice that the datastore name sticks on the hosts that you
just removed (regardless of the fact that the disks have been removed). This seems
to be cosmetic since a creation of a new vSAN cluster replaces this with the
default “vsanDatastore”.