IT Operations Management (ITOM)

Evolve OM Unix to OMi: Simple Command Line Tools admins need to know

Evolve OM Unix to OMi: Simple Command Line Tools admins need to know


Guest post written by Martin Recker, HP Operations Bridge R&D, HP Software



The following is a hypothetical conversation with an admin user of HP Operations Manager for Unix, as imagined by Martin Recker, former OMU developer.


“I’m an OMU admin and if I assume that sooner or later OMi is going to succeed my good old UNIX tool. So how should I start the journey? I’m up to the challenge, but time and money is really low. Can you give me some ways to quickly build on my OMU know-how? Any memory aids are welcome…”


You’re not alone! Previous posts have explained why it makes sense for admins using HP Operations Manager (HPOM) for Windows, UNIX, Solaris or Linux to move to HP Operations Manager i (OMi),

and the complete story is documented in the Operations Bridge Evolution Guide.


But in this article, let’s concentrate on a few OMi basics for OMU veterans. I will simplify things even more and talk only about nodes, node groups, policies and policy group. The vehicle for our short tour will be the corresponding command line utilities dealing with such artifacts.


“Hang on a second, what is an ‘artifact’ anyway? The OMi doc is full of the word.”


You can translate it to “object” or “item”—it’s nothing special, just a different term.


“And did you just use the words ‘node’, ‘node group’, ‘policy’ and ‘policy group’, even though we’re in the OMi world?”


Yes you’re right. I used these words so you would feel more at home. In OMi, a node is a node configuration item, and a node group is now a view, a policy is a policy template, and a policy group is now called an aspect.


“Okay, so in OMU a node is defined by its nodename. Different nodename means different node. How does it work in OMi?”


Well, it’s quite so easy as in OMU, but look at it this way: your nodebank is now the RTSM (runtime service model), while a node CI is identified by its long hostname (primary_dns_name), short hostname (CI name), and its IP addresses. And from OMi 10.01 onwards you get back your opcnode command, now called opr-node. You can add, modify and delete nodes, add or delete its IP addresses, and maybe simpler than with OMU: you can work over node IDs: e.g. when to clean a duplicate node CI:

opr-node –user user –password password –del_node –ci ciId

And there are many ways that opr-node can filter on nodes in the RTSM. You can even setup your own filters in the OMi UI and run them with opr-node:

opr-node –user user –password password –list_nodes –filter_name myLinuxBoxes

“You said a nodegroup is now called ‘view’. I have some doubts about that.”


You’re right. The truth is, a nodegroup is a fix set of nodes, while a view delivers a group of CIs you get when applying the view’s filter query on the RTSM. For an example, look at the command line tool
opr-agt, which should remind you of OMU’s opcragt. So when typing opcragt –status –all,
you now say:

opr-agt –user user –password password –status –all


It is identical to:

opr-agt –user user –password password –status –query_name All_CIs_with_OM_Agents


“Just saw that commands opr-agt as well as opr-node also both have an option –node_group. Why do you then say a node group is like a view, and not a node group is a node group?”

In fact, an OMU node group is also reflected in OMi as a fix set of nodes, a CI collection of nodes. You can use it to control the agents like this:

opr-agt –user user –password password –stop –node_group myGroup


Or list them using:

opr-agt –user user –password password –list_agent_nodenames –node_group myGroup


With OMi, you assign configuration to nodes selected through a view. Assignment via node groups is on the enhancement list and may come with a future release.

Therefore from that angle an OMU node group is more like an OMi view still.


“Okay, I’ve got it. So now we’re at policies. For me, as a longtime OMU admin, it’s a funny transition from OMU 7 templates to OMU 9 policies and now to OMi policy templates.”


The difference between an OMU 9 policy and OMi policy template is easy: a policy template is like a form feed in that you fill in some values, leave others with their default. A policy template has editable fields, called parameters, while an OMU 9 policy has none, and OMU 7 templates don’t even have versioning. Parameters and versioning are the central mechanisms to simplify config maintenance.


“I agree, that’s a big step forward. But how do I get my really valuable policies from OMU to OMi?”


