vSphere NFS Connection Status Alarm Auto-Remediation

One minor annoyance I had when moving to a new company was a load of alerts that were simply noise.  Not to anyone's fault, but simply poor default VMware implementation.

VMware comes packaged w/ an alert to notify when a storage path is down.  The problem is that, that's all it does.  So say you have the SNMP traps generated from that to create a ticket.  Great, now you have a ticket, but little did you know that the problem fixed itself via some failover method.

So now you have a ticket, you were woken up in the middle of the night for something that was benign.  Wouldn't it be great if another SNMP trap were sent that said "Hey, I'm ok now, close out the ticket"?

The assumption is that the SNMP trap collector, like HP's BSM/SiteScope tool, were smart enough to associate a trap to the same alarm.  Which, in my case, it does.  So here is how I redesigned an NFS alarm to send trap stating a problem and then having that alarm send a trap designating everything is ok.

Some interesting results from the Project VRC State of VDI/SBC Survey

I can't publish all the results, but they will be available here on March 24th, 2015.

Here are two that I found rather interesting that I can publish early:

XenDesktop seems to be the incumbent VDI solution for the survey respondents.  I knew that Citrix had been around a long time, but still rather surprised that it's still trumping VMware's Horizon View.  I probably shouldn't be though as Citrix has always advertised their solution very well and feature functionality always seems to be ahead of View.  Although, seeing XenDesktop in practice on vSphere infrastructure doesn't give me the warm and fuzzy's especially leading into the next question.
How updates are installed/updated/managed responses doesn't really surprise me, but it does bother me.  Manually updating images seems so archaic and I'm quite frankly surprised that VMware hasn't made updating Parent VM's a more automated process.  Being that the respondents were also Citrix heavy, I feel this bodes poorly for their product on the automated operations front as well.

The only way I've hypothesized to update parent VM's in a somewhat automated process is to:

  1. power-up the parent VM 
  2. query SCCM for the related VM 
  3. wait for a 'success' of applicable 'some time window' updates.  
  4. Power off VM
  5. Snapshot it
  6. Delete old snapshots (based on some time window and count)
  7. WinRM call powerCLI cmdlets on View Brokers to then associate pool to new snapshot.

I think if I remember correctly, doing that last step was not possible or somewhat very difficult because the cmdlets didn't have this capability.  Something to look into again I suppose.  I also have thoughts on using WinRM in a 'cloud' fashion against View Brokers.  I'm working on an article that I'll publish later w/ my thoughts and practical application of this thought.