Show Menu

The Mainte­nance Host (host01)

Host01 is the Mainte­nance Host. It is host to things like the MI and CNFG. Commands for Health and Status of the other blades are run from here. These are all very passive and "­saf­e" commands to run without disrupting or changing any config­ura­tion.

cm_adm -a flavor­_su­mmary Shows what 'flavor' is running on the cards. Flavor is what the VM is doing. Ex: vPIM or vSCM

cm_adm -a tenant­_su­mmary Displays all of the configured tenants on the system, their 'type", what VLAN's they belong to, and what io type is config­ured.

cm_adm -a vm_status --target all Great command that shows, tenant by tenant, the name, state and flavor of the VM. In general the state here must be active.

cm_adm -a health A command that preforms a health diagnostic of the entire system. If it passes you'll get a "­Health Check Passed­" message. This is an all inclusive test. Hosts, VM's and the files needed to checke­d.T­hings to look out for here are SSH, and IPM. (IP Manager) these must be in a pass state.

cm_adm -a vm_hos­t_s­ummary -t host# replace the # with which host you are inquiring about. This gives you a modest amount of info for the host's vm's.

cm_adm -a vm_pow­er_off -v 0<VM NAME> Used to shutdown a VM.

cm_adm -a vm_restore -v <VM NAME> Used to start a VM that was previously created and then stopped by the vm_shu­tdown action, or vm_pow­er_off command.

Backing Out of a Layer

Starting from ssh and going all the way down to the rconsole levels is a tricky business to pull back out of. If you don't exit the layers properly, you can level a session open, in which it will hang if you try to re-enter that same layer.
Here's a general method­ology:

How you get in: ssh
How you get out: exit

How you get in: virsh console
How you get out: ctrl + ]

How you get in: node-c­onsole -s
How you get out: logout then... ctrl + c

How you get in: rconsole
How you get out: exit

In effect you would be climbing back up the chain of layers to where you started.


cm_adm -a generate
- creates a set of ssh keys to interact with the iLO


cm_adm -a generate
- creates a set of ssh keys to interact with the iLO
cm_adm -a install
- applies the generated ssh keys to the hosts.


cm_adm -a generate
- creates a set of ssh keys to interact with the iLO
cm_adm -a install
- applies the generated ssh keys to the hosts.

The Hosts

These commands can be run from any host on the system. Remember there is one host per blade. Each host runs multiple VM's.N­ormally you ssh to the host you want, or ssh from host01 to whatever host you wish.

Not all of these commands are 'passive', so use caution!

virsh list Let's you see all of the VM's running on the particular host that you are on. For example, Host01, has 4 different vm's. Also shows the state it is in. Should be 'running'.

virsh console <VM NAME> This is the virsh command you'll be using the most. Let's you connect into the VM that you have on that particular host. Ex:
virsh console 01-s00­c01h0
You can't virsh into a VM that is not located on the host.

