Zsoldier's Tech Blog

Summary: Creating or Subscribing to a Content Library on vSAN is typical practice, but the annoying side effect?  Objects created on vSAN datastore that show up as "unassociated" objects and guess what, they simply inherit the Cluster's default VSAN policy at time of import.  Yeah, dumb right?  Also, by vSAN Operations Guide Standards section 6721 subsection 4 , you shouldn't do this. So then what? In Azure VMware Solution(AVS) , you have a couple of options.  You can do what the operations guide tells you that you shouldn't do or you can do something better.  Regardless of these options, the one thing you should do, is create a global content library.   Create Global Content Library:  here are instructions to create one on an Azure blob store. You should do this, makes life easier if you can. Also a fun little experiment to play w/ Azure Functions Centralized Storage of your ISO/OVF's etc. Attach external storage (Not necessary, but I'll explain ...

Summary: Basically while testing stretch cluster, we ran into strange failover behavior.  The fact that it was not simply occuring.  During this testing, we found a dirty little secret about stretch cluster failovers.  One that makes me rethink if stretch clusters really is worth doing. Documented Failure Scenarios Details: All documented scenarios effectively deal w/ a 'single' type of failure.  The problem is disasters/failures can be multi-faceted and cascading in some instances.  Taking the Secondary Site Failure or Partitioned scenario and adding the 'cascading failure' to it and you end up in a whole world of trouble depending on the next 'failure'. Below effectively depicts the failure of the interconnect between the two sites.  The problem this fails to take into account is that there are typically 3 things involved to this.   The networking between the two sites The preferred site routers The secondary site routers So here is a slightly ...

Summary: A cache disk failed in my host taking along with it the disk group.  This is expected behavior, but for some reason, the disk group also disappeared from GUI so I couldn't decommission the disk group to basically replace the cached drive.  So, had to do it through powercli/esxcli.  Wish I took a screenshot, cause it was kind of annoying. PowerCLI Example: Once you've deleted the offending disk group, you can now create a new disk group utilizing the replaced cache disk and former capacity disks.

Summary: Was going through and attempting to setup new vSAN cluster but noticed that the wizard was only showing 3 of 4 disks from 3 of 4 hosts and 0 disks from another host.  This appears to be by design where the setup wizard will only target disks that have 0 partitions.  Makes sense. This, however, is not obvious in the setup. Solution: Simply delete any partitions from those disks that you'd like to have vSAN claim.  You can do this enmasse via PowerCLI or the Web Client interface (as pictured below). [ Warning: This is a destructive process so be sure that you know absolutely for certain that you are targeting the correct storage devices.  This is especially true if you plan to script this process.] Erase Partition in Web Client The above process would suck if you were doing it against a large cluster, so learn to do it in powershell or some other automated method. PowerCLI Method: $TCluster = Get-Cluster TargetClusterName $TVMHosts = $TCluste...

Script that I'm putting together to configure new all-flash vSAN clusters.  Still a work in progress, I plan on making it into a function once I've worked out the kinks.  Hosting it on gist.github.com so feel free to make suggestions.

Summary: While configuring my hosts, I ran into various issues.  One host simply decided to stop talking and the hostd service became unstable.  This meant vCenter could not access the ESXi host to manage it.  One issue I had was that my hosts were missing PTR entries, but even w/ that resolved, I was still stuck w/ one host having issues. Quick Fix (Assumes no data on vSAN disks, use info at your own risk): Assuming you have vSAN claimed disks, this is how you can clear them up. Gather your list of disk on the host using this command: ls /vmfs/devices/disks Ones appended w/ a :1 or 2 are typically your vSAN disks, you can double check using this command: partedUtil getptbl /vmfs/devices/disks/naa.################# Return looks like this: Once you've determined which ones have those partitions, delete them: partedUtil delete /vmfs/devices/disks/naa.################# 1 partedUtil delete /vmfs/devices/disks/naa.################# 2 Once all have bee...

So my esteemed colleague, Andrew Harding , brought this to my attention and the idea has kind of blossomed.  I thought it was rather clever approach to implementing VSAN in a cost effective manner. The current line of thinking w/ VSAN is that you buy each host w/ the exact same disk configuration. In this way, with each host purchase, you not only get capacity, but you get additional I/O and CPU/Memory performance. Disclaimer: Mac Mini's are completely unsupported by VMware, this is for illustration purposes only. There are a couple problems w/ this model: Additional vSphere license cost Additional VSAN license cost Additional Hardware SSD/Disk cost Being that VSAN does NOT attempt to keep VM storage data local to a host, you can augment your VSAN cluster w/ simple compute hosts that have no storage.  Meaning, if you don't have storage capacity or I/O performance problems, you can simply add another host that does not participate in the VSAN for additional C...

From my understanding all-flash vSAN works like this: Caching Tier is 100% Writes. (Write Buffer) Capacity Tier is Mixed-Use With this in mind, I ordered Dell R730's w/ two types of drives.  Two high write endurance SSD's and Four Mixed Use SSD's. Short Story: Here is the script I created to 'tag' the mix-use drives as flash capacity: #Enable All Flash vSAN Intelligently Add-PSSnapIn -Name VMware.VimAutomation.Core -ErrorAction SilentlyContinue $TargetHosts = Get-VMHost $CacheDiskVendor = "TOSHIBA" $CacheDiskModel = "PX02SSF040" $CapacityDiskVendor = "TOSHIBA" $CapacityDiskModel = "PX02SMF040" Foreach ($VMhost in $TargetHosts) { $ESXCLI = $VMHost | Get-ESXCLI $Storage = $VMhost | Get-VMHostStorage Foreach ($SCSILUN in $Storage.ScsiLun) { If ($SCSILUN.Vendor -match $CapacityDiskVendor -and $SCSILUN.Model -match $CapacityDiskModel) { $ESXCLI.vsan.storage.tag....

Enjoyed my conversation w/ William talking about my ghetto MacCloud setup.  You can read the interview here: http://www.virtuallyghetto.com/2014/08/community-stories-of-vmware-apple-os-x-in-production-part-4.html Some things people have asked me for clarification: We are using Mac Mini 'Server' versions.  These have two drives by default. You can get a kit to add a second drive to the standard mac mini version. Mgmt and VM traffic flows over Standard vSwitch0 (Onboard as Uplink) vSAN and vMotion flows over dVS (Thunderbolt as Uplink) Onboard 1Gb and Thunderbolt 1Gb adapter Booting to USB thumb drive plugged into the back of the Mac Mini w/ ESXi. vCenter is a vCSA built and running on another vCenter instance.  Here is what it looks like configured: