07 April 2010

Working with multiple default servers

Connect-VIServer has a new behavior/feature as of the 4.0 Update 1 release: "Working with multiple default servers." So what? So this: connecting to hosts that are not managed via a vCenter instance and taking actions against inventory items.
"vSphere PowerCLI supports working with multiple default servers. If you select this option, every time when you connect to a different server using Connect-VIServer, the new server connection is stored in an array variable together with the previously connected servers, unless the -NotDefault parameter is set. This variable is named $DefaultVIServers and its initial value is an empty array. When you run a cmdlet and the target servers cannot be determined from the specified parameters, the cmdlet runs against all servers stored in the array variable. To remove a server from the $DefaultVIServers variable, you can either use Disconnect-Server to close all active connections to the server, or modify the value of $DefaultVIServers manually."
(from http://www.vmware.com/support/developer/windowstoolkit/wintk40u1/html/Connect-VIServer.html)

An example of the new behavior in action:
PS C:\> Connect-VIServer vcenter4.local
WARNING: There were one or more problems with the server certificate:
* The X509 chain could not be built up to the root certificate.

Login Information
Please supply user credentials.
User: vNuggsAdmin
Password for user vNuggsAdmin: ***********

Name Port User
---- ---- ----
vcenter4.local 443 vNuggsAdmin


PS C:\> Connect-VIServer standAloneHost0.local
WARNING: There were one or more problems with the server certificate:
* The X509 chain could not be built up to the root certificate.
* The certificate's CN name does not match the passed value.

Login Information
Please supply user credentials.
User: root
Password for user root: ***********

Working with multiple default servers?

Select [Y] if you want to work with more than one default servers. In this case, every time when you connect to a different server using Connect-VIServer, the new server connection is stored in an array variable together with the previously connected servers. When you run a cmdlet and the target servers cannot be determined from the specified parameters, the cmdlet runs against all servers stored in the array variable.
Select [N] if you want to work with a single default server. In this case, when you run a cmdlet and the target servers cannot be determined from the specified parameters, the cmdlet runs against the last connected server.
You can change your preference at any time using the DefaultServerMode parameter of Set-PowerCLIConfiguration.
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): Y

Name Port User
---- ---- ----
standAloneHost0.local 443 root


PS C:\> $DefaultVIServers
Name Port User
---- ---- ----
standAloneHost0.local 443 root
vcenter4.local 443 vNuggsAdmin


PS C:\>
At this point, running a cmdlet that is not VIServer specific (as determined by the specified parameters) runs against all the servers to which this session is connected, namely "standAloneHost0.local" and "vcenter4.local." So, you can now act on all items in these servers' inventory.

A few notes:
  • If connecting to a vCenter instance and a host which is managed by that vCenter instance, cmdlets will return the items in the host's inventory twice: once when the cmdlet runs against the vCenter server, and once when the cmdlet runs against the host itself, since both will be in the $DefaultVIServers array.
  • The help for "Connect-VIServer" cmdlet mentions that "Working with a single default server is deprecated and will be removed in a future release.", so the time is now to familiarize one's self with multiple VIServer behavior.
  • As the message in the Powershell session above reads, one can adjust the single/multiple VIServer behavior using the "Set-PowerCLIConfiguration" cmdlet, for which the help is straightforward.

Additionally, as you will probably notice, the title bar of your PowerShell session indicate that you are connected to X number of servers, along with their names.

A simple example of the usefulness of this new feature: connect to several non-vCenter managed VIServers and act against all items associated with said hosts. We are using a Powershell Credential object in this example so as not to need to enter credentials for each host (which assumes that there is a common account across them all) and to remove the need to specify credentials on the command-line.
Connect to serveral hosts
...
PS C:\> $credRootUser = Get-Credential -Credential root

Windows PowerShell Credential Request
Enter your credentials.
Password for user root: *************


PS C:\> Connect-VIServer -Credential $credRootUser -Server hst0,host1,aHost23,hst45

Name Port User
---- ---- ----
hst0 443 root
host1 443 root
aHost23 443 root
hst45 443 root


PS C:\> Get-VM -server hst0

Name PowerState Num CPUs Memory (MB)
---- ---------- -------- -----------
win7test PoweredOff 1 1024


PS C:\> Get-VM | Format-Table Name, PowerState, NumCPU, MemoryMB, @{Label="HostName"; Expression={$_.Host.Name}}

Name PowerState Num CPUs Memory (MB) HostName
---- ---------- -------- ----------- --------
win7test PoweredOff 1 2048 hst0
dubuntu0 PoweredOn 1 768 host1
dubuntu8 PoweredOff 1 1024 host1
vMA4 PoweredOff 1 512 aHost23
2k8test PoweredOff 1 1024 hst45


