Sunday, September 1, 2019

Send Active vSphere Alarms to Microsoft Teams

One of the ways that we have been driving adoption of Microsoft Teams at work is by automatically pushing useful content into channels via its webhook support.

I've pushed alarms from our general monitoring system into Teams and it removes the limitation of short text messages while providing more details on an issue before resorting to using the corporate VPN.  I simply arm myself with the Microsoft Teams app on my phone.

I thought about what else might benefit from the ability to see details while on the go and came up with active vSphere alarms.  I wanted to be able to get details on active alarms, the time they started, their status (severity, if you ask me) and the objects and clusters involved.

I started playing around with PowerShell and soon had rudimentary alarm data going into a Microsoft Teams channel.  But what if I am or can be connected to work? 

I added a button to open the vSphere Client and then an alarm-specific button that opens the vSphere Client summary page for the object: 

Example vSphere Alarms Alert
Setting it all up is pretty straightforward: create an incoming webhook connector in Microsoft Teams, save the URL, and schedule the PowerShell to run at a frequency of your choosing.

Adding a Webhook

Open Microsoft Teams, choose or create a new Team, choose or create a new channel within that Team, and then select the three dots to the right of the channel name to create a connector.  The screenshots below will help lead you along, but it's pretty simple.  Be sure to save the link that is generated for your connector.  You can always go back and manage the configured connectors on your channel if you need to get the URL again.






Scheduling

Save the PowerShell at the bottom of this article and save it on a server somewhere so that you can set it up as a Scheduled Task.  Invocation is easy, and you will need to provide your vCenter FQDN and Microsoft Teams webhook URL as part of the program/scripts arguments:

-ExecutionPolicy Bypass -file Send-vSphereAlarms.ps1 -vcenter vcenter-fqdn -TeamsUri uri

I like to configure the task to run every 10 minutes, but pick what works best for you and your environment.  

I'm certain that a lot can be changed in the script. Play around and enjoy!

Send-vSphereAlarms.ps1


