I suspect you would be better off with some virtualization platform more like OpenVZ (&#39;containers&#39; rather than VM&#39;s) - and probably without any hardware<div>installed (ie SIP to SIP - leave the gateways to a different part of the network).</div>

<div><br></div><div>We&#39;ve run some Asterisk instances in Proxmox (<a href="http://pve.proxmox.com/wiki/Main_Page">http://pve.proxmox.com/wiki/Main_Page</a>) and while it&#39;s early days, it looks pretty</div><div>promising.</div>

<div><br></div><div>Brent<br><br><div class="gmail_quote">On Wed, Mar 3, 2010 at 3:27 PM, Brian May <span dir="ltr">&lt;<a href="mailto:brian@microcomaustralia.com.au">brian@microcomaustralia.com.au</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On 3 March 2010 16:04, Rob Forman &lt;<a href="mailto:rob4manhere@gmail.com">rob4manhere@gmail.com</a>&gt; wrote:<br>


&gt; Is anyone running FreeSWITCH virtualized (xen or vmware) in<br>
&gt; production?  I saw ec2 and xen mentioned a few places.  If so, are<br>
&gt; there tips or tricks for handle timer issues which affect virtual<br>
&gt; machines in general, such as recommended divider or clocksource<br>
&gt; settings?  I&#39;m seeing funny timing issues while testing with audio<br>
&gt; recording and playback that speed up or slow down.<br>
<br>
</div>I tried tdm400+xen DOM0+asterisk years ago, on a single processor<br>
machine but gave up. zttest returned good results, but analogue<br>
quality has intermittently very poor quality and it made telephone<br>
conversations difficult to understand. Especially a problem when<br>
hourly cron jobs would start on all VMs at exactly the same time, but<br>
was a problem at other times too. Plus the fact people who used the<br>
phone more often then me didn&#39;t report the problem, so I thought it<br>
was fine.<br>
<br>
Plus the general fact I didn&#39;t really like the idea of running<br>
Asterisk on DOM0, and running it on DOMU seemed to imply even more<br>
overheard, as DOM0 would have to process the interrupts and pass them<br>
to the DOMU.<br>
<br>
Unfortunately I don&#39;t remember what scheduler I used, maybe sedf?<br>
<br>
I suspect a multi-processor system would be a lot better suited for<br>
the task. Also might be OK if you don&#39;t use zaptel hardware... I seem<br>
to remember these cards generate a huge number of interrupts.<br>
<br>
While this was with Asterisk, I suspect my results were not specific<br>
to Asterisk in anyway.<br>
<font color="#888888">--<br>
Brian May &lt;<a href="mailto:brian@microcomaustralia.com.au">brian@microcomaustralia.com.au</a>&gt;<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>--<br>Brent Paddon<br><br>Director | Over the Wire Pty Ltd <a href="mailto:brent.paddon@overthewire.com.au">brent.paddon@overthewire.com.au</a> | <a href="http://www.overthewire.com.au">www.overthewire.com.au</a><br>

Phone: 07 3847 9292 | Fax: 07 3847 9696 | Mobile: 0400 2400 54<br>
</div>