This blog was generated from CDN blog
Created by: John McDonough on 02-08-2011 03:05:49 PM
A KVM launch link for a UCS blade or rack mount server is accessible via the UCS Manager interface and the url http://<ucs-ip-
address>/ucsm/kvm.html
KVM access in 1.4 is improved from 1.3, the 1.4 KVM access institutes KVM session ownership. That is when a second KVM session is launced for a
server, the launcher is shown a dialog to request access to the initial session. The owner of the initial session is alerted to the request and
can grant access as read-only, as read-write, or can deny access. Both versions of UCS firmware 1.3 and 1.4 support secure access (https KVM
link), however even in non-secure interaction one time use tokens are generated for KVM access.
To launch a KVM for a server from a script, a few things must be determined, UCS firmware version, the management interface IP address and the
launch url. The launch url is ultimately what provides access to the KVM, it will contain the IP address of the management interface, the one
time use tokens, the dn of the Service Profile, if there is one associated. If the dn of the Service Profile is included the the Service Profile properties tab
is displayed. Controlling the display of the service profile properties tab is something that only a custom script can do.
I'm going to be script agnostic and provide the calls and output, it's up to you to wrap this up in Perl, PowerShell, Java, VB, etc...
Let's start with getting the management interface for the server. The management interface will provide us with the IP address to connect to,
with version 1.4 of UCS firmware the management IP address can now be managed a few different ways, it can come from a pool and stick with the
server, come from a pool and stick with the service profile or be statically assigned to the service profile. Whatever method was used the IP
address of the management interface is maintained in the mgmtIf object, specifically the mgmtIf object for management interface 1.
The mgmtIf object is a granchild object of the computeBlade object and great-great-grandchild of the topSystem object. The object ancestral
liniage is
For a blade -- topSystem --> equipmentChassis --> computeBlade --> mgmtController --> mgmtIf
or
For a rack mount -- topSystem --> computeRackUnit --> mgmtController --> mgmtIf
For chassis 1 blade 1 the dn of mgmtIf 1 would be
sys/chassis-1/blade-1/mgmt/if-1
For rack unit 1 the dn of mgmtIf 1 would be
sys/rack-unit-1/mgmt/if-1
I'll go through this example with computeBlade, since that is what has been in UCS since day 1, however where you see chassis-x/blade-x that can
be replaced with rack-unit-x for rack mount servers.
If the mgmtIf object is a grandchild of computeBlade how do you go about getting the mgmtIf object without doing a query on the computeBlade and
setting inHierarchical="true". If you need a refresher on UCS queries check out this blog it will tell you all you need to know about queries to get this script going.
Assume that I have alread done the <aaaLogin> and have a valid cookie
To get the management interface for a computeBlade you can either go directly to the dn for management interface 1 with a configResolveDn or you
could use configScope set the dn to the computeBlade and the inClass to mgmtIf. Doing it the latter way will require parsing multiple returned mgmtIf objects.
Query
<configResolveDn
cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4"
inHierarchical="false"
dn="sys/chassis-1/blade-1/mgmt/if-1">
</configResolveDn>
Provided the computeBlade exists the response will be the similar to this, hopefully management IP addresses have been assigned.
Response
<configResolveDn dn="sys/chassis-1/blade-1/mgmt/if-1" cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4" response="yes">
<outConfig>
<mgmtIf
access="unspecified"
adminState="enable"
chassisId="1"
discovery="absent"
dn="sys/chassis-1/blade-1/mgmt/if-1"
epDn=""
extBroadcast="0.0.0.0"
extGw="14.3.25.1"
extIp="14.3.25.243"
extMask="255.255.255.0"
fsmDescr=""
fsmPrev="nop"
fsmProgr="100"
fsmRmtInvErrCode="none"
fsmRmtInvErrDescr=""
fsmRmtInvRslt=""
fsmStageDescr=""
fsmStamp="never"
fsmStatus="nop"
fsmTry="0"
id="1"
ifRole="unknown"
ifType="physical"
ip="127.5.1.1"
locale=""
mac="00:26:51:08:9B:04"
mask="0.0.0.0"
name=""
peerChassisId="N/A"
peerDn=""
peerPortId="0"
peerSlotId="0"
portId="1"
slotId="1"
stateQual="unspecified"
subject="blade"
switchId="A"
transport=""
type=""
vnet="1"/>
</outConfig>
</configResolveDn>
Now that we know the IP address, next we'll get the firmware version of UCS Manager, the version we care about is in an object with a class type
of firmwareRunning, however there are many of those objects and the one we really care about is sys/mgmt/fw-system so we'll use a configResolveDn
query.
Query
<configResolveDn cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4" inHierarchical="false" dn="sys/mgmt/fw-system"/>
Response
<configResolveDn dn="sys/mgmt/fw-system" cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4" response="yes">
<outConfig>
<firmwareRunning deployment="system" dn="sys/mgmt/fw-system" packageVersion="" type="system" version="1.4(2b)"/>
</outConfig>
</configResolveDn>
Now that I know the UCS firmware version I can use that to determine which token generation method I'll use. Remember before I said where you see
chassis-x/blade-x you can replace that with rack-unit-x, that ony works in UCS firmware 1.4, there is no support for rack mount servers in UCS Manager prior to 1.4.
Token generation methods changed from 1.3 to 1.4 to allow for support of rack mount servers. Two tokens are needed for when the KVM launch URL is
created.
1.4 Token generation method - aaaGetNComputeAuthTokenByDn
Request
<aaaGetNComputeAuthTokenByDn
cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4"
inCookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4"
inDn="sys/chassis-1/blade-1"
inNumberOf="2"/>
Response
<aaaGetNComputeAuthTokenByDn
cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4"
response="yes"
outUser="__computeToken__"
outTokens="61988320761576037020851,43544867103458002077091">
</aaaGetNComputeAuthTokenByDn>
1.3 Token generation method - aaaGetNComputeAuthToken
Request
<aaaGetNComputeAuthToken
cookie="1312247466/729c6770-6546-4a13-82e6-024d0015cca5"
inCookie="1312247466/729c6770-6546-4a13-82e6-024d0015cca5"
inChassisId="1"
inSlotId="1"
inNumberOf="2"/>
Response
<aaaGetNComputeAuthToken
cookie="1312247466/729c6770-6546-4a13-82e6-024d0015cca5"
response="yes"
outUser="__computeToken__" outTokens="04901822589703997129391,34809355585511073028631">
</aaaGetNComputeAuthToken>
The last item needed is the Service Profile name, if there is a service profile associated to the server. The service profile name can be
retrieved from the computeBlade object, it is the value of the assignedToDn attribute.
Query
<configResolveDn cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4" inHierarchical="false" dn="sys/chassis-1/blade-1"/>
Response
<configResolveDn dn="sys/chassis-1/blade-1" cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4" response="yes">
<outConfig>
<computeBlade
adminPower="policy"
adminState="in-service"
assignedToDn="org-root/ls-esx4-01-node-1"
association="associated"
availability="unavailable"
availableMemory="24576"
chassisId="1"
checkPoint="discovered"
connPath="A,B"
connStatus="A,B"
descr=""
discovery="complete"
dn="sys/chassis-1/blade-1"
fltAggr="0"
fsmDescr=""
fsmFlags=""
fsmPrev="TurnupSuccess"
fsmProgr="100"
fsmRmtInvErrCode="none"
fsmRmtInvErrDescr=""
fsmRmtInvRslt=""
fsmStageDescr=""
fsmStamp="2011-07-22T11:40:05.227"
fsmStatus="nop"
fsmTry="0"
intId="51912"
lc="discovered"
lcTs="1969-12-31T19:00:00.000"
lowVoltageMemory="not-applicable"
managingInst="A"
memorySpeed="not-applicable"
model="N20-B6620-1"
name=""
numOfAdaptors="1"
numOfCores="8"
numOfCoresEnabled="8"
numOfCpus="2"
numOfEthHostIfs="2"
numOfFcHostIfs="2"
numOfThreads="16"
operPower="on"
operQualifier=""
operState="ok"
operability="operable"
originalUuid="e5805ab1-7c91-11de-b2b0-000bab01bfd6"
presence="equipped"
revision="0"
serial="QCI133000RB"
serverId="1/1"
slotId="1"
totalMemory="24576"
usrLbl=""
uuid="25b50101-0001-0000-2000-0025b5010100"
vendor="Cisco Systems Inc"/>
</outConfig>
</configResolveDn>
Now that we have all the components for the KVM URL, lets construct it, the URL will launch the KVM interface, it can be a single tab interface
displaying just the KVM console or a multi-tab interface with the second tab showing either the Server properties or the Service Profile
properties.
The single KVM console tab URL for sys/chassis-1/blade-1
http://14.3.25.20/ucsm/kvm.jnlp?
&kvmIpAddr=14.3.25.243&kvmUser=__computeToken__&kvmPassword=38158712471501120248151¢raleUser=__computeToken__&
centralePassword=70669906150949419168551&chassisId=1&slotId=1&tempunpw=true&
frameTitle=Chassis%201%20-%20Server%201%20KVM%20Console
The items that are being set in the URL
kvmIpAddr
kvmUser
kvmPassword
centraleUser
centralePassword
chassisId
slotId
tempunpw - not sure what this is my guess, temp user name and password flag
frameTitle
The dual tab KVM interface for sys/chassis-1/blade-1
http://14.3.25.20/ucsm/kvm.jnlp?
&kvmIpAddr=14.3.25.243&kvmUser=__computeToken__&kvmPassword=98775305540511458434251¢raleUser=__computeToken__&
centralePassword=16003560674436101632111&kvmDn=org-root/ls-esx4-01-node-1&chassisId=1&slotId=1&tempunpw=true&
frameTitle=Chassis%201%20-%20Server%201%20KVM%20Console
The only additional item in the URL is kvmDn which is set to the dn of the Service Profile associated to the blade.
A rack mount server KVM can be launched by using the same URL construction but replace chassisId & slotId with just the dn of the rack mount server for example to launch a single tab interface for a rack-unit-1 the URL would be
http://14.3.25.20/ucsm/kvm.jnlp?
&kvmIpAddr=14.3.25.243&kvmUser=__computeToken__&kvmPassword=38158712471501120248151¢raleUser=__computeToken__&
centralePassword=70669906150949419168551&dn=sys/rack-unit-1&tempunpw=true&
frameTitle=Rack%20-%20Server%201%20KVM%20Console
For PowerShell you can launch this URL from a script and be browser independent by using the following command
(New-Object -com Shell.Application).Open("http://14.3.25.20/ucsm/kvm.jnlp?
&kvmIpAddr=14.3.25.243&kvmUser=__computeToken__&kvmPassword=98775305540511458434251¢raleUser=__computeToken__&
centralePassword=16003560674436101632111&kvmDn=org-root/ls-esx4-01-node-1&chassisId=1&slotId=1&tempunpw=true&
frameTitle=Chassis%201%20-%20Server%201%20KVM%20Console");
Other languages I'm sure support the launching of a URL, that's up to you.
Hope this helps
John McDonough
Cisco Advanced Services
UCS Compute and Virtualization Practice
Created by: John McDonough on 02-08-2011 03:05:49 PM
A KVM launch link for a UCS blade or rack mount server is accessible via the UCS Manager interface and the url http://<ucs-ip-
address>/ucsm/kvm.html
KVM access in 1.4 is improved from 1.3, the 1.4 KVM access institutes KVM session ownership. That is when a second KVM session is launced for a
server, the launcher is shown a dialog to request access to the initial session. The owner of the initial session is alerted to the request and
can grant access as read-only, as read-write, or can deny access. Both versions of UCS firmware 1.3 and 1.4 support secure access (https KVM
link), however even in non-secure interaction one time use tokens are generated for KVM access.
To launch a KVM for a server from a script, a few things must be determined, UCS firmware version, the management interface IP address and the
launch url. The launch url is ultimately what provides access to the KVM, it will contain the IP address of the management interface, the one
time use tokens, the dn of the Service Profile, if there is one associated. If the dn of the Service Profile is included the the Service Profile properties tab
is displayed. Controlling the display of the service profile properties tab is something that only a custom script can do.
I'm going to be script agnostic and provide the calls and output, it's up to you to wrap this up in Perl, PowerShell, Java, VB, etc...
Let's start with getting the management interface for the server. The management interface will provide us with the IP address to connect to,
with version 1.4 of UCS firmware the management IP address can now be managed a few different ways, it can come from a pool and stick with the
server, come from a pool and stick with the service profile or be statically assigned to the service profile. Whatever method was used the IP
address of the management interface is maintained in the mgmtIf object, specifically the mgmtIf object for management interface 1.
The mgmtIf object is a granchild object of the computeBlade object and great-great-grandchild of the topSystem object. The object ancestral
liniage is
For a blade -- topSystem --> equipmentChassis --> computeBlade --> mgmtController --> mgmtIf
or
For a rack mount -- topSystem --> computeRackUnit --> mgmtController --> mgmtIf
For chassis 1 blade 1 the dn of mgmtIf 1 would be
sys/chassis-1/blade-1/mgmt/if-1
For rack unit 1 the dn of mgmtIf 1 would be
sys/rack-unit-1/mgmt/if-1
I'll go through this example with computeBlade, since that is what has been in UCS since day 1, however where you see chassis-x/blade-x that can
be replaced with rack-unit-x for rack mount servers.
If the mgmtIf object is a grandchild of computeBlade how do you go about getting the mgmtIf object without doing a query on the computeBlade and
setting inHierarchical="true". If you need a refresher on UCS queries check out this blog it will tell you all you need to know about queries to get this script going.
Assume that I have alread done the <aaaLogin> and have a valid cookie
To get the management interface for a computeBlade you can either go directly to the dn for management interface 1 with a configResolveDn or you
could use configScope set the dn to the computeBlade and the inClass to mgmtIf. Doing it the latter way will require parsing multiple returned mgmtIf objects.
Query
<configResolveDn
cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4"
inHierarchical="false"
dn="sys/chassis-1/blade-1/mgmt/if-1">
</configResolveDn>
Provided the computeBlade exists the response will be the similar to this, hopefully management IP addresses have been assigned.
Response
<configResolveDn dn="sys/chassis-1/blade-1/mgmt/if-1" cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4" response="yes">
<outConfig>
<mgmtIf
access="unspecified"
adminState="enable"
chassisId="1"
discovery="absent"
dn="sys/chassis-1/blade-1/mgmt/if-1"
epDn=""
extBroadcast="0.0.0.0"
extGw="14.3.25.1"
extIp="14.3.25.243"
extMask="255.255.255.0"
fsmDescr=""
fsmPrev="nop"
fsmProgr="100"
fsmRmtInvErrCode="none"
fsmRmtInvErrDescr=""
fsmRmtInvRslt=""
fsmStageDescr=""
fsmStamp="never"
fsmStatus="nop"
fsmTry="0"
id="1"
ifRole="unknown"
ifType="physical"
ip="127.5.1.1"
locale=""
mac="00:26:51:08:9B:04"
mask="0.0.0.0"
name=""
peerChassisId="N/A"
peerDn=""
peerPortId="0"
peerSlotId="0"
portId="1"
slotId="1"
stateQual="unspecified"
subject="blade"
switchId="A"
transport=""
type=""
vnet="1"/>
</outConfig>
</configResolveDn>
Now that we know the IP address, next we'll get the firmware version of UCS Manager, the version we care about is in an object with a class type
of firmwareRunning, however there are many of those objects and the one we really care about is sys/mgmt/fw-system so we'll use a configResolveDn
query.
Query
<configResolveDn cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4" inHierarchical="false" dn="sys/mgmt/fw-system"/>
Response
<configResolveDn dn="sys/mgmt/fw-system" cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4" response="yes">
<outConfig>
<firmwareRunning deployment="system" dn="sys/mgmt/fw-system" packageVersion="" type="system" version="1.4(2b)"/>
</outConfig>
</configResolveDn>
Now that I know the UCS firmware version I can use that to determine which token generation method I'll use. Remember before I said where you see
chassis-x/blade-x you can replace that with rack-unit-x, that ony works in UCS firmware 1.4, there is no support for rack mount servers in UCS Manager prior to 1.4.
Token generation methods changed from 1.3 to 1.4 to allow for support of rack mount servers. Two tokens are needed for when the KVM launch URL is
created.
1.4 Token generation method - aaaGetNComputeAuthTokenByDn
Request
<aaaGetNComputeAuthTokenByDn
cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4"
inCookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4"
inDn="sys/chassis-1/blade-1"
inNumberOf="2"/>
Response
<aaaGetNComputeAuthTokenByDn
cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4"
response="yes"
outUser="__computeToken__"
outTokens="61988320761576037020851,43544867103458002077091">
</aaaGetNComputeAuthTokenByDn>
1.3 Token generation method - aaaGetNComputeAuthToken
Request
<aaaGetNComputeAuthToken
cookie="1312247466/729c6770-6546-4a13-82e6-024d0015cca5"
inCookie="1312247466/729c6770-6546-4a13-82e6-024d0015cca5"
inChassisId="1"
inSlotId="1"
inNumberOf="2"/>
Response
<aaaGetNComputeAuthToken
cookie="1312247466/729c6770-6546-4a13-82e6-024d0015cca5"
response="yes"
outUser="__computeToken__" outTokens="04901822589703997129391,34809355585511073028631">
</aaaGetNComputeAuthToken>
The last item needed is the Service Profile name, if there is a service profile associated to the server. The service profile name can be
retrieved from the computeBlade object, it is the value of the assignedToDn attribute.
Query
<configResolveDn cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4" inHierarchical="false" dn="sys/chassis-1/blade-1"/>
Response
<configResolveDn dn="sys/chassis-1/blade-1" cookie="1312246321/1cd0a1a8-b5b0-4cd9-bfdb-d25410af7db4" response="yes">
<outConfig>
<computeBlade
adminPower="policy"
adminState="in-service"
assignedToDn="org-root/ls-esx4-01-node-1"
association="associated"
availability="unavailable"
availableMemory="24576"
chassisId="1"
checkPoint="discovered"
connPath="A,B"
connStatus="A,B"
descr=""
discovery="complete"
dn="sys/chassis-1/blade-1"
fltAggr="0"
fsmDescr=""
fsmFlags=""
fsmPrev="TurnupSuccess"
fsmProgr="100"
fsmRmtInvErrCode="none"
fsmRmtInvErrDescr=""
fsmRmtInvRslt=""
fsmStageDescr=""
fsmStamp="2011-07-22T11:40:05.227"
fsmStatus="nop"
fsmTry="0"
intId="51912"
lc="discovered"
lcTs="1969-12-31T19:00:00.000"
lowVoltageMemory="not-applicable"
managingInst="A"
memorySpeed="not-applicable"
model="N20-B6620-1"
name=""
numOfAdaptors="1"
numOfCores="8"
numOfCoresEnabled="8"
numOfCpus="2"
numOfEthHostIfs="2"
numOfFcHostIfs="2"
numOfThreads="16"
operPower="on"
operQualifier=""
operState="ok"
operability="operable"
originalUuid="e5805ab1-7c91-11de-b2b0-000bab01bfd6"
presence="equipped"
revision="0"
serial="QCI133000RB"
serverId="1/1"
slotId="1"
totalMemory="24576"
usrLbl=""
uuid="25b50101-0001-0000-2000-0025b5010100"
vendor="Cisco Systems Inc"/>
</outConfig>
</configResolveDn>
Now that we have all the components for the KVM URL, lets construct it, the URL will launch the KVM interface, it can be a single tab interface
displaying just the KVM console or a multi-tab interface with the second tab showing either the Server properties or the Service Profile
properties.
The single KVM console tab URL for sys/chassis-1/blade-1
http://14.3.25.20/ucsm/kvm.jnlp?
&kvmIpAddr=14.3.25.243&kvmUser=__computeToken__&kvmPassword=38158712471501120248151¢raleUser=__computeToken__&
centralePassword=70669906150949419168551&chassisId=1&slotId=1&tempunpw=true&
frameTitle=Chassis%201%20-%20Server%201%20KVM%20Console
The items that are being set in the URL
kvmIpAddr
kvmUser
kvmPassword
centraleUser
centralePassword
chassisId
slotId
tempunpw - not sure what this is my guess, temp user name and password flag
frameTitle
The dual tab KVM interface for sys/chassis-1/blade-1
http://14.3.25.20/ucsm/kvm.jnlp?
&kvmIpAddr=14.3.25.243&kvmUser=__computeToken__&kvmPassword=98775305540511458434251¢raleUser=__computeToken__&
centralePassword=16003560674436101632111&kvmDn=org-root/ls-esx4-01-node-1&chassisId=1&slotId=1&tempunpw=true&
frameTitle=Chassis%201%20-%20Server%201%20KVM%20Console
The only additional item in the URL is kvmDn which is set to the dn of the Service Profile associated to the blade.
A rack mount server KVM can be launched by using the same URL construction but replace chassisId & slotId with just the dn of the rack mount server for example to launch a single tab interface for a rack-unit-1 the URL would be
http://14.3.25.20/ucsm/kvm.jnlp?
&kvmIpAddr=14.3.25.243&kvmUser=__computeToken__&kvmPassword=38158712471501120248151¢raleUser=__computeToken__&
centralePassword=70669906150949419168551&dn=sys/rack-unit-1&tempunpw=true&
frameTitle=Rack%20-%20Server%201%20KVM%20Console
For PowerShell you can launch this URL from a script and be browser independent by using the following command
(New-Object -com Shell.Application).Open("http://14.3.25.20/ucsm/kvm.jnlp?
&kvmIpAddr=14.3.25.243&kvmUser=__computeToken__&kvmPassword=98775305540511458434251¢raleUser=__computeToken__&
centralePassword=16003560674436101632111&kvmDn=org-root/ls-esx4-01-node-1&chassisId=1&slotId=1&tempunpw=true&
frameTitle=Chassis%201%20-%20Server%201%20KVM%20Console");
Other languages I'm sure support the launching of a URL, that's up to you.
Hope this helps
John McDonough
Cisco Advanced Services
UCS Compute and Virtualization Practice
