|Example vSphere Alarms Alert|
Sunday, September 1, 2019
Wednesday, January 30, 2019
Automation being king, this will do it. The general process for each host:
- Set the syslog destination
- Insure a firewall exception
- Restart the syslog service.
Wednesday, December 26, 2018
I'm documenting here so that I don't forget the solution. It's my remind-future-self post.
While I found plenty of Google hits with a similar complaint, I hadn't found any solutions that worked for me.
The vCommunity is great, so a quick tweet was met with a quick reply from buddy Bob Plankers:
When running PerfMon (I suppose that I should do so more often) I received an error:
My next stop was a Technet article which did the trick:
- lodctr /r
- lodctr /q to find anything disabled.
- lodctr /e:"performance counter" to enable
Tuesday, December 18, 2018
Thursday, January 19, 2017
While investigating some stability issues we noticed something interesting:
That's one device and the LUN IDs should be the same. In this configuration, vSphere sees the same device multiple times.
What's more, the vSphere GUI is doing us a "favor" and condensing the output. Using esxcli we can confirm that there are, in fact, more than 4 paths:
Whoa Nelly! I've condensed the output some, but that's 12 paths instead of 4. Each LUN ID represents one set of paths.
The 3PAR GUI confirms:
This particular virtual volume was exported directly to the host twice and once indirectly via a Host Set. Yeah, don't do that!
Determining the Scope of the IssueI found a thread on VMware Communities from Markus Kraus, where he saw the same issue, although ultimately from a different cause. Markus has a blog post too, with a great script and vCheck plugin!
Using Markus' script, I was able to determine all devices with more than one LUN ID. Now we know how prevalent the issue is and which LUNs are involved on each particular vSphere host.
UnwindingWhile we like 3PAR Host Sets, our implementation was incomplete. Moving toward completion has the potential of causing more problems because exports are also tied to the Host Sets. The biggest sin here was mixing the use of direct host exports and exports in Host Sets.
With the right attack plan we can work on one vSphere host at a time without any outage:
- Place a host into Maintenance Mode.
- Remove the host from any 3PAR Host Set.
- Remove host-based duplicate virtual volume exports one at a time.
- Rescan HBAs.
- Exit Maintenance Mode.
showhostsetShow Virtual Volumes exported to a host:
showvlun -sortcol 1 -host <host>
removehostset <setname> <host>
removevlun <vvname> <lunid> <host>What I found to work best is to first remove the host from any Host Set followed by a rescan of the vSphere host HBA. When that is completed, unexport any duplicate exports by removing the highest LUN ID(s). Then rescan HBAs again.
Keep in mind that VVNames and Host Set Names are case sensitive.
- removehostset My-Host-Set host-9
- Rescan HBA
- removevlun NL-THIN-3 34 host-9
- removevlun NL-THIN-3 33 host-9
- Rescan HBA
- showvlun -sortcol 1 -host host-9
- Verify with esxcli storage core path list --device <device>
Monday, March 14, 2016
VMware has just updated, re-titled, and published "Architecting Microsoft SQL Server on VMware vSphere -- Best Practices Guide."
There looks to be some pretty good information within, so get comfortable and grab the PDF here.
Wednesday, December 9, 2015
If you are configuring vSphere hosts for syslog collection you may be overwhelmed by the amount of data thrown at your collector. By default hostd and vpxa are configured for a logging level of “verbose.”
To view the configuration for all of your vSphere hosts, break out PowerCLI. I’m forever forgetting how to retrieve information from certain cmdlets and include the host name. Here it is for me to find again:
Setting hostd and vpxa logging levels on all hosts to “info” is pretty easy: