Plantronics + Polycom. Now together as Poly Logo

On-prem DMA in MS Hyper V cluster.

SOLVED
Highlighted
Advisor

On-prem DMA in MS Hyper V cluster.

DMA 6.3 (then 6.4). Twice in 2 years we have lost our on-prem DMA. It's sitting in a complex VM enviroment, but enterprise level with 99.99% UT, etc.

 

The CentOS/Polycom VMs are running in 'their' enviroment with specs as determined by Polycom. We actually only have two hardware bits, the RMX and MediaSuite. Everything else is VM in our enviroment. RPAD, WSP, MEA, RPRM, the various Skype/Lync components, etc. These all seem to run with no issues. Just the DMA has issues.

 

It starts with some endpoints not registering. Nothing on the DMA looks askew. This time, I would have hoped I would have been smarter (to not repeat last summer's fiasco) but I troubleshoot the endpoint issues to no avail, backed up the DMA configs and rebooted - hasn't been up since.

 

Last year, Polycom engineers checked at the console level, determined that the core components of the DMA were corrupted (engine something or other).

 

This year, we brought back older images of the DMA, ours is pretty static (config) so we went back some months to see if we could get a working one. We could get them spun up, but no access via the HTTP interface. Looking at it today, it actually appears that our original DMA is starting up - but that there is nothing on the eth0 side. Sees no link. We tried going with a legacy NIC. Card on the host is a 10GB Intel card and not the problematic Broadcom NIC referenced by Polycom. Even then, we made changes to the host enviroment, as if the Broadcom card was used - just to see.

 

At this point I have a DMA 9x version up and running (not config'd) but running with an IP and available via HTTP for config. One of the original 6.4 instances (config'd but that didnt come backup after the reboot) - that seems to be running on the console side, but nothing on the network side, you can't set the IP. Another 6.4, clean, behaving the same way that the old (corrupt?) 6.4 is - nothing on the network side. You can't see the network address, the VM thinks there is nothing on the eth0.

 

I have a ticket in. Hopefully we'll get somewhere tomorrow, but I know I'll have to crawl through the tree. MS HyperV situations seem to be an outlier, its mostly VMWare (?).

 

I'll post what happens here, but does anyone else out there run DMA on prem in a Hyper V enviroment?

 

 

Message 1 of 3
1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Advisor

Re: On-prem DMA in MS Hyper V cluster.

Here's the Polycom ticket 1-9875324766, but that probably just consists of us going through the process and rebuilding the DMA. I spun up a 6.4 version, copied our backup configs back to the VM and set it up. We had some issues with licensing (perpetual licensing, handed out from our RPRM) that I figured out. I ended up upgrading to DMA 9 and it all seems to be working now.

 

Its not clear what the issue was/is, but I think that last year's DMA crash was a different problem. That VM at the console level would start and then crash, etc. This year, the DM seems to have issues picking up/seening the NIC from the VM host. We didn't look too closely at the original VM (to my dismay) instead just built up a new one.

 

What I ended up doing is going over Microsoft's Linux best practices as well as CentOS specifics. The Polycom docs were thin, the MS and 3rd-party info had more details.

 

Long story short is that CentOS does not deal well with anything 'dynamic' or redundant in an MS VM enviroment (might be different in VMware, not sure). In particular if you are hosting in a highly dynamic cluster like we have you essentially have to dumb down anything related to the Polycom/CentOS VMs. Primarily this is on the network side, no dynamic MAC addressing, any of the NIC hardware acceleration and Advanced Features on the on Host need to be off/disabled.

 

Not sure if this will help our problem of having DMA issues going forward, but my plan is to be more diligent about taking Snapshots (as well as our regular backup process).

View solution in original post

Message 3 of 3
2 REPLIES 2
Highlighted
Polycom Employee & Community Manager

Re: On-prem DMA in MS Hyper V cluster.

Hello @scotteredu,

welcome back to the Polycom Community.

What is the ticket number so I can cross reference ?


Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.

Best Regards

Steffen Baier

Polycom Global Services

----------------

Notice: This community forum is not an official Poly support resource, thus responses from Poly employees, partners, and customers alike are best-effort in attempts to share learned knowledge. If you need immediate and/or official assistance please open a service ticket through your proper support channels.
Please also ensure you always check the VoIP , Video Endpoint , Skype for Business , PSTN or RPM FAQ's
Message 2 of 3
Highlighted
Advisor

Re: On-prem DMA in MS Hyper V cluster.

Here's the Polycom ticket 1-9875324766, but that probably just consists of us going through the process and rebuilding the DMA. I spun up a 6.4 version, copied our backup configs back to the VM and set it up. We had some issues with licensing (perpetual licensing, handed out from our RPRM) that I figured out. I ended up upgrading to DMA 9 and it all seems to be working now.

 

Its not clear what the issue was/is, but I think that last year's DMA crash was a different problem. That VM at the console level would start and then crash, etc. This year, the DM seems to have issues picking up/seening the NIC from the VM host. We didn't look too closely at the original VM (to my dismay) instead just built up a new one.

 

What I ended up doing is going over Microsoft's Linux best practices as well as CentOS specifics. The Polycom docs were thin, the MS and 3rd-party info had more details.

 

Long story short is that CentOS does not deal well with anything 'dynamic' or redundant in an MS VM enviroment (might be different in VMware, not sure). In particular if you are hosting in a highly dynamic cluster like we have you essentially have to dumb down anything related to the Polycom/CentOS VMs. Primarily this is on the network side, no dynamic MAC addressing, any of the NIC hardware acceleration and Advanced Features on the on Host need to be off/disabled.

 

Not sure if this will help our problem of having DMA issues going forward, but my plan is to be more diligent about taking Snapshots (as well as our regular backup process).

View solution in original post

Message 3 of 3