<div class="gmail_quote">On Sat, Sep 3, 2011 at 1:56 AM, Jeff LaCoursiere <span dir="ltr"><<a href="mailto:jeff@sunfone.com">jeff@sunfone.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Thu, 1 Sep 2011, RSCL Mumbai wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
I tried and failed with VirtualBox too. Timing seemed impossible to maintain, even on beefy hardware (hexacore)<br>
with plenty of RAM (16G), and nothing else going on (single instance). I don't think VirtualBox is up to real-time<br>
stuff.<br>
<br></div><div class="im">
We use LXC now, and it is fantastic.<br>
<br>
j<br>
<br>
<br>
Thx Jeff.<br>
<br>
Kindly share some more details on the kind of hardware you are using, LXC parameters and the kind of load the system can<br>
handle.<br>
<br>
I am sure this will help me and more like myself.<br>
<br>
Thx<br>
Sanjay<br>
<br>
<br></div><div class="im">
My main interest of being on Virtual platform is portability / Backup.<br>
In case of any h/w issues, or crashes, simply copy the VM on to another box and you are up in minutes.<br>
<br>
<br>
Sanjay<br>
<br>
<br>
</div></blockquote>
<br>
Hi Sanjay,<br>
<br>
LXC is more of a quasi-virtual platform - it doesn't give you hardware virtualization, but instead lets you share the kernel of the host between multiple instances. To me this allows for multiple efficiencies and advantages that you don't get with hardware virtualization:<br>
<br>
1) the host's memory is shared between all instances<br>
2) the host's disk is shared between all instances<br>
3) a shell on the host has access to the files in all of the instances<br>
<br>
So an instance that is truly idle is taking up very little resource on the host. Versus a traditional hardware virt, which even when idle has an appreciable chunk of RAM and CPU in use all the time.<br>
<br>
For hosting lots of asterisk instances this is VERY efficient.<br>
<br>
We have it setup such that the host runs an asterisk image that is the "PSTN gateway" and has dahdi loaded for timing and access to interface cards. It accepts calls for subscribed DIDs and routes them to the appropriate instance.<br>
<br>
Each instance has an asterisk process that is dedicated to a customer, which includes their own instance of FreePBX. The dedicated asterisk instance uses a SIP peer connection to the asterisk running on the host which is its outbound access to the PSTN (or other instances). The one gotcha I ran into was configuring the instance to allow access to the dahdi kernel module of the host, which is needed for timing for meetme (we still run 1.4). The conf file needs to contain:<br>
<br>
# dahdi<br>
lxc.cgroup.devices.allow = c 196:0 rwm<br>
lxc.cgroup.devices.allow = c 196:253 rwm<br>
lxc.cgroup.devices.allow = c 196:254 rwm<br>
lxc.cgroup.devices.allow = c 196:255 rwm<br>
<br>
This is still in proof-of-concept mode for us, but we do have a half dozen customers representing about fifty seats running on it in beta. No complaints in over two months, and the load average may as well be zero.<br>
<br>
The machine is a quad core Xeon (X3450 @ 2.66Ghz) with 8G RAM, running Ubuntu 11.04.<br>
<br>
Each instance is a subtree of the host's filesystem, by default (at least in Ubuntu) under /var/lib/lxc. We created a template with a full asterisk and FreePBX installation. To create a new instance we simply untar the template and run a sed script over a set of files to give it an IP address, hostname, and minor edits to various asterisk config files. I haven't done it yet, but I intend to create a mirror of the host machine on another box with rsync, which will serve as the backup. At some point I would like to have the instances running on both mirrors with failover.<br>
<br>
LXC docs basically suck. If you do go down this road, you will have to be prepared to glean as much as possible from notes various people have posted. I settled on Ubuntu 11.04 as a base because a lot of LXC specific scripts have been created to help with management. Even so its kind of flaky shutting down and rebooting the instances. Once they are running as you like it is stable, but I had a lot of weird things happen along the way as I was tweaking.<br>
<br>
OpenVZ is the older and more mature equivalent, and may be a better choice to start, but it is not built into the kernel as LXC is. I don't have an real comparisons to provide operationally, but I can vouch for LXC being stable enough for production use so far. I haven't stress tested it yet to see how many instances we can provide on a single host, but am hoping it to be a function of the number of simultaneous calls rather than the number of instances...<br>
<br>
Would love to hear from anyone else that is using LXC, especially in production.<br>
<br>
Cheers,<br><font color="#888888">
<br>
j</font><br>--<br></blockquote><div><br>@Jeff, @Tarek,<br><br>I finally decided to move away from Virtualization.<br>I have read a lot of posts on various forums which suggests VB is not fully ready for a real time application like Asterisk, and I have been facing issues all the way.<br>
LXC was a bit complicated for me and I was short on time.<br><br>Did a bare metal install and its working good.<br>My Quad Xeon 2.3 GHz CPU hardly hits 10% with 20 concurrent calls<br>I have only 2GB RAM for now and its 50% used.<br>
<br>Created a CloneZilla image last night, plan to install it on another similar hardware later today. <br><br>I am wondering how to resolve ethernet conflict while restoring the image on a new identical hardware (MAC address change causes OS to create 2 new interfaces).<br>
<br>I do not have any PSTNs, pure IP.<br><br>Sanjay <br></div></div>