virsh console <VM NAME> --force This can be an extremely helpful command to help force out an existing or hung session (If someone logs out of virsh incorr­ectly!

virsh reboot <VM NAME> Reboots the VM specified.

virsh shutdown <VM NAME> Shutsdown the VM specified.

virsh start <VM NAME> Starts the VM specified

virsh dumpxml <VM NAME> This prints out the XML config­uration about the VM that was written at it's creation. Generally you won't need to change any of this...

virsh destroy <VM NAME> Destroys the instance of the VM you specify

virsh undefine <VM NAME> Undefines the name, and provis­ioning of the domain of the VM you specify. To completely remove a VM you need to run both commands, destroy and undefine.
In Virsh, all VM's are created by config­uring XML files, which are read into virsh.

VM States

When you are in the MI host (00-s0­0c01h0) run the command "­cm_adm -a vm_status --target all" you will see a read out of the state of all the VM's provis­ioned. The states of the VM's on the cards are as follows:

Guest or "­Ten­ant­" Commands

RCC- Reliable Cluster Computing This cluster is a process on a host that
monitors and controls the status of all the VMs on that host. RCC maintains high availa­bility and acts upon errors.
REM - REdundancy Manager The REM combines the actions of the SM running on the config­uration server and LM tasks running on the cards
(Local Manager and System Manager).
These commands can be run from the MI. They manage the VM's throughout the different blades. These must be run as user lss.
rcc_sr­v_state --action display --set ALL Report all RCC and VM states
rem_sr­v_state --action display --set all Report all REM status

The VM's On Each Host

Each Host blade will be running VM's that are running the services we need. (IMS, PIM, SCM, OA etc...) Once on the VM, you can connect to each of the services running.

node-c­onsole -s <card #> This allows you to connect to the specific SCM card. Replace card # with the actual number. The card number must be on the Host to connect to it.

node-c­onsole -p <card #> This allows you to connect to the specific PIM card. Replace card # with the actual number. The card number must be on the Host to connect to it.

view node This lets you get a low level look at what the applic­ation on the VM are doing. Most import­antly it shows the VM's UP/DOWN status, and the applic­ation's UP/DOWN status. It also shows each applic­ation (PIM, or SCM), it's state, and it's function (Activ­e/S­tan­dby). Very useful command.

view ip statistics current This seems to give you a good measur­ement of how to gauge rather the applic­ations you set up are actually talking and receiving traffic.

view ip if This command shows the basics of what most ifconfig commands show. It gives you a list of interfaces that are created for the applic­ation, as well as the state (up/down) the prefix or subnet cidr, the interfaces name (en.scm1, or en.pim2 etc..), and the vlan it's attached to
( mgc, oam, voice, etc..)

view route table Shows the routing table would should have atleast 1 static and one local route. The static route may or may not be the default gateway.
It is at this deep, 'Appli­cation Layer' that we must configure the IP's, networks, and subnets.

The GUI's

Remember what GUI is on what machine.
The CNFG VM hosts the web server that lets us get to the FS-GUI. This is the applic­ation where we set the parameters for the ISC portion, including realms, filters, SIP applic­ations, firewalls, Diameter profiles, charging collection data, PCSCF tables etc.. The FS-GUI applic­ation needs to be downloaded from the CNFG server via ftp. Use filezilla. It is located in /opt/l­ss/­lmt­/pr­ovgui


8950 ID Management GUI

Quick Defini­tions and Things to Remember

IP Realms: Realms allow you to group addresses and subnets that are known to a border gateway. It then lets the gateway know which realm it requires an address from. (untrusted or trusted in our case)

VMM Virtual Machine Manager, basically the hypervisor that supports us using all of the VM's and their sub-ap­pli­cat­ions.

iLO iLO is the embedded server software on the chassis itself, and on each bay, that allows for remote connec­tivity. All iLO addresses are apart of the OAM vlan.

Naming of VM's: <Tenant Number> - <shelf number> <card number> <Host number>

All VM's, Hosts, and nodes in a particular subnet, and VLAN will use the same default gateway.

Remember to put ipv6 addresses in [ ] 's when used with a port number.

If you are on a PC or behind a router that only supports IPv4, and the MI-GUI is provis­ioned IPv6, you won’t be able to access it.

You must download the provis­ioning gui software from the CNFG server. Check the CPC for this address, and ftp the software from that address.
It's location: /opt/L­SS/­LMT­/Pr­ovG­ui/­Sof­tswitch

Files Needed: is for the chassis provis­ioning. Created from the original Guest Field Worksheet.
.xls Guest Worksheet is for the system and VM provis­ioning.
"7510 script­" 7510 IP Provis­ioning
CPC/NDP: Core files that are used to create and populate the above files.
.xlsprov This file is needed to prevent manually inputting the hundreds of parameters into the FS-GUI/COM

Keep Your Bearings

To keep track of where you are in the system, you can reference this to see what the prompts correspond to. The prompts below are examples, the numbers will be different, but learn to recognize the general syntax.

When you are on the Host Level:
[root@­wgw­03-­host01 ~]#

When you are on the VM Level:
[root@­vmm­05-10 ~]#

When you are on the 'Sub-S­ervice' Level:

When are you in any of these levels, make sure you exit the level properly, or the 'session' will still be open, and cause you problems when you try to return!


No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          The 5060 IP Call Server (ICS) Cheat Sheet

          More Cheat Sheets by Steve Fowlkes

          The 5060 IP Call Server (ICS) Cheat Sheet