<#
.SYNOPSIS
Post active vSphere alarms to a Microsoft Teams channel.
.DESCRIPTION
Connect to the specified vSphere vCenter, query for all active alarms, and post those
as a card to Microsoft Teams via a Webhook.
The card will contain one section per alarm with a few facts: the cluster involved,
the date and time of the alarm, the alarm status (yellow/red/etc), and whether
or not the alarm has been acknowledged.
The card will also have a button to visit the vCenter UI while each (alarm) section
has a button that goes directly to that object's summary tab in vCenter.
Hat tip to @ericblee6, who pointed me toward @TheLazyAdmin's article below. That gave
me a new way to form the collections and format the webhook data.
https://www.thelazyadministrator.com/2018/12/11/post-inactive-users-as-a-microsoft-teams-message-with-powershell/
.PARAMETER vCenter
The vCenter server to be queried and linked to.
.PARAMETER TeamsUri
Your Microsoft Teams WebHook URI. To get this, add a Connector to a Teams Channel and
copy the provided URL.
#>
param (
[Parameter(Mandatory = $true)][ValidateNotNullOrEmpty()][string]$vCenter,
[Parameter(Mandatory = $true)][ValidateNotNullOrEmpty()][uri]$TeamsUri
)
# Indicators found in MoRef for types of resources.
$clusterInd = "ClusterComputeResource-"
$hostInd = "HostSystem-"
$vmInd = "VirtualMachine-"
# Return active alarms from vCenter
function Get-Alarms() {
[CmdletBinding()]
param (
[string]$vCenter
)
try {
if ($global:DefaultVIServer.ServiceUri.Host -ne $vCenter) {
Connect-VIServer $vCenter | Out-Null
}
# we need the Uuid for direct-reference vCenter URLs
$Script:vcUuid = $global:DefaultVIServer.InstanceUuid.ToUpper()
}
catch {
Write-Output "Failed to connect to $vCenter"
return $null
}
$Clusters = Get-View -ViewType ComputeResource -Property Name, OverallStatus, TriggeredAlarmstate
$report = @()
$AlarmClusters = $Clusters | Where-Object { $null -ne $_.TriggeredAlarmState }
foreach ($ac in $AlarmClusters) {
foreach ($ta in $ac.TriggeredAlarmstate) {
$object = [PSCustomObject]@{
'AlarmTime' = (($ta.Time).ToLocalTime()).ToString()
'AlarmStatus' = $ta.OverallStatus.ToString()
'AlarmAcked' = $ta.Acknowledged
'Cluster' = $ac.Name
'ImageUrl' = ''
'Entity' = ''
'Type' = ''
'MoRef' = $ta.MoRef
'TriggeredAlarms' = (Get-AlarmDefinition -Id $ta.Alarm.ToString()).Name
}
$entity = $ta.Entity.ToString()
if ($entity -like "$($clusterInd)*") {
$object.Entity = $ac.Name
$object.Type = "Cluster"
$object.MoRef = $ac.MoRef
$object.ImageUrl = "https://i.imgur.com/iq2BkLQ.png"
}
elseif ($entity -like "$($hostInd)*") {
$vmHost = Get-VMHost -Id $entity
$object.Entity = $vmHost.Name
$object.Type = "VMHost"
$object.MoRef = $entity
$object.ImageUrl = "https://i.imgur.com/k22bhCD.png"
}
elseif ($entity -like "$($vmInd)*") {
$vm = Get-VM -Id $entity
$object.Entity = $vm.Name
$object.Type = "VM"
$object.MoRef = $entity
$object.ImageUrl = "https://i.imgur.com/Y0ShH0n.png"
}
$report += $object
}
}
return $report
}
# Grab the alarms
Write-Output "Querying active vSphere alarms from $vcenter"
$Alarms = New-Object System.Collections.Generic.List[System.Object]
Get-Alarms($vcenter) |
Sort-Object Cluster, Time, Entity |
ForEach-Object {
# throw into a collection consumable by Teams
$Alarms.add($_)
}
# Build the card sections, one per alarm. Stuff them into a collection
# consumable by Teams
$Sections = New-Object System.Collections.Generic.List[System.Object]
foreach ($a in $Alarms) {
# Determine query string that lands us on our object in vCenter. It uses the MoRef, but
# with the first "-" replaced and the vCenter UUID
$qs = "#?extensionId=vsphere.core.vm.summary&objectId=urn:vmomi:$($a.MoRef):$($vcUuid)"
$qs = $qs -replace "(.*:vmomi:[a-z]+)-(.*)", '$1:$2' # adjust formatting
$s = @{
activityTitle = $a.Entity
activitySubtitle = $a.Type
activityText = $a.TriggeredAlarms
activityImage = $a.ImageUrl
activityImageType = "article" # avoid rounded corner icons
potentialAction = @(
@{
'@type' = "OpenUri"
name = "Visit Object"
targets = @(
@{
"os" = "default"
"uri" = "https://$($vcenter)/ui/$($qs)"
}
)
}
)
facts = @(
@{
name = 'Cluster'
value = $a.Cluster
}
@{
name = 'Alarm Time'
value = $a.AlarmTime
}
@{
name = 'Alarm Status'
value = $a.AlarmStatus
}
@{
name = 'Alarm Acked'
value = $a.AlarmAcked
}
)
}
$Sections.Add($s)
}
# Post it if you got it
$count = $Sections.Count
if ($count -gt 0) {
$text = "There $(if ($count -gt 1) {'are'} else {'is'}) $count active alarm$(if ($count -gt 1) {'s'} else {''}) at $(Get-Date)"
Write-Output $text
$body = ConvertTo-Json -Depth 8 @{
title = "Active vSphere Alarms via $($vCenter)"
text = $text
sections = $Sections
potentialAction = @(
@{
'@context' = 'http://schema.org'
'@type' = "ViewAction"
name = "vCenter"
target = @("https://$($vcenter)/ui/")
}
)
}
Write-Output "Posting $($count) sections to WebHook $($TeamsUri)"
Invoke-RestMethod -Uri $TeamsUri -Method Post -Body $body -ContentType 'application/json'
}

Wednesday, January 30, 2019

vSphere Syslog Slam

Maybe you are like me and you have a new syslog destination (SIEM is grand).  Maybe you want to ensure that all of your vSphere hosts are configured the same.

Automation being king, this will do it.  The general process for each host:
  1. Set the syslog destination 
  2. Insure a firewall exception 
  3. Restart the syslog service.
In vSphere 5.1 the Set-VMHostSysLogServer cmdlet was added to PowerCLI.  While there are other ways to accomplish the same task, I tend to prefer using any method that is more obvious when coding.  Set-VMHostSysLogServer it is.

