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.

4 comments:

  1. This is great stuff, you should blog more !

    ReplyDelete
  2. Thanks, Virtu-Al. Having more quality posts here is the goal, for certain.

    ReplyDelete
  3. This actually ended up being really helpful for me, thanks! And I agree with Virtu-Al, you should blog more :)

    ReplyDelete
    Replies
    1. Thanks, Techrich, glad that you found it useful! Yes, we should work on dedicating more time to sharing some of the nugglets that are piling up on our end. Eventually...

      Cheers

      Delete