vMotion SQL Report

I created this report a long time ago when vMotion was viewed w/ much skepticism.  It's proved quite useful even to this day not to only prove that vMotion works, but as a troubleshooting tool to make sure vMotion wasn't the 'cause' of problems.

As unlikely as it may be the 'cause' of issues, transparency helps and 'knowing' the root cause of issues only strengthens the case for a software defined datacenter.  <stepping off soapbox>

Anyway, here are the meat and potatoes:

Query is set to EST and implements daylight savings time on appropriate dates.  You can change the numbers highlight in red to match your time zone.
SQL Query for the Dataset:

SELECT        ENTITY_NAME AS [VM Name], COMPLETE_STATE AS Status, CANCELLED AS Cancelled, CASE WHEN START_TIME >= '11/1/09 02:00:000' THEN DATEADD(hour, - 4
                         START_TIME) WHEN START_TIME BETWEEN '04/1/09 02:00:00.000' AND '11/1/09 01:59:59.999' THEN DATEADD(hour, - 3, START_TIME) 
                         WHEN START_TIME BETWEEN '11/1/08 02:00:00.000' AND '04/1/09 01:59:59.999' THEN DATEADD(hour, - 4, START_TIME) WHEN START_TIME BETWEEN 
                         '04/1/08 02:00:00.000' AND '11/1/08 01:59:59.999' THEN DATEADD(hour, - 3, START_TIME) ELSE START_TIME END AS [Start Time], DATEADD(hour, - 4
                         COMPLETE_TIME) AS [Complete Time], USERNAME AS Username
FROM            VPX_TASK
WHERE        (DESCRIPTIONID = N'vim.VirtualMachine.migrate') OR
                         (DESCRIPTIONID = N'Drm.ExecuteVMotionLRO')
ORDER BY [Start Time] DESC

The returned values for 'status' and 'username' are not very user friendly so here are some expressions I drew up to return some 'friendlier' values:
Status: =IIf(Fields!Status.Value = "success","Completed Successfully","Failed, Check Host Logs")
Username: =Iif(Fields!USERNAME.Value = "","DRS Automated",Fields!USERNAME.Value)

When DRS vMotions a VM, it does so as a null user.  Rather than return a blank field, I fill it in w/ "DRS Automated".  In the end, this is the type of report you can end up with in SQL reporting services:

Add Portgroups/VLANs to vmware standard switches via PowerCLI

Wrote a simple little script to insert a portgroup into a targeted vSwitch of all VM hosts in a targeted cluster.  This is not an issue if you use distributed vSwitches.

$vCenterName = Read-Host -Prompt "Please provide name of vCenter server"
$vCenter = Connect-VIServer $vCenterName

If ($? -ne $true){
Write-Host "$($vCenterName) appears to be invalid, please rerun script w/ correct vCenter name."

$ClusterName = Read-Host -Prompt "Provide name of cluster you'd like to add a new portgroup to"
$Cluster = Get-Cluster $ClusterName

If ($? -ne $true){
Write-Host "$($ClusterName) appears to be invalid, please rerun script w/ correct cluster name."

$VLAN = Read-Host -Prompt "Please provide VLAN ID: (0-4094 are valid values)"
$PGName = Read-Host -Prompt "Please provide name of port group: (i.e. 10.64.120.x)"
$vSwitchName = Read-Host -Prompt "Please provide vSwitch ID you'd like to add the portgroup to: (i.e. vSwitch2)"

$TargetHosts = $Cluster | Get-VMHost
    Foreach ($VMHost in $TargetHosts)
    $VMHost | Get-VirtualSwitch -Name $vSwitchName | New-VirtualPortGroup -Name $PGName -VLanId $VLAN

Disconnect-VIServer $vCenter -Confirm:$false

LDAP UCS Group Maps w/ AD groups more than 1000 members bug?

[SHORT UPDATE: My hypothesis was wrong]
[FULL UPDATE: Click here]

Seems like I always run into bugs w/ UCS's LDAP and AD integration.  This time it appears that UCS has issues w/ associating users that are members of AD groups that contain more than 1000 members.  I say 1000 members because in all likelyhood UCS's programming is calling this method:

In my case, I was referencing 'domain users' and granting read-only.  Testing the users from the CLI interface would show that the user account would authenticate just fine like as follows:
connect nxos
test aaa server ldap nameofADserver usernametoTest cleartextpassword
user has been authenticated


In the end, the problem seems to be that UCS is unable to map the user to the group that grants the UCS role access because of the 1000 member limit.

Quite simply, map an AD group that has less than 1000 members to an UCS defined role.  I've opened a TAC case for further investigation.

Get Dell ESX host warranty info via PowerCLI version 2

Originally made to quickly see which ESX hosts are in or out of warranty.  The Dell Management plugin still doesn't seem to give this information interestingly enough.  Anyway, my old script doesn't work these days because the property for service tag doesn't exist @ the vCenter level.  It does exist @ the host level though, so I had to work a little magic.

Here is an screenshot example of you can end up with:

  • Dell changed their warranty site so the ShipDate field is incorrect.  Pulling the site string down only faithfully pulls down the warranty end date.  If that field is important to you, then feel free to share w/ me how I can pull that info along w/ the end date.
  • The script also assumes you have the same root password on all your hosts.  If you have a different password, then you'll need to generate an xml credential file for each.
  • It's designed to grab data from your vCenter server for your list of ESX hosts.  It then uses that list to loop connect through each of your ESX hosts and puts them into an array variable.
  • These should be applied in the context of the account you plan to run this under in a scheduled task fashion.
    • If your ESX servers are not signed by a trusted CA, you'll need to set your powercli configuration to ignore certificate errors:
      • Set-PowerCLIConfiguration -InvalidCertificateAction:Ignore
    • Since you are working w/ multiple VI server connections, you may need to set your defaultVIservermode to multiple
      • Set-PowerCLIConfiguration -DefaultVIServerMode:Multiple
Click through for the code: