I should add we have two installation of Sipx on ESXi with "good" success.
Here is what we have found. Here are some rules we have found that work most of the time. 1. Use the latest version of ESX...ie 3.5.x 2. Never try to run anything else on the server, I know, seems to be counter to virtualization 3. Use at least a quad core 4. Use AMD opterons, for some reason they seem to work better for sip....I've done some research and it seems like the AMD are faster at context switching...so maybe thats why. 5. Set the VM's CPU, Disk and RAM shares to "high". 6. Only set the VM to a single CPU We have found this works fairly well considering only VM and auto attends actually hit the sipx server. I'm sure this will not work well with the 4.0 release and it's sipxbridge. But for 3.10 with an ingate this works well. Also, most of our clients are opting for Exchnage UM, so that removes the voicemail from the equation anyways. The reason why we go through this trouble is the ease of DR and "safety". We typically take a "snapshot" of the system in the final config and put it on a DVD. If the server ever blows up, we can have it up and running much faster than installing Centos and then restoring the config. The customer can also make snapshots and revert back if they break somthing. The sipx snapshots are nice, but typically things get modified on the linux server itself that is not captured by the "backup". So, we use Virtualization not for consildation but for all the other perks. Good luck.....but like the others have said, virtualization is gonna be much more tempermental than a physcial server...and will require a larger server to perform at the same level. -M >>> "Tony Graziano" <tgrazi...@myitdepartment.net> 01/05/09 7:45 PM >>> Thanks for following up with him Matt. I think even if you dedicate resources, there's still always a possible issue. It's fine for lab use, but not really for production use I think. Unless you have a really good way to always guarantee all resources without latency in a virtual environment, it's not a good idea in production. Latency + sip = misery. This has been discussed in detail many times on the list, and your best answer is to back it up through sipxconfig and restore to a standalone system. >>> "Matt White" <mwh...@thesummit-grp.com> 01/05/09 7:19 PM >>>How many >>> physical cores are in the ESXi server? It's a common mistake for people to assign 2 vSMP to a host. Generally speaking with ESX, you will get lower performance when using multiple cpu's inside a VM. Thats because there is a performance hit to virtualizing two cpu's. The only time this works out is if the software running in the VM is heaviliy multi-threaded. And if there's not at least 4 CPU's int he ESXi server than it's really a problem becuase the virtual machine with fight with the Service console for cpu time. -M >>> Jhony Perez <jpe...@zbzoom.net> 01/05/09 6:26 PM >>> Hello everyone, I have SipX 3.10.2 with CentOS 5 running on a VMWare ESXi server, I've assign 1GB of RAM and selected 2 CPU during the install, the system seems to run just fine but we started having intermittent issues with voicemail quality, at first it was only on the playback of the message but now it seems to be on the message itself, as we can hear it during the playback from forwarding it to email. I've dedicated resources to the SipX, (1GHz and 1GB RAM) now I'm going to monitor the server closely but if this continues to happen I'm gonna have to move it to a dedicated server. By the way, we only have 5 users on the system which it is live. Has anyone installed SipX on VMWare and if so, how does it run?? is there any tweak I can do to get it working better?? Your help is greatly appreciated. Jhony _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users -- This email was Anti Virus checked by the Summit Technology Consulting Groups Astaro Security Gateway. http://www.astaro.com </mwh...@thesummit-grp.com></tgrazi...@myitdepartment.net>
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
