Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

EMGR Physical-to-Virtual Convert failing 1

Status
Not open for further replies.

MitelInMyBlood

Technical User
Apr 14, 2005
1,990
US
The server guys tried to convert my E-mgr (5) to a virtual environment this morning and it flamed out badly. We don't see anything in the event viewer that points to a problem. Tomcat logs are showing some errors. ANyone see anything here that gives a clue? Thanks

[06 Nov 2008 09:47:22:312] ~ALERTAUDIT~INFO~: Update: from Major to Major at Thu Nov 06 09:47:22 CST 2008. Alert: 10.221.8.64 : At least one node on this subnet is in alarm state.
[06 Nov 2008 09:47:26:796] ~MISC~INFO~: TELNET successfully unbound from registry
[06 Nov 2008 09:47:26:812] ~MISC~INFO~: SSH successfully unbound from registry
[06 Nov 2008 09:47:26:812] ~TOPO~INFO~: CORBA: CORBADiscProcess ready for Shut Down
[06 Nov 2008 09:47:26:812] ~TOPO~INFO~: TL1: TL1GatewayProcess ready for Shut Down
[06 Nov 2008 09:47:26:812] ~TOPO~INFO~: TL1: TL1DiscProcess ready for Shut Down
[06 Nov 2008 09:47:26:812] ~MISC~INFO~: UserConfigAPI successfully unbound from registry
[06 Nov 2008 09:47:26:812] ~MISC~INFO~: UserStorageAPI successfully unbound from registry
[06 Nov 2008 09:47:26:812] ~MISC~INFO~: ShutDown called for CLIFactoryBinder
[06 Nov 2008 09:47:26:812] ~MISC~INFO~: AdventnetCLIFactory successfully unbound from registry
[06 Nov 2008 09:47:26:812] ~MISC~INFO~: ConfigurationAPI successfully unbound from registry
[06 Nov 2008 09:47:26:828] ~CONFIG~INFO~: No pending devices present for saving
[06 Nov 2008 09:47:26:828] ~MISC~ERROR~: Exception caught in ShutDown of RunProcessInterface com.adventnet.nms.startnms.NmsMainFE at:
java.lang.NullPointerException
at com.adventnet.nms.startnms.NmsMainFE.shutDown(NmsMainFE.java:741)
at com.adventnet.nms.admin.ShutDownServer.shutDownRunProcessModule(ShutDownServer.java:231)
at com.adventnet.nms.admin.ShutDownServer.shutDownNMSServer(ShutDownServer.java:181)
at com.adventnet.nms.admin.ShutDownServer.shutDownNMSServer(ShutDownServer.java:53)
at com.adventnet.nms.admin.ShutDownAPIImpl.shutDownNMSServer(ShutDownAPIImpl.java:96)
at com.mitel.entmgr.servercommon.license.ProcessMitelLicense.shutDownWebNMSServer(ProcessMitelLicense.java:190)
at com.mitel.entmgr.servercommon.license.ProcessMitelLicense.callMain(ProcessMitelLicense.java:133)
at com.adventnet.nms.util.RunProcessSmall.runCommand(RunProcessSmall.java:97)
at com.adventnet.nms.util.RunCmd.run(RunCmd.java:100)
[06 Nov 2008 09:47:26:828] ~MISC~INFO~: NmsPolicyAPI successfully unbound from registry
[06 Nov 2008 09:47:26:828] ~MISC~INFO~: EventAPI successfully unbound from registry
[06 Nov 2008 09:47:26:828] ~MISC~INFO~: AlertAPI successfully unbound from registry
[06 Nov 2008 09:47:26:828] ~PROVISION~INFO~: Provisioning Module started as a separate Enterprise Manager process
[06 Nov 2008 09:47:26:937] ~EVENT~INFO~: Trap Receiving Thread has been successfully Shut Down
[06 Nov 2008 09:47:26:937] ~ALERT~ERROR~: Exception in unexporting the remote object alertFilterAPI: java.rmi.NoSuchObjectException: object not exported
[06 Nov 2008 09:47:26:937] ~EVENT~INFO~: Event Manager has been gracefully Shut Down
[06 Nov 2008 09:47:26:937] ~MISC~INFO~: PollAPI successfully unbound from registry
[06 Nov 2008 09:47:26:937] ~MISC~INFO~: MapAPI successfully unbound from registry
[06 Nov 2008 09:47:26:937] ~MISC~INFO~: NmsAuthenticationAPI successfully unbound from registry
[06 Nov 2008 09:47:26:953] ~MISC~INFO~: RMIAccessAPI successfully unbound from registry
[06 Nov 2008 09:47:26:953] ~MISC~INFO~: NmsAuthAdminAPI successfully unbound from registry
[06 Nov 2008 09:47:26:953] ~MISC~INFO~: NmsAuthEngineAPI successfully unbound from registry
[06 Nov 2008 09:47:26:953] ~MISC~INFO~: NmsAuditAPI successfully unbound from registry
[06 Nov 2008 09:47:26:953] ~MISC~INFO~: TftpAPI successfully unbound from registry
[06 Nov 2008 09:47:26:968] ~MSF~ERROR~: In ManagementServer Cleanup
[06 Nov 2008 09:47:29:093] ~MISC~INFO~: TopoAPI successfully unbound from registry
[06 Nov 2008 09:47:29:093] ~TOPO~ERROR~: Exception in unbinding TopoAPI : java.lang.NullPointerException
[06 Nov 2008 09:47:29:093] ~MISC~INFO~: Removed work directory under Tomcat.
[06 Nov 2008 09:47:29:093] ~MISC~ERROR~: Runcommand instance is null. Can not stop process : Thread[Thread-50,5,main]
 
