OnCommand Storage Management Software Discussions

Upgrade OM in paralell?

Hi guys,

We are about to upgrade from OM 3.7 to 3.8. At the same time its going on a new and more robust server. My question is simple:

- Can I run two instances at the same time? I want to install 3.8 on the new server, "restore" a backup to it and run the new version

  in paralell with the older instance so that I sort of get to test the new setup. Will this work? Cant see why not myself, it would create

  more traffic but thats about it?



PS: I should have asked this too: our current OM is a windows version, on new version is Linux, will upgrading even work?

Message was edited by: eric.barlier


Re: Upgrade OM in paralell?

Hi Eric --

Yes, that will work.  You will need to be careful if you run scripts, configuration management, Protection Manager or Provisioning Manager (basically anything that will perform active management on the storage systems).  Those could interfere with each other.

You are correct this will generate additional load on the storage systems, so keep an eye on that to decide whether it's acceptable.

I'm not sure how the licensing will work out.  NetApp pays a royalty to our component vendors for every installed DFM instance.  I don't know if we have an exception for transitions like this.

-- Pete

Re: Upgrade OM in paralell?

It definitely does work.  It will create a lot more traffic to the system, particularly if you have PerfAdvisor enabled from both systems.

You might want to consider disabling perfadvisor on the new system until the upgrade is fully complete.  Then when your upgrade is done, and the monitoring part of DFM is fully up and running do the following.

move the perfdata directory on your new server to a _tmp

dfm options set perfadvisorenabled=off on your old system

copy the perfdata directory from your old server to your new

rename the perfdata directory on your old server to _old

set options set perfadvisorenabled=on on your new system

That way your perf data history will be continuous (except for copy time) and you won't have any dual performance monitoring of your systems

We have used this method in the past for several types of issues.

Re: Upgrade OM in paralell?

Hi Eric,

I've had firsthand experience with what you're proposing (which probably doesn't surprise you).

I've found issues with ONTAP that if you monitor a Filer with more than one OM server the second OM server needs to use a different license key. It caused a system panic so it was not a trivial problem.

I'll see if I can dig out the info on the incident and determine whether its fixed in a later version of ONTAP than when I first encountered the issue.


Re: Upgrade OM in paralell?

Hi Richard --

I'd be interested in hearing the release number too.  In development and testing, we routinely have storage systems monitored by 3, 5, 10 or more DFM stations.  I haven't heard of one panicing recently due to license issues.

We generally don't run the storage systems with heavy read/write loads, which is why we get away with it but don't recommend it to customers.

-- Pete

Re: Upgrade OM in paralell?

Hi Richard,

Very interesting indeed, I wonder if the crash would have been due to separate serials? If I could run the same SN on both instances it would be seen

as one instance (?) and it would not crash..

Anywys, I ll look into if I can run with same serial and take it from there.

Thanks and good to hear from you again!


Re: Upgrade OM in paralell?

Thanks a bunch for this info. I ll sure get good use of it.



Re: Upgrade OM in paralell?


The problem was the same SN / license key in both instances.

And as luck would have it I can't find the case info or bug number.

I'll keep digging.


Re: Upgrade OM in paralell?

Thanks for the update. I still need to install OM on a linux box, so Im not there yet. I might hold fire though..


Re: Upgrade OM in paralell?

Hi Pete,

Found it. Bug 187970 because we had systems running at the time.

It's an SSH bug rather than an OM bug but somehow out of the situation we also developed a best practice of having unique license keys per OM instance (not sure how but then details are sketchy as this was a while ago). Because OM uses SSH the likelihood of these kind of SSH bugs on the Filer are exaggerated when more OM instances are added to the environment.

At the time we also had concerns with the last sentence in point 2.5 on the following document:


The wording was open to interpretation especially when differentiating between monitoring and management functions. From a provisioning and protection manager perspective I think you've already mentioned its best practice to only manage via one instance.