PS C:\> Get-VM | Where-Object {$_.PowerState -eq "PoweredOff"} | Start-VM
...
Now connected to each host, one could perform whatever task(s) they desired. In this example, we got the VMs for one host, got the VMs for all hosts to which we were connected, and then started all powered-off VMs. Another example would be to gather VMNIC info as described in the "Find Busted VMNICs" post here at vNugglets.com. Yet another example would be, as Glenn at get-admin.com points out in his "Find vCenter without vCenter" post, finding the VMHost on which the vCenter VM resides in the case that vCenter services (or the VM) are not responding properly (and, so, one cannot connect to vCenter to determine this info).
This feature is most useful for managing hosts that are not managed via a vCenter instance. Once the given hosts are connected to a vCenter, admins can run their commands against said vCenter as per usual.

23 December 2009

Find Busted VMNICs

So, while we mentioned this would be a "low-volume blog", we didn't think we'd get our domain expiration notice before the first vNugglet hatched. Anyway, a problem we've run into in the past are VMNICs that suddenly have no link for whatever reason--switch upgrades, random user error, etc.

The following script will search the connected vCenter Server(s) to find any VMNICs that are actively being used in a standard vSwitch and also have no link (0Mbps).

## Script function: Lists all VMNICs that have no link and that are connected to a vSwitch (sorted by corresponding host).
## Author: vNugglets.com
## Usage: Connect to vCenter, run script interactively.


## Get all hosts and sort by name
Get-VMHost | Sort-Object -Property Name | ForEach-Object {
## (Re)Initialize array of failed VMNICs
$arrFailedVMNICsInUse = @()

## Get current host's Name, NICs, and vSwitches objects
$objCurrentHostNICs = Get-VMHostNetworkAdapter -VMHost $_
$objCurrentHostVSwitches = Get-VirtualSwitch -VMHost $_

## For each failed NIC, if it is attached to a vSwitch, add it to the failed VMNICs array
$objCurrentHostNICs | Where-Object {$_.BitRatePerSec -eq 0} | ForEach-Object {
$objCurrentFailedNIC = $_
$arrValidVMNICs = $objCurrentHostVSwitches | ForEach-Object {$_.Nic}
if ($arrValidVMNICs -match $objCurrentFailedNIC.DeviceName) {
$arrFailedVMNICsInUse += $objCurrentFailedNIC
} ## end if
} ## end inner ForEach-Object

## If there is at least one failed VMNIC, display the hostname it is associated with followed by the list of failed VMNICs
if ($arrFailedVMNICsInUse.Count -gt 0) {
$_.Name + ":"
$arrFailedVMNICsInUse | ForEach-Object {
"`t" + $_.DeviceName
} ## end ForEach-Object
Write-Host ""
} ## end if
} ## end outer ForEach-Object

That's it! Hopefully this is helpful to someone else.


*UPDATE - 19 January 2011: Updated script due to the following properties that are now deprecated.

PS C:\> .\findBustedVMnics.ps1
WARNING: 'PhysicalNic' property is obsolete. Use 'Get-VMHostNetworkAdapter' cmdlet instead.
WARNING: 'VirtualSwitch' property is obsolete. Use 'Get-VirtualSwitch' cmdlet instead.

...

08 February 2009

vNugglets Objectives

Welcome to vNugglets. Right now vNuggs is comprised of two IT masters that needed a place to share some scripts/howto's/whatever. AC started off washing dishes at Chubby's Fish & Steak. Then during and after attending college he worked as a Systems Administrator at a small shop, followed by a Fortune 500 financial company. AC currently works at a consulting company where he specializes in VMware administration/infrastructure. D-Day started his illustrious career by slinging pizza pizzas! at Little Caesar's. Then during college he too worked at a small shop as a Systems Administrator (doing everything). D-Day currently works at the same consulting company as AC, specializing in VMware administration/automation.

This blog will contain useful (hopefully) scripts, howto's, and miscellany. While there are plenty of scripts/howto's out there, vNuggs will focus on providing well-written/documented material, not just "it works, that's good enough" efforts. This includes:
  • providing example usage/output
  • good, readable, commented code
  • trying to stay away from most aliases for the sake of the readers
pertaining to:
  • VMware (generally PowerShell)
  • Sys Admin tasks
  • general automation
In focusing on these items, vNugglets.com will likely be a low-volume blog, not one that will rigorously cover current virtualization/technology news. There are excellent sources for that sort of info (and more) on our blog list.