falconergyrperegrine
asked on
VMWARE ESX Server and ShoreTel Voicemail
have recently installed a ShoreTel phone system and setup a standalone Windows 2003 server virtual machine to run the voicemail/application server software that comes with the phone system.
My current configuration is as follows:
- ESX 2.5 (VMotion, Dell/EMC CX300, Dell PE-2850)
- Windows 2003 Server (not a member of a domain)
- Gigabit NIC to Gigibit switch
I have a 2-part question:
1) Has anyone attempted to use or is currently using a ShoreTel VOIP system with the ShoreWare voice server installed on a Windows virtual machine running on ESX?
2) Can anyone think of a reason why ESX might be responsible for auto-attendant voice-call packet loss?
The ShoreTel system uses a combination of "Enhanced SIP" and RTP to send media to the ShoreTel switches and then MGCP between the switches and the phones. In my scenario, ShoreWare is running on a VM, so it is sending the media via SIP/RTP from the ShoreWare/Windows 2003 server VM through the virtual switch in ESX, out the physical NIC, through the ethernet switch to the ShoreTel phone switch, then back through a PoE Ethernet switch and off to the phone.
Our integration/solutions provider claims that VMWare is responsible for causing infrequent packet loss in auto-attendant messages to the IP-phone. After we set everything up and were preparing to move into production, ShoreTel told us that ShoreWare in a virtual machine environment isn't supported, although they admitted to never testing it themselves and couldn't say why it wasn't supported.
We went ahead and rolled it out anyway because the problem was very infrequent, but we still occasionally experience it.
We have been advised to install a standalone hardware server for the ShoreWare software rather than using a VM running on ESX. Personally I don't think the issue is VMWare, and I'm not excited to lose all the benefits of redundant hardware/software that I have through ESX and our SAN.
We currently have pretty much solved the packet loss since sinking our system time with the VMware Server.
We still occasionally have a problem with the auto attendant failing. About once a week when our auto attendant status changes it goes dead. You pickup and hit voicemail and get nothing and when people call in they get put into a contact your voicemail administrator message.
Does anyone have any comments or suggestions about this?
My current configuration is as follows:
- ESX 2.5 (VMotion, Dell/EMC CX300, Dell PE-2850)
- Windows 2003 Server (not a member of a domain)
- Gigabit NIC to Gigibit switch
I have a 2-part question:
1) Has anyone attempted to use or is currently using a ShoreTel VOIP system with the ShoreWare voice server installed on a Windows virtual machine running on ESX?
2) Can anyone think of a reason why ESX might be responsible for auto-attendant voice-call packet loss?
The ShoreTel system uses a combination of "Enhanced SIP" and RTP to send media to the ShoreTel switches and then MGCP between the switches and the phones. In my scenario, ShoreWare is running on a VM, so it is sending the media via SIP/RTP from the ShoreWare/Windows 2003 server VM through the virtual switch in ESX, out the physical NIC, through the ethernet switch to the ShoreTel phone switch, then back through a PoE Ethernet switch and off to the phone.
Our integration/solutions provider claims that VMWare is responsible for causing infrequent packet loss in auto-attendant messages to the IP-phone. After we set everything up and were preparing to move into production, ShoreTel told us that ShoreWare in a virtual machine environment isn't supported, although they admitted to never testing it themselves and couldn't say why it wasn't supported.
We went ahead and rolled it out anyway because the problem was very infrequent, but we still occasionally experience it.
We have been advised to install a standalone hardware server for the ShoreWare software rather than using a VM running on ESX. Personally I don't think the issue is VMWare, and I'm not excited to lose all the benefits of redundant hardware/software that I have through ESX and our SAN.
We currently have pretty much solved the packet loss since sinking our system time with the VMware Server.
We still occasionally have a problem with the auto attendant failing. About once a week when our auto attendant status changes it goes dead. You pickup and hit voicemail and get nothing and when people call in they get put into a contact your voicemail administrator message.
Does anyone have any comments or suggestions about this?
1) I've never used that hardware, or software.
2) I can concieve of many reasons why VMWare could cause packet loss. Bad drivers, naughty applications, etc.. are just the beginning. Alas, I've got no good (specific) advice here.
Keep in mind that voice traffic and processing is stupidly miniscule, when compared to today's hardware.. unless you're dumping like, about, 100 concurrent voice mail sessions at your hardware, I doubt you've got a hardware limitation.
8kbps multiplied by 100 concurrent sessions is still just under 1Mbps, unless my multiplication brain cell is off.
I hate to say it -- but I'd start perfmon'ng on your machine, to see if you can figure out what piece of hardware is getting maxed out. Throw RAM at it first, since RAM is cheap.
There's a big assumption there -- that your packet loss is due to some bottleneck, either from a hardware constraint or some (VMWare?) software constraint.
Look at the basics. CPU, RAM, Disk I/O. (disk lights on more than 30% realtime, disk is suspect..)
Hardware is usually cheaply fixable. Software -- especially from a closed system vendor -- is usually expensive to diagnose and then fix.. if diagnosing it is possible.
SANs can be ugly to diagnose, too. Really ugly. Pile up those Perfmon indicators -- queue length, %time, etc.. Does the SAN actually talk CIFS, NFS, or what? Look at that. NFS can be locky, fer sure.
VMWare tuning is an entire art unto itself. Finding, then hiring, a serious VMWare geek could be beneficial to you. When I purchased a $100k IBM x440 server (8 CPUs) -- IBM gave us a serious VMWare geek for free, for a couple days. IBM Global Services has those geeks -- but ya got to pay for them.
Overall, I'm kinda with Joel_Sisko.
Phones are #1 on the "keep it up and reliable" list of systems. If you have to migrate the VM system to a $5000 piece of hardware that has some half-decent redundancy, it might be worth it. Those cost-reliability decisions are yours to make, yeah?
You might spend $5000 just diagnosing the VMWare installation. Keep a real budget in mind while you approach this one..
Best of luck,
-- Scott.
2) I can concieve of many reasons why VMWare could cause packet loss. Bad drivers, naughty applications, etc.. are just the beginning. Alas, I've got no good (specific) advice here.
Keep in mind that voice traffic and processing is stupidly miniscule, when compared to today's hardware.. unless you're dumping like, about, 100 concurrent voice mail sessions at your hardware, I doubt you've got a hardware limitation.
8kbps multiplied by 100 concurrent sessions is still just under 1Mbps, unless my multiplication brain cell is off.
I hate to say it -- but I'd start perfmon'ng on your machine, to see if you can figure out what piece of hardware is getting maxed out. Throw RAM at it first, since RAM is cheap.
There's a big assumption there -- that your packet loss is due to some bottleneck, either from a hardware constraint or some (VMWare?) software constraint.
Look at the basics. CPU, RAM, Disk I/O. (disk lights on more than 30% realtime, disk is suspect..)
Hardware is usually cheaply fixable. Software -- especially from a closed system vendor -- is usually expensive to diagnose and then fix.. if diagnosing it is possible.
SANs can be ugly to diagnose, too. Really ugly. Pile up those Perfmon indicators -- queue length, %time, etc.. Does the SAN actually talk CIFS, NFS, or what? Look at that. NFS can be locky, fer sure.
VMWare tuning is an entire art unto itself. Finding, then hiring, a serious VMWare geek could be beneficial to you. When I purchased a $100k IBM x440 server (8 CPUs) -- IBM gave us a serious VMWare geek for free, for a couple days. IBM Global Services has those geeks -- but ya got to pay for them.
Overall, I'm kinda with Joel_Sisko.
Phones are #1 on the "keep it up and reliable" list of systems. If you have to migrate the VM system to a $5000 piece of hardware that has some half-decent redundancy, it might be worth it. Those cost-reliability decisions are yours to make, yeah?
You might spend $5000 just diagnosing the VMWare installation. Keep a real budget in mind while you approach this one..
Best of luck,
-- Scott.
ASKER
I figured this one out myself. It was ShoreTels softswitch software. They released a patch and it took care of the problem. Had nothing to do with VMWare. VMWare was just an excuse not to support our system. We told them that but to no avail. Asked why they would not support it and they indicated that they did not know.
Refund falcons points.
Joel_Sisko
Joel_Sisko
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I'm about to migrate my Shoreware win 2003 vmail server to ESX. I've been advised by several Sortel customers that they do the same thing.
The server is just a db server really with the dedicated switch hardware doing the D/A conversion as long as the server can serve the files in a timely manner, the system won't know the difference.
The server is just a db server really with the dedicated switch hardware doing the D/A conversion as long as the server can serve the files in a timely manner, the system won't know the difference.
Suggestions: Any way you can adjust the VMware that anytime data that needs to be processed for ShoreWare takes priority over all other applications? My gut feeling is saying lack of processing power at the time the voice system needs it the most.
Joel_Sisko