Powershell: CPU Load Generator

Found this snippet online.
foreach ($loopnumber in 1..2147483647) {$result=1;foreach ($number in 1..2147483647) {$result = $result * $number};$result}

Works great, but only seems to hit a single CPU.  In order for it fully load all CPU's, I decided to augment it by simply having it launch a powershell window per CPU/Core found w/ the same script running in a loop.

Here is what I came up w/ below:
#$NumberofProcs = (Get-WMIObject win32_processor | Measure-Object NumberofLogicalProcessors -sum).sum
#Updated based on anonymous feedback.
$NumberofProcs= [int]$env:Number_of_Processors
While ($NumberofProcs -ne 0) 
Start Powershell.exe -ArgumentList '"foreach ($loopnumber in 1..2147483647) {$result=1;foreach ($number in 1..2147483647) {$result = $result * $number};$result}"'
For some context, I was using this script to force vRealize Operations to send a notification for anomalous behavior on a typically low use VM. Thanks anonymous! I'd credit you if I knew who you were.

vSAN Cost-Effective Architecture (For Desktops, almost there for servers)

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:
  1. Additional vSphere license cost
  2. Additional VSAN license cost
  3. 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 CPU/RAM capacity.
Disclaimer: Mac Mini's are completely unsupported by VMware, this is for illustration purposes only.
Unfortunately, you can only circumvent the additional SSD/Disk costs.  You still need to purchase the vSphere and VSAN license.  If you ever need additional storage capacity and/or I/O performance you can simply slot in SSD's/Disks into those compute-only nodes at a later date.  It would be much nicer if you could circumvent vSAN licensing for those compute-only nodes while they do not provide storage.

However, in the VMware Horizon suite model, this type of architecture can play in your favor as VSAN is included and based upon a concurrent user model.  In this way you actually circumvent licensing completely, assuming you have enough concurrent users, and only need CPU/RAM/Storage.

I was happy to see that VSAN for the Horizon suite now includes all-flash VSAN now and that it is not a separate cost.  Unfortunately, VMware is still treating VSAN like they did vMotion back in the day.  You want All-Flash VSAN for servers?  That's extra.  Stretched VSAN Cluster?  Well, that's included when you buy all-flash.  Can you buy it separately?  No.  Ugh.  I'm going back to my previous stance, "All-Flash" should be included in the base license.  It feels stupid otherwise.  Features like "Dedupe", "Erasure-Coding", and "Stretch Cluster" should be and make sense as add-ons as they don't necessarily require specific hardware.  At least, not that I'm aware of yet.

vSphere Web Client (vCSA) stuck on authenticating

Related to vSphere 5.5 and vCenter Server Appliance.

Basically, when attempting to log into the web client I would get the following error message or the dreaded authenticating forever loading bar:
Could not connect to vsphere web client contact your administrator to fix this issue

Long story short, I did the following to fix my problem:

  1. Switched to embedded SSO and back to external SSO.
    1. Honestly, this step may or may not have been needed, but I did notice errors in my SSO server logs.  You might try step 2 first just to see.
  2. Under the admin tab select Yes for certificate regeneration and hit submit.

    1. Then switched back to no.
  3. Restarted Web Client Service.
Thankfully, I had another vCenter appliance attached to the same SSO server that was working fine.  So to troubleshoot, I looked at the virgo logs for the web client on the one that was working and that one that was not.  I noticed that my working vCenter Web Client would get a response back from the SSO server requesting a session.  The entries looked like this:

70008563 100113 200025 com.vmware.vise.security.DefaultAuthenticationProvider            Retrieving session listeners for sessionId 100113, clientId 200025 

session-init-pool-15127      70008563 100113 200025 com.vmware.vsphere.client.security.sso.SsoTokenLifetimeManager    Registering session : 100113

On the one that was not working, the second entry would never show up.  This told me there was something wrong w/ the communication between the SSO server and the VCSA having the issue.  That led me to unregister the VCSA from the external SSO server and use switch to the embedded one then back.  This didn't seem to fix the problem, so my next thought was to have the VCSA regenerate its certs.

Did that and after restarting the web client service, seemed to fix the issue described above.  I'm pointing that the cert regeneration was all that might have been needed, but unsure if unregistering and registering back played a role in fixing the issue as well.  Basically listing it just in case.