$syslog = 'udp://1.2.3.4:514' # change to your syslog host
$Hosts = Get-VMHost | Sort-Object Name
$Hosts | ForEach-Object {
try {
Write-Output "Setting $_ Syslog to $syslog"
Set-VMHostSysLogServer -VMHost $_ -SysLogServer $syslog -ErrorAction Stop | Out-Null
}
catch [Exception] {
Write-Output " Operation failed."
continue
}
$res = Get-VMHostSysLogServer -VMHost $_
if ("$($res.Host):$($res.Port)" -eq $syslog) {
# the setting took, add firewall exception and restart the service
Write-Output " Enabling syslog firewall exception on $_"
Get-VMHostFirewallException -VMHost $_ -Name "syslog" | Set-VMHostFirewallException -Enabled:$true | Out-Null
Write-Output " Restarting Syslog on $_"
$esxCli = Get-EsxCli -VMHost $_ -V2
if ($esxCli.system.sysLog.reload.invoke()) {
Write-Output " Reloaded"
}
}
}
view raw Set-Syslog.ps1 hosted with ❤ by GitHub
Cheers!

Wednesday, December 26, 2018

VMware Authorization Service High CPU Usage

When running VMware Workstation on Microsoft Windows, the VMware Authorization Service (vmware-authd.exe) may place a high CPU load on the system.  Upgrading from Workstation 14 to the latest Workstation 15 had no impact, so it's not something that VMware recently fixed.  I remember the issue from many years ago, but not how to resolve the situation.

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:

Bob's reply sent me to an article on michlG's blog.   The proposed solution did not fit my particular circumstances, but it got me on the right track: looking at Windows performance counters.  

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:

  1. lodctr /r
  2. lodctr /q to find anything disabled.
  3. lodctr /e:"performance counter" to enable






Tuesday, December 18, 2018

Windows Registry: Loading and Unloading All User Hives

Today my team was discussing the need to search all user registry hives when scanning for malware.

It's not too bad to do this manually if there are a two user profiles on a system, but it gets considerably more tedious on common-use PCs with more user profiles.  And I'm lazy.

The process might also prove handy for other registry-related tasks, where perhaps can't use Group Policy to be lazy.

Queue Load-UserHives.ps1. This quick-and-dirty PowerShell will search the system for available user profiles and load each key.  Later, you can reverse this with the -Unload switch.  Rather than externally tracking what was loaded prior, a simple naming prefix is used for the unload process.

<#
.SYNOPSIS
Load/unload all discovered user hives into the registry
.DESCRIPTION
For the local machine, load all discovered user hives. Provide the option to then come
back and unload those same hives.
Why might you want to do this:
For scanning for viruses/malware, you want to insure that all
user keys are scanned as well.
Making a registry change for all local machine users.
.EXAMPLE
Load-UserHives.ps1 [-unload]
#>
param (
[Parameter(Mandatory = $false)][switch]$unload
)
$KeyPrefix = "temp-" # Append to each loaded hive as a key name
function Get-Confirmation($prompt) {
# Return $true if we get a "Yes"
#
$yes = New-Object System.Management.Automation.Host.ChoiceDescription "&Yes", "Off we go!"
$no = New-Object System.Management.Automation.Host.ChoiceDescription "&No", "Abort! Abort!"
$options = [System.Management.Automation.Host.ChoiceDescription[]] ($yes, $no)
($host.ui.PromptForChoice($null, $prompt, $options, 1) -eq 0)
}
if (-not $unload.IsPresent) {
$users = (Get-ChildItem -path ($env:USERPROFILE | Split-Path -Parent)).name
[gc]::collect()
Write-Output "Found $(($users | Measure-Object).Count) user folders."
if (Get-Confirmation("Load all user hives?")) {
foreach ($u in $users) {
# Load, but not our own which is already loaded
if ($u -notlike $env:USERNAME) {
Write-Output "Loading to HKU\$($KeyPrefix)$($u)..."
REG LOAD "HKU\$($KeyPrefix)$($u)" "C:\Users\$($u)\NTUSER.DAT"
}
else {
Write-Output "Skipping current user $($u)"
}
}
}
}
else {
$hives = (Get-ChildItem -Path Registry::HKEY_USERS\$($KeyPrefix)*).Name
[gc]::collect() # Free what we can in hopes of successful unloads
$count = ($hives | Measure-Object).Count
Write-Output "Found $($count) loaded hives."
if ($count -gt 0) {
$prompt = "Unload all loaded user hives?"
$yes = New-Object System.Management.Automation.Host.ChoiceDescription "&Yes", "Off we go!"
$no = New-Object System.Management.Automation.Host.ChoiceDescription "&No", "Abort! Abort!"
$options = [System.Management.Automation.Host.ChoiceDescription[]] ($yes, $no)
if (Get-Confirmation("Unload all loaded user hives?")) {
foreach ($h in $hives) {
Write-Output "Unloading $($h)..."
REG UNLOAD "$($h)"
}
}
}
}
Write-Output "Done."


