v15.5 instability on hyper-V

[microsystems]

We have seen two of our 3cx 15.5 installs that were running debian under windows server hyper-v start acting goofy this month. We start seeing de registrations of system extensions, then physical extensions start de registering / re registering. Then the web server intermittently stops responding.

Dashboard shows normal low cpu / memory utilization, and as part of the diagnostic process we added memory and cores to the VM. This seemed to worsen the situation.

Customers were screaming so we replaced one with a physical box built off the same debian / 3cx iso, no problems since replacing. The second one started acting the same way today and we wound up backing up and reinstalling on a windows server hyper-v instance. No issues since then.

Has anyone else seen any issues with debian / 3cx 15.5 running on hyper-v? one server was a HP, the other a Lenovo and the HP was running server 2012, the Lenovo X series 3650 was running a brand new server 2016 instance.

We are getting wary of doing any more hyper-v / debian installs. This issue seems to show up weeks after the initial install. Very strange.

JC

 

[cobaltit]

Did you follow this guide?

https://www.3cx.com/docs/installing-microsoft-hyper-v/

 

[eddv123]

You could have an issue with time no being accurate on your installation that might be causing extensions to unregister since you are using Debian and HyperV.

Try installing an NTP client on your Debian installation and see if the issue persists.
https://wiki.debian.org/NTP

 

[DSXVOICE]

Eddv123's advice is probably your best bet. Your symptoms sound like a clock issue.

 

[cobaltit]

Yep, thus the question if the Hyper-V document was referenced:

Debian does not support the installation of integrated services. Therefore the installation and configuration of the NTP Client needs to be performed after creating the VM instance, by running these commands:

apt-get update

apt-get install ntp

 

[microsystems]

Yep, thus the question if the Hyper-V document was referenced:

thanks, we did follow the hyper-v docs, but will take a look at the ntp issue. I cant spool up the non working instances anymore due to serial number conflicts with the production systems, but will try to restore to a test enviornment with a free license.

However, I dont know why the system extensions were going in and out of registration. you would think whatever timebase the pbx was using would be good in refernce to the server clock. Since we have seen this twice, we will take a good look at every facet of the implementation docs against our installs.

Thanks to all that responded!

 

[cobaltit]

thanks, we did follow the hyper-v docs, but will take a look at the ntp issue. I cant spool up the non working instances anymore due to serial number conflicts with the production systems, but will try to restore to a test enviornment with a free license.

Sure you can. Just make a new virtual network with no internet access and change the NIC over to that or just leave it not connected. You'll have to console in but you can at least check the NTP status.

 

[Nick W]

This is certainly a time issue and causes exactly this.

Also ensure that the Time sync is disabled on your Guest VM settings when using NTP within the VM.