Plantronics + Polycom. Now together as Poly Logo

On-prem DMA in MS Hyper V cluster.


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
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

<======== Signature / Disclaimer ========>
Please be aware:For questions about the type of support to expect please check here

Please also ensure you always check the VoIP , Video Endpoint , Skype for Business , PSTN or RPM FAQ's

Please remember, if you see a post that helped you , and it answers your question, please mark it as an "Accept as Solution".

The title Polycom Employee & Community Manager is an automatic setting within the community and any forum reply or post is based upon my personal experience and does not reflect the opinion or view of my employer.
Poly employee participation within this community is not mandatory and any post or FAQ article provided by myself is done either during my working hours or outside working hours, in my private time, and maybe answered on weekends, bank holidays or personal holidays.
Message 2 of 3

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).

Message 3 of 3