Thursday, January 19, 2017

LUNs with Multiple Exports

We have a vSphere 5.5 environment with your standard multiple paths to shared storage.  In our case, 2 paths to each of 2 nodes in a 7000-series HPE 3PAR array.

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:

~ # esxcli storage core path list --device naa.60002ac000000000000000090000851c
iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:21220002ac00851c,t,122-naa.60002ac000000000000000090000851c
UID: iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:21220002ac00851c,t,122-naa.60002ac000000000000000090000851c
Runtime Name: vmhba38:C0:T5:L33
Device: naa.60002ac000000000000000090000851c
Device Display Name: 3PARdata iSCSI Disk (naa.60002ac000000000000000090000851c)
Adapter: vmhba38
Channel: 0
Target: 5
LUN: 33
Plugin: NMP
State: active
iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:21220002ac00851c,t,122-naa.60002ac000000000000000090000851c
UID: iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:21220002ac00851c,t,122-naa.60002ac000000000000000090000851c
Runtime Name: vmhba38:C0:T5:L34
Device: naa.60002ac000000000000000090000851c
Device Display Name: 3PARdata iSCSI Disk (naa.60002ac000000000000000090000851c)
Adapter: vmhba38
Channel: 0
Target: 5
LUN: 34
Plugin: NMP
State: active
iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:21220002ac00851c,t,122-naa.60002ac000000000000000090000851c
UID: iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:21220002ac00851c,t,122-naa.60002ac000000000000000090000851c
Runtime Name: vmhba38:C0:T5:L1
Device: naa.60002ac000000000000000090000851c
Device Display Name: 3PARdata iSCSI Disk (naa.60002ac000000000000000090000851c)
Adapter: vmhba38
Channel: 0
Target: 5
LUN: 1
Plugin: NMP
State: active
iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:20220002ac00851c,t,22-naa.60002ac000000000000000090000851c
UID: iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:20220002ac00851c,t,22-naa.60002ac000000000000000090000851c
Runtime Name: vmhba38:C0:T4:L1
Device: naa.60002ac000000000000000090000851c
Device Display Name: 3PARdata iSCSI Disk (naa.60002ac000000000000000090000851c)
Adapter: vmhba38
Channel: 0
Target: 4
LUN: 1
Plugin: NMP
State: active
iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:20210002ac00851c,t,21-naa.60002ac000000000000000090000851c
UID: iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:20210002ac00851c,t,21-naa.60002ac000000000000000090000851c
Runtime Name: vmhba38:C0:T2:L33
Device: naa.60002ac000000000000000090000851c
Device Display Name: 3PARdata iSCSI Disk (naa.60002ac000000000000000090000851c)
Adapter: vmhba38
Channel: 0
Target: 2
LUN: 33
Plugin: NMP
State: active
Transport: iscsi
iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:20210002ac00851c,t,21-naa.60002ac000000000000000090000851c
UID: iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:20210002ac00851c,t,21-naa.60002ac000000000000000090000851c
Runtime Name: vmhba38:C0:T2:L34
Device: naa.60002ac000000000000000090000851c
Device Display Name: 3PARdata iSCSI Disk (naa.60002ac000000000000000090000851c)
Adapter: vmhba38
Channel: 0
Target: 2
LUN: 34
Plugin: NMP
State: active
iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:21210002ac00851c,t,121-naa.60002ac000000000000000090000851c
UID: iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:21210002ac00851c,t,121-naa.60002ac000000000000000090000851c
Runtime Name: vmhba38:C0:T3:L1
Device: naa.60002ac000000000000000090000851c
Device Display Name: 3PARdata iSCSI Disk (naa.60002ac000000000000000090000851c)
Adapter: vmhba38
Channel: 0
Target: 3
LUN: 1
Plugin: NMP
State: active
iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:21210002ac00851c,t,121-naa.60002ac000000000000000090000851c
UID: iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:21210002ac00851c,t,121-naa.60002ac000000000000000090000851c
Runtime Name: vmhba38:C0:T3:L33
Device: naa.60002ac000000000000000090000851c
Device Display Name: 3PARdata iSCSI Disk (naa.60002ac000000000000000090000851c)
Adapter: vmhba38
Channel: 0
Target: 3
LUN: 33
Plugin: NMP
State: active
iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:21210002ac00851c,t,121-naa.60002ac000000000000000090000851c
UID: iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:21210002ac00851c,t,121-naa.60002ac000000000000000090000851c
Runtime Name: vmhba38:C0:T3:L34
Device: naa.60002ac000000000000000090000851c
Device Display Name: 3PARdata iSCSI Disk (naa.60002ac000000000000000090000851c)
Adapter: vmhba38
Channel: 0
Target: 3
LUN: 34
Plugin: NMP
State: active
iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:20220002ac00851c,t,22-naa.60002ac000000000000000090000851c
UID: iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:20220002ac00851c,t,22-naa.60002ac000000000000000090000851c
Runtime Name: vmhba38:C0:T4:L33
Device: naa.60002ac000000000000000090000851c
Device Display Name: 3PARdata iSCSI Disk (naa.60002ac000000000000000090000851c)
Adapter: vmhba38
Channel: 0
Target: 4
LUN: 33
Plugin: NMP
State: active
iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:20220002ac00851c,t,22-naa.60002ac000000000000000090000851c
UID: iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:20220002ac00851c,t,22-naa.60002ac000000000000000090000851c
Runtime Name: vmhba38:C0:T4:L34
Device: naa.60002ac000000000000000090000851c
Device Display Name: 3PARdata iSCSI Disk (naa.60002ac000000000000000090000851c)
Adapter: vmhba38
Channel: 0
Target: 4
LUN: 34
Plugin: NMP
State: active
iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:20210002ac00851c,t,21-naa.60002ac000000000000000090000851c
UID: iqn.1998-01.com.vmware:host-9-69836ca5-00023d000003,iqn.2000-05.com.3pardata:20210002ac00851c,t,21-naa.60002ac000000000000000090000851c
Runtime Name: vmhba38:C0:T2:L1
Device: naa.60002ac000000000000000090000851c
Device Display Name: 3PARdata iSCSI Disk (naa.60002ac000000000000000090000851c)
Adapter: vmhba38
Channel: 0
Target: 2
LUN: 1
Plugin: NMP
State: active
view raw gistfile1.txt hosted with ❤ by GitHub
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 Issue