You have got licencing issue. Licenses keys built against MAC address of your network adaptor. So put the same MAC for your virtual NIC as you had on real server
 
Thanks!

Unfortunately the server team's reply says:

We can’t use the MAC from the physical box on the VM. It’s out of the acceptable range for the VM. Unless we can get a new license key or point to a license server that is somewhere else this won’t work.
 
In VMWare there is an option to set MAC address for your virtual network adaptor. And you cannot use the same physical server wthin the same LAN. Don't mix MAC and IP address. IP address can be different
 
No, we understand the diff. The issue is the VM will not allow us to use the mac address from the old NIC, saying it's out of the acceptable range.

The whole idea was that since we're getting pressure from our internal computer security folks about the SP2 conflict, we figured we'd move to VM Ware and freeze the physical machine & shut it off, then apply SP2 on the VM. That way if we later had a problem/conflict with SP2 we would move back to the physical machine.
 
I see. VMWare worked for me. Free migration tool + free player. Can you tell what's the MAC address of the physical box, I will try to assign it to my VMWare player
 
Open up your VMWare config file. If the active ethernet adaptor is ethernet0, then add/replace following lines:

ethernet0.addressType = "generated"
ethernet0.generatedAddress = "00:12:79:D5:CC:01"
ethernet0.generatedAddressOffset = "0"

Try to start VM
 
I gave that to the server Gods - - have not heard anymore.
I appreciate all your help.

In the event we end up doing a clean install, I see it's easy enough to do a database restore from OPS, but I don't see an obvious way to do a restore to a clean install of E-Mgr. There's a policy to perform a backup of Emgr, which we ran, but the restore procedure isn't obvious. I forget, will it ask for a restore source drive during a clean (from scratch) install?
 
I was using scripts at this location
C:\Program Files\Mitel\Enterprise Manager\bin\backup
 
Server team is adamant - their version of ESX will not allow a MAC address outside the accepted range.

So we tried to do a clean install, which also flamed out. The EMGR install went ok and the restoredb bat file runs ok, but nothing happens (the database is not restored)

They are also insisting on an install on drive D:\Apps directory

For now we've blown it off, will try again next week. Coming back up now on the Physical machine.

 
It appeares to me that in this case VMWare will not work, so don't fix whatever is not broken :)
 
I'm inclined to agree. It's working fine, managing 30-some nodes.

We've agreed to make one final attempt next week using a clean build of 2K3 (SP1) on the C drive of another fresh VM-ware machine. The thinkinig here is they're trying to shove too many variables at us all at once. Since we apparently aren't able to use P2V to clone it, I don't see many other options.

Film at 11..

 
BTW what I found, if you configure 2 or more virtual CPUs in VM running EMGR it's very slow. One CPU is much better. Don't have any good explanation.
 
UPDATE:

Did our 3rd reinstall attempt today and it's running! Absolutely, positively had to reinstall to drive C, could not restore the database otherwise. We're up on VMWare with Emgr5/Ops8.

Emgr policies did not restore.....

 
All MITEL stuff is not very flexible. It has to be installed by the book only. So, RTFM
 
Got a problem now w/SX2K sites unable to do their nightly backups. All the 3300 sites work fine. Got a hunch it's a permissions thing, but haven't spotted anything obvious. In watching the terminal screen on a 2K while an auto data save is running it gets all the way to where it attempts to upload the "session" info, ie sxtov then immediately flames out. Logs don't yield a clue.
 
Never mind... >sheepish grin<
Forgot to establish user mnms
duhhh....
 
So was this issue down to the fact that the MAC address of the NIC had problems with licensing?

Is this licensing with the AMC or VMware?

If the problem was with the AMC then the Hardware ID could have been reset.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top