« Back to Microsoft Discussions

computeBlade#SetBladePower() method seems to work wrongly

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
I've just tried the following script to power-on and shutdown a blade with reference to "CISCO UCS Power Shell Library User Guide".

  $b = Get-Blade | where {$_.dn -match "sys/chassis-1/blade-3"}
  $b.SetBladePower("on")

However, this method call raises an exception and the message is as follows:

  "Set-BladePower failed:configured object (org-root/ls-13/power) not found"

There is no "org-root/ls-13" service profile in my UCS environment.
I think the associated service profile is wrongly hard-coded in definition of a SetBladePower method.

B.T.W., I've also tried the following script by using lsServer object instead of computeBlade object.
It worked!

  $p = Get-ServiceProfile | where {$_.pnDn -match "sys/chassis-1/blade-1"}
  $p.SetServerPower("on")

Thanks,

Hi! Good catch. I'll take a look and see if there's a bug in the method. In the mean time, you can accomplish this using the pipeline:

1get-blade | where {$_.dn -match "sys/chassis-1/blade-1"} | set-bladepower -status cycleimmediate


Take a look at the get-help for set-bladepower to see the valid values for status....

Thanks!
Josh

Sorry - another quick followup :-) I tried to reproduce your error on my system, and the only issue I saw was the invalid power state (as I mentioned, 'on' isn't a valid value). What version of the CiscoUCSM.dll are you using? Try downloading the newest Toolkit and give it another try.

Thanks!
Josh

Hi! Good catch. I'll take a look and see if there's a bug in the method. In the mean time, you can accomplish this using the pipeline:

1get-blade | where {$_.dn -match "sys/chassis-1/blade-1"} | set-bladepower -status cycleimmediate


Take a look at the get-help for set-bladepower to see the valid values for status....

Thanks!
Josh



Hi Josh,
 
I'm able to reproduce the issue, but I also see a disconnect between what is accepted as an argument to the object method SetBladePower for an object returned from Get-Blade and what is a valis value for the status attribute of an lsPower object
 
The SetBladePower method is defined as System.Collections.Generic.List[CiscoUCSM.Out.lsPower] SetBladePower(Cisco.Common.Enumerations.PowerStatus powerStatus)
 
If I look at the enumerations in the object model docs for the lsPower "status" attribute which is defined as type "lsPowerState" I see these values

 
down 0
up 1
cycle-immediate 2
cycle-wait 3
hard-reset-immediate 4
hard-reset-wait 5
soft-shut-down 6
soft-shut-down-only 7
cmos-reset-immediate 12
bmc-reset-immediate 13
bmc-reset-wait 14
diagnostic-interrupt 15
kvm-reset 16

DEFAULT up(1)
 
Yet if I enter the value "down" like this $p.SetBladePower("down") I receive  this error
 
Cannot convert argument "0", with value: "down", for "SetBladePower" to type "Cisco.Common.Enumerations.PowerStatus": "
Cannot convert value "down" to type "Cisco.Common.Enumerations.PowerStatus" due to invalid enumeration values. Specify
one of the following enumeration values and try again. The possible enumeration values are "None, On, Off"."
At line:1 char:17
+ $p.SetBladePower <<<< ("down")
    + CategoryInfo          : NotSpecified: ( : ) [], MethodException
    + FullyQualifiedErrorId : MethodArgumentConversionInvalidCastArgument
 
Where the enumerations are defined as "None, On, Off" 
 
I understand that I am making the connection from "Cisco.Common.Enumerations.PowerStatus powerStatus" to "lsPowerState" but I think that is a fair assumption and I would have expected those values to be there.
 
The other item I'm seeing is that Set-BladePower only supports the values "on, off" as shown in the error I received below when trying to use cycleimmediate. Perhaps there is a newer version of the beta, but I'm not seeing the possible -Status values listed in the get-help for Set-BladePower. Here I would also like to see an adhereance to the actual "status" attribute value, so instead of cycleimmediate I would expect "cycle-immediate" or "2" to be valid options.
 
 
PS C:\Users\John McDonough\Documents\UCSPS-Beta> Set-BladePower -Chassis 3 -Blade 4 -Status cycleimmediate -XML
Set-BladePower : Cannot validate argument on parameter 'Status'. The argument "cycleimmediate" does not belong to the s
et "on,off" specified by the ValidateSet attribute. Supply an argument that is in the set and then try the command agai
n.
At line:1 char:43
+ Set-BladePower -Chassis 3 -Blade 4 -Status <<<<  cycleimmediate -XML
    + CategoryInfo          : InvalidData: ( : ) [Set-BladePower], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationError,Cisco.UCSCmdlet.Commands.Operations.SetBladePower
 
 
Regards,
John

Joshua, John
 
Thank you for your comments.
 
I'm sorry, I was using older library.
I confirmed that the following pipeline style worked properly with latest library.

  // power cycle
  Get-Blade | where {$_.dn -match "sys/chassis-1/blade-1"} | Set-BladePower -status cycleimmediate -Force

  // boot
  Get-ServiceProfile | where {$_.pnDn -match "sys/chassis-1/blade-1"} | Set-ServerPower -status up -Force
  // shutdown
  Get-ServiceProfile | where {$_.pnDn -match "sys/chassis-1/blade-1"} | Set-ServerPower -status down -Force

I also confirmed that the following method invocation style worked although I'm not sure it is supported.
I think the programmer who usually uses some sort of object-oriented language (java, python, ruby, etc.)¿might prefer this style.

  $b = Get-Blade | where {$_.dn -match "sys/chassis-1/blade-1"}
  $b.SetBladePower("cycleimmediate")    // power cycle

  $p = Get-ServiceProfile | where {$_.pnDn -match "sys/chassis-1/blade-1"}
  $p.SetServerPower("up")      // boot
  $p.SetServerPower("down")    // shutdown


Thanks,

Josh,

I was using the older library as well, so things are working as expected.

My only comment would be the power states not matching "exactly" with the power states in the object model. Not a big issue, is the deviation a result of PowerShell parameter naming convention?

Regards,
John

Good catch, John - I hadn't noticed the difference. That said, I'll check with the devs and see why they made that change. Shouldn't have been a PowerShell issue though. Its not a problem having param values with '-' in them.