On the OMU side, use command opcpolicy –download –pol_group to download any policy group, or just do a complete download using opccfgdwn. Copy the download directory to OMi and call

ConfigExchange -user user –pw password -uploadOM -input myDownloadDir

The tool will upload everything it understands — policies, policy groups and instrumentation. It’s best you verify whether the policies should be adapted when used with OMi. For that, call

ConfigExchange -user user –pw password -check –pf myDownloadDir –logfile myAdaptationHints


“Sounds good, but what about the policy groups? You said a policy group is an aspect. Are you sure?”


Maybe I’ve simplified it a bit too much. An aspect has versioning, also you can set policy parameters on the aspect level, and an aspect has a CI-type dependency. But similar to OMU policy groups, you can link policies and instrumentation to it, it can be hierarchical, and you can assign and deploy it to nodes.


“So why not automatically convert a policy group into an aspect when uploading from OMU to OMi?”


The policy groups are uploaded, just look in the OMi template group UI. But an auto-conversion sounds like too much magic behind the scenes. It’s unlikely that you’d organize your aspects exactly like your policy groups, not with the new possibilities you get with policy and aspect parameters, similar to adjusting to the new paradigm of working CI-centric instead of node-centric. Unlike with OMU, you now can assign config to CI types like databases, instead of being forced to assign it to the node the database is hosted on.

Anyway, starting to work in OMU style is not a bad idea. Over time, you’ll find out where parameters can simplify matters and thereby reduce the number of required policies. Whether to work CI-centric or node-centric is often a question of taste. The more you model your IT environment in the RTSM, the more a CI-centric approach makes sense.


“I see, but what about task automation – command-line tools to do config assignments? Thinking about OMU’s opcnode —assign_pol_group or opcpolicy –list_pol_assigns?”


We’re not yet there, but working on it. Have a look on the OMi command ConfigWsTool which can do certain assignments, and there will be more to come.


“Ok, so far so good. Now what about the link to the agent. How does one transform assignments into policy deployments?”


First of all, the command line tools ovpolicy and ovdeploy are the same as on OMU. OMi server also has an Operations agent installed, delivering such utilities. Secondly, OMi has a command to deploy the configuration, like OMU’s opcragt –distrib. For example, call:

opr-agt –user user –password password –deploy -force –node_group myGroup


Besides that, there is only one more thing to keep in mind: Config assignment and config deployment are executed immediately one after the other — at least if you don’t change the default behavior to suspend-mode. And in case of failed or suspended deployment jobs, OMi has another command line utility. For instance, you can run suspended jobs within a maintenance window at the weekend using:

opr-jobs –user user –password password –start –suspended –node_group myGroup


That’s all for now. I think we’re done with our little tour.


“Thank you. I think I’ll give OMi a try.”


Learn more about Operations Manager and Operations Manager i here.

You can also download trials of the software to experience them for yourself.

Search for blogs containing tag OMI10F for other topics similar to this one

The OM-to-OpsBridge evolution program including license exchange details is now live. Search on the tag OM2OpsBridge to find blogs discussing this program and evolution to OpsBridge.
Search on OMiContent for other blogs on management packs and connectors.

We are pleased to announce the HP BSM Integration for BMC Impact Manager by Comtrade, version 1.1. The HP BSM Integration for BMC Impact Manager by Comtrade enables you to establish a link between BMC Impact Manager and HP Operations Manager i 10 (OMi).  


The key features of this release are:   


  • Support of Operations Manager i 10 and BSM Connector 10    
  • Self-discovery  

The installation package and the integration guide are available at


We are also pleased to announce the availability of yet more extensions to our fast growing catalogue of management tools, the lightweight OMi Management Pack for Docker has been released on HP-LN:


We are now happy to announce the availability a new connector for HP Helion.
You can find it for download on HPLN at,

Based on Monasca the OpenStack monitoring tool and available independently from Helion, but will be a key part of the Helion offering in fal 2015l. With this HP Helion Monasca connector we are well prepared in advance for integrating HP Helion monitoring with OMi.

  • A demo of the Monasca connector is available in the demo environment already, it is a recorded and clickable demo.
  • It is community supported release






  • operations bridge
About the Author