vicidial.org

by **enjay** » Fri Feb 13, 2009 1:33 pm

I have a interesting situation..

At startup of Asterisk/VICIDIAL when users login they get their own conferences

8600051
8600052

etc..

however when any user logs off then logs back in they get 8600194 and every user who logs in theirafter lands in that same conference (creating major overlaps).

Asterisk -1.4.22
Zaptel - 1.4.12.1
VICIDIAL - Latest SVN

any ideas?

by **mflorell** » Fri Feb 13, 2009 2:40 pm

Get off of 1.4.22 first of all, 1.4.21.2 is the latest stable one we've found and we have been able to replicate issues with 1.4.22 and 1.4.23.

How many agents are on this system?

what kind of database storage engine are you using?

How many 8600194 vicidial_conferences records are there in the DB?

Have you looked at the mysql error log in the agc web directory?

by **enjay** » Fri Feb 13, 2009 5:02 pm

Currently on 1.4.21.1

No agents on the system currently 2 agents Im testing with when this happens..

pretty much all tables are MyISAM, some are MEMORY

one entry in vicidial_conferences for 8500194

there is no mysql error log in /var/www/html/agc/*

..

Note this is just one problem I'm experiencing, another is that when I have a closer logged in (assuming Im not reproducing the above error) a fronter sends a call to the closer, the closer receives the call but then has no ability to click the hangup button etc its all greyed out even though there is a LIVE CALL..

This whole infrastructure is running on a VMWARE ESX Infrastructure any known issues with this?

by **mflorell** » Fri Feb 13, 2009 6:06 pm

VMWARE is the only thing I know as a problem with VICIDIAL under any kind of load. As for the problem, no clue what could be causing it. We have several clients on Asterisk 1.4.21.2 so I know that's not it. What version of MySQL?

by **enjay** » Fri Feb 13, 2009 6:12 pm

MySQL - 5.0.45

I run this version elsewhere Im not sure what the issue is either the only abnormality in this environment from my perspective is also VMWARE, though there is absolutely 0 load. I will rebuild these servers.

by **enjay** » Thu Feb 26, 2009 2:09 am

Servers reloaded, all seems to be running smoothly.

VMWARE ESX = no no!

by **Op3r** » Thu Feb 26, 2009 5:33 am

Hahahaha

All this time you were trying to run it on vmware?

by **enjay** » Thu Feb 26, 2009 11:55 am

I said I was.... and its not quite VMWARE in the generic sense it is ESX infrastructure which if it COULD run on (im sure the timing would ALWAYS be a nightmare) would be unbelievable from a redundancy/failover perspective. The extra time spent to rebuild from scratch was worth the investment to validate whether it would work or not

-Art

by **mcargile** » Thu Feb 26, 2009 12:42 pm

You could have asked.

Vicidial requires a functioning zaptel timer in order to work. Ztdummy uses the systems real time clock to generate its timing. There is no real time clock in any virtualization technology out there accept OpenVZ which is not true virtualization. Ztdummy will compile and it will load. It just will not do anything. You can modify the code for Ztdummy to use the Kernel Tick rather than the RTC but then you have horrible timing and it should never be used in production.

I have had at least 6 customers call us up and ask us to fix their Vicidial installation, only to tell them to ditch VMWARE. Once I convince them to do so everything works like a charm.

And just for the record there are other issues with using OpenVZ.

by **asterguy** » Thu Mar 19, 2009 3:22 am

ESX is a good server. I've tried to run asterisk on it and it works fine however, you need to do some tweaks.
add "clock=pit" on the kernel line on your menu.lst and update your ntp server.

by **williamconley** » Thu Mar 19, 2009 3:57 pm

we're not worried about running asterisk on it, but vicidial.

but i'm hearing an interesting concept here: are you saying that ztdummy is the Main or Only serious wall here?

as in ... if we find a way to get timing ... it WOULD work? (or at least suddenly switch from "no way" to "probably"?)

by **mflorell** » Thu Mar 19, 2009 5:15 pm

That's not really the only wall, there are also other issues I have been told about like the perl scripts that are running every minute that can cause issues because they take up a lot of resources and by default would run all at the same time.

OpenVZ was the most successful so far because you could access a real timer because it's not really a virtual machine.

by **williamconley** » Thu Mar 19, 2009 5:42 pm

I ran some tests at one point (for a different project) to break through the VM image and communicate directly with the host system. I wonder if it would be possible to deliberately make a hole available for the timer (likely violating a couple VMWare rules, but life's like that).

If that could be accomplished, I can see where having the clocks striking simultaneously on any/all of the hosted boxes could create a bottleneck issue. I would of course suspect that could be resolved in the same way as moving all my bills from the 1st (coinciding with the mortgage) and spreading them out over the rest of the month did. Set cron to run at different times on the different machines. Not exactly on the :00 second.

But if the first step is a solid timer, then aside from looking for a hardware timer (which doesn't really help "testers" but could resolve the issue for those wanting 4 clients on one box), we need to breach the wall of the VMware. It apparently isn't enough to just have ONE machine running inside the VMware box, as evidence of this still not working is quite prevalent. We need to get an outside the VMWare box timer to show the inside-the-box OS what time it really is. Hm.

by **mcargile** » Fri Mar 20, 2009 3:28 pm

If you are really desperate to spend hours banging your head against a wall you can try coupling VirtualBox with Sangoma's VoiceTime modules. VirtualBox allows you to assign USB devices to VMs and the VoiceTime modules are USB devices. I tried this for kicks at one point and it didnt quite work but I had VirtualBox running on Windows with Linux VMs. It might work with VirtualBox running in Linux with Linux VMs.

But in all seriousness there really is no point in running Vicidial in a VM. You might be able to fit 3 customers on one hell of a beefy system but at which point you might as well get each customer their own server for 80% of the cost of the beefy server. If density is the issue look into some of SuperMicro's cases. They have ten inch deep 1U cases that you can double side a rack with.

by **williamconley** » Fri Mar 20, 2009 9:44 pm

Mostly I'm looking at the ability to have users able to "test vicidial" with at least a couple agents with no hardware involved. pulling a virtual machine would be worthy, if it worked. I have some friends that are heavy into virtualization enough that they'd probably run their own vicidialnow type of project IF it could be done. but the initial "git-er-goin" would have to happen first. they aren't vici-folk.

but they'd LOVE to become vici-folk.

by **mcargile** » Mon Mar 23, 2009 3:10 pm

Check out www.vicibox.com. Its our LiveCD which we use for demo and training purposes.

by **williamconley** » Mon Mar 23, 2009 3:15 pm

Ok, now THAT'S cool.

by **mcargile** » Mon Mar 23, 2009 3:24 pm

Thanks.

It is based off Ubuntu and comes with 2.0.4 installed. I have not had time to replace most of the Ubuntu artwork and the Ubuntu boot menu, but it does function and it will not trash the computer so long as you don't click the install link.

by **williamconley** » Mon Mar 23, 2009 3:33 pm

LOL. I'll keep my finger off the button.

vicidial.org

8600194 Conference Oddities

8600194 Conference Oddities

Who is online