I 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.

Unwinding

While 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:

  1. Place a host into Maintenance Mode.
     
  2. Remove the host from any 3PAR Host Set.
     
  3. Remove host-based duplicate virtual volume exports one at a time.
     
  4. Rescan HBAs.
     
  5. Exit Maintenance Mode.
We are not going to use the 3PAR GUI because it's not granular enough.  Removing a host from a host set would also remove the exports and risk impact on other hosts.  ssh into the 3PAR to access their rather nice CLI.
 
Our Command Set
 

List all Host Sets and their members:
showhostset
Show Virtual Volumes exported to a host:
showvlun -sortcol 1 -host <host> 
Remove the host from the Host Set:
removehostset <setname> <host>
Unexport from a 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.


Example Time



  1. removehostset My-Host-Set host-9
     
  2. Rescan HBA
     
  3. removevlun NL-THIN-3 34 host-9
     
  4. removevlun NL-THIN-3 33 host-9
     
  5. Rescan HBA
     
  6. showvlun -sortcol 1 -host host-9
     
  7. Verify with esxcli storage core path list --device <device>


Monday, March 14, 2016

Microsoft SQL Server on vSphere Best Practices Guide

Some of us have been running Microsoft SQL Server on top of vSphere for years. Maybe it was only for your pre-VCSA vCenter or maybe you have dozens of instances--but that doesn't stop an official Best Practices Guide from being good reading.

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

vSphere Host Logging Levels

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:

Get-VMHost | Sort-Object Name | ForEach-Object {
$h = New-Object PSObject -Property @{'Host' = $_.Name}
Get-AdvancedSetting -Entity $_ -Name 'Config.HostAgent.log.level','Vpx.Vpxa.config.log.level' |
ForEach-Object {
Add-Member -InputObject $h -Name $_.Name -Value $_.Value -MemberType NoteProperty
}
$h
}
view raw gistfile1.txt hosted with ❤ by GitHub

 

Setting hostd and vpxa logging levels on all hosts to “info” is pretty easy:

Get-VMHost | Get-AdvancedSetting -Name "Config.HostAgent.log.level","Vpx.Vpxa.config.log.level" |
Set-AdvancedSetting -Value "info" -Confirm:$false
view raw gistfile1.txt hosted with ❤ by GitHub