Decide to ask about your recommendations.
Here i ask about few VirtualPBXses inside one kerio operator:
So i suppose that we also can use vmware esxi for example, with few installed kerio operator inside.
I ask because solutions like trixbox or elastix doesn't recommended for use it inside vmware for production by their developers.
So is it stable solution in case of kerio operator and ready for production use?
HI i have this running on fairly basic hardware - a 6 core AMD Phenom 2 with a 60 GB SSD, 8 GB RAM.
I used VMware ESXi as the operator didn't boot so well with the hardware i had
We have a relatively small installation, I have only assigned the server 2 vCPU's and 2 GB of RAM, and a 20 GB VMDK. I also set a 200 Mhz reservation.
When 4-5 phone calls are active it barely registered within the Operate admin/ web page as any CPU load.
It has been 100% stable, using snom phones and auto provisioning. We are using the 820 821 870 and a meeting point.
The only issue we have had is when a staff member botched the configuration, but this was fixed by using the built-in restore.
You wont have any issues with it running on a virtualisation platform, the only possible challenges I can see are around the networking etc for the SIP trunk. This is the same for any voip system.
- Vladimir Toncar (Kerio)
When it comes to running Operator on a virtual server, the short answer is: It depends.
A somewhat longer answer follows:
We think that running Operator on a real hardware is the better idea. But we paid attention to the ability to run on virtual platforms (mainly VMWare) because we are using it a lot ourselves during development and testing. You can run Operator on a virtual server but I recommend that you run it in a prolonged test before you commit to it as your long-term solution. It really depends on what other servers/applications you run on your host machine. Also, you should not expect that a virtual Operator server will support the same number of users/concurrent calls as the real HW with the same nominal CPU power. Virtual servers don't scale that well.
(1) Maintaining real time - The clock in the virtual machine must not slow down. This can be an issue on some virtual platforms but Operator should be resilient against that. We use the Asterisk's zt_dummy kernel module by default, so Asterisk has a reliable timing platform. We also use NTP by default to help maintain the correct time, so leave it on.
(2) Do not overcommit your virtual platform - If your host machine has X GHz of CPU power, the sum of CPU power defined for your virtual machines should not exceed X (or at lest not significantly exceed). Even though you can set priorities for virtual machines (like in ESX), these priorities guarantee an average allocation, not a real-time response. You should not overcommit your host machine memory, as well. If a virtual machine (Operator) needs to run and it's not in the physical memory, it might wait some milliseconds, and up to several hundreds milliseconds, before it gets some CPU cycles. I probably do not need to explain that this is not good for VoIP telephony.
I hope this explanation is of some help.
[Updated on: Mon, 02 May 2011 15:24]
Kerio discussion forums are intended for open communication between forum
members and may contain information and material posted by members which may
be useful in learning about Kerio products. The discussion forums are not
intended to provide technical support for any specific product. Any
information implied or expressed in the discussion forums is that of the
posting member. Kerio is in no way responsible for the information posted in
the forums, or its accuracy. Kerio employees may participate in the
discussions, but their postings do not represent an offical position of the
company on any issues raised or discussed. Kerio reserves the right to
monitor and maintain the forums to promote free and accurate exchange of