Automating the world one-liner at a time…
This post is a part of the nine-part “What’s New in Windows Server & System Center 2012 R2” series that is featured on Brad Anderson’s In the Cloud blog. Today’s blog post covers Out-Of-Band hardware management using new PCSVDevice cmdlets and how it applies to the larger topic of “Transform the Datacenter.” To read that post and see the other technologies discussed, read today’s post: “What’s New in 2012 R2: IaaS Innovations.”
Windows Server is built from Cloud up to make it best Cloud OS. We believe that the issues running Clouds and the large datacenters running cloud workloads are classic OS issues. Our vision of datacenter management is built around concept of “Datacenter Abstraction Layer (DAL)” – which enables datacenter plug-n-play experience using industry standards. This vision is outlined here A critical aspect of building and scaling cloud infrastructure is Out-of-band management of server hardware through Baseboard management controllers (BMC). This is not a new concept; Out-of-band management of server hardware through BMC has been in existence for about 15 years now. In fact, last year we published “Out of band hardware management” PowerShell module at TechNet Script Center to enable management of server hardware using DMTF WS-Man standard (CIM Cmdlets). SCVMM 2012 also has support for out of band management. In WS 2012 R2, we take this a step forward to make this functionality available in box through an easy to use task abstraction so that users can include these functions in their scripting solutions.
As we planned Windows Server 2012 R2, we talked to datacenter operations teams and asked where they spend their manual effort in datacenter management. Almost everyone agreed that it goes into configuring networks and provisioning server hardware. In this blog post we will cover server hardware management. Network configuration will be covered in a separate blog.
We started with three simple objectives for WS 2012 R2 release:
We found that most of the server hardware in datacenters was capable of remote management through industry standards like IPMI/RMCP+ and CIM/WS-MAN. However, to our surprise, datacenters were relying on a set of fixed functions provided by vendor proprietary tools instead of building custom automation on standards that work across vendors. Reason was simple: the standards we mentioned are great but are seen as complex by the folks we talked to. There was a need to provide simple ‘task-oriented-abstraction’ for managing the server hardware. It was also clear that we need to support both IPMI/RMCP and CIM/WS-Man and provide a common abstraction that hides the perceived underlying complexities.
We identified tasks that are performed most often in managing compute nodes in datacenters.
We went into the workshop and came back with a PowerShell module and WMI a provider which achieves the goals outlined above. Building cmdlets on top on WMI gives great flexibility in building datacenter automation. We will talk about PowerShell cmdlets in this blog post.
PS C:\> Get-Command -Module PcsvDevice
CommandType Name ModuleName
----------- ---- ----------
Function Get-PcsvDevice PcsvDevice
Function Restart-PcsvDevice PcsvDevice
Function Set-PcsvDeviceBootConfiguration PcsvDevice
Function Start-PcsvDevice PcsvDevice
Function Stop-PcsvDevice PcsvDevice
Let's talk for a minute about the name PCSV and why we chose it. PCSV stands for “Physical Computer System View”. It is a new DMTF profile in the final approval process <link>. Goal of this new profile it to hardware management easier and simpler. To be precise – instead of getting lost in sea of profiles and classes that come with existing DMTF initiatives like SMASH/DASH, new PCSV profile gives a simple view to the client saving roundtrips and complex client side coding. We love the simplification that PCSV provides and decided to base our new cmdlets on it.
We choose to implement these cmdlets as a WMI provider which acts as a PCSV proxy for remote machines. Those remote machines can implement PCSV, SMASH, or IPMI – our provider makes them all appear as though they implement PCSV. This provides customers a simple uniform abstraction to manage.
When learning about any new cmdlet, Get-Command is your friend. Let's use it to see how the Get-PcsvDevice cmdlet looks like:
PS C:\> Get-Command -Syntax Get-PcsvDevice
Get-PcsvDevice [-TargetComputerName] <string> [-Credential] <pscredential> [-ManagementProtocol] <ManagementProtocol> [[-Port] <uint16>] [-Authentication <Authentication>] [-UseSSL] [-SkipCACheck] [-SkipCNCheck] [-SkipRevocationCheck] [-TimeoutSec <uint32>] [-CimSession <CimSession>] [-ThrottleLimit <int>] [-AsJob] [<CommonParameters>]
Get-Commandt tells us that we need to know the following:
If your BMC is using standard ports (623 for IPMI and WSMAN HTTP, 664 for WSMAN HTTPS) you don’t need to specify it; otherwise you also need to specify the port.
PS C:\> $cred = Get-Credential root
PS C:\> $ip = "10.10.1.10"
PS C:\> Get-PcsvDevice -TargetComputerName $ip -ManagementProtocol IPMI -Credential $cred
TargetComputerName Manufacturer Model SerialNumber EnabledState
------------------ ------------ ----- ------------ ------------
10.10.1.10 DELL PowerEdge R720 CN7123456700EH Disabled
Similarly if we were using WSMAN protocol, the experience will look similar:
PS C:\> $cred = Get-Credential admin
PS C:\> $ip = "10.10.1.20"
PS C:\> Get-PcsvDevice -TargetComputerName $ip -ManagementProtocol WSMan -Credential $cred
TargetComputerName Manufacturer Model SerialNumber EnabledState
------------------ ----------- ----- ------------ ------------
10.10.1.20 Hewlett-Packard HP Compaq 6005 Pro SFF MXL2081VWT Enabled
The cool thing here is that the cmdlet figures out the profiles supported by the device (whether it is supporting PCSV, SMASH or DASH).
Let's talk about other operations – namely start/stop/restart and setting one time boot configuration.
$a = Get-PcsvDevice -TargetComputerName $ip -ManagementProtocol IPMI -Credential $cred
# Switch ON the machine
$a | Start-PcsvDevice
# Lets switch the machine OFF
# Note that the cmdlet prompts by default - because switching OFF
# a machine can potentially result in data loss
$a | Stop-PcsvDevice
# Common automation scenario - set the machine to boot from network and restart the machine.
# Assumption : You have your WDS deployment server setup to serve image (not covered
# in this script)
# Let’s see how to do it using PCSV cmdlets in a pipeline
# Step 1 - set the machine to boot from network , but just for the next boot
# Step2 - Reboot the machine
$bmc = Get-PcsvDevice -TargetComputerName $ip -ManagementProtocol IPMI -Credential $cred
$bmc | Set-PcsvDeviceBootConfiguration -OneTimeBootSource "CIM:Network:1" -PassThru | Restart-PcsvDevice
To make sure these cmdlets actually work with BMC implementations from major vendors – we are working on interop testing with our partners. We also plan to participate in industry plugfests to ensure interoperability.
We see the cmdlets in Server 2012 R2 as the first step in enabling out-of-band server management from Windows. There is long way to go and we happy that we are starting with a solid foundation. We would love to hear from you what other aspects of out-of-band management we should consider. Our goal is to make server hardware management so easy that everyone can do it.
Osama Sajid, representing
Standards Based Management team in Windows Server
To see all of the posts in this series, check out the What’s New in Windows Server & System Center 2012 R2 archive.
I have a 2012R2 VM Core build and if I try Get-Help Get-PcsvDevice. It returns Get-Help cannot find Get-PcsvDevice HelpNotFoundException. Get-PcsvDevice returns a CommandNotFoundException ? Not had any other trouble with PowerShell what am I missing Thanks.
What about using mac address to set IP? You rack server, write down mac address, and do everything else remotely via PowerShell.