I dont think thats going to every happen. They will lose all their money right there.
PS: i hope you meant to say if Cisco TAC will officially support Callmanager on VMWare?
Virtualizing callmanager doesn't threaten Cisco's profit model nearly as much as a full embrace of SIP like they just did in CCM 5.0. If they aren't scared of that, then they aren't scared of server virtualization. Moreover, I was told by a VMware account manager and SE at a seminar recently that Cisco helped VMware write the "virtual switch" that is in the ESX product.
It's just handwriting on the wall at this point. Kinda like the rumor "the next big CCM version will run on a *nix platform" was a couple of years ago. Well...
I was talking to a Cisco partner about it and he was saying how it wouldn't work because of the hardware detection stuff. I am wondering how the VMware p2v tool would work on it. Hopefully I will get a chance to play with it soon.
Thanks for all of the responses, I had also been told about the virtual switch Cisco has helped developed in VMWare ESX.
I have also been told there is a way to have CCM running on VMWare with a few "slight" adjustments
It is definately POSSIBLE to run any version of CCM on VMWare (I run them on VMWare Server, Workstation or whatever I have handy - not ESX, but I don't see why it wouldn't work).
The issue is that it isn't SUPPORTED.
Imagine you call TAC to tell them that you have a delay reaching dial-tone, or can't get a phone registered, or whatever...
Q: They want to know what your hardware is? - A: VMWare.
Q: VMWare on what? A: A big cluster. Don't know exactly what hardware, doesn't matter as it's virtual.
Q: What else runs on the VMWare cluster? A: loads of stuff...
I guess the point is that if it's on VmWare, Cisco can't control what hardware spec you run the product on so performance issues become more likely... Compatibility issues may arise because you are introducing not just 'supported hardware' it will run on, but 'virtual hardware' which is software and therefore prone to bugs and so on...
With the supported hardware list, with real hardware, and with a customised, controlled OS, then we have something like a controlled environment the program can run on that reduces problems and simplifies troubleshooting.
So you can run on VMWare - google for the steps...
But don't do it in production... I don't expect to see Cisco change their mind about that anytime soon either!
With regard to SIP the idea is that we all need phones that Cisco don't make now and again (maybe one that reads out calling numbers for visually impaired folks, or that works underwater or something I guess) or that are just cheap so it doesn't matter if someone steals it from a warehouse... Cisco don't make niche market (or cheap) phones, so now you can still use CallManager for all your business telephony but still take advantage of cheap/odd phones - and Cisco get to take some license money off you.
So in another way it might work in Cisco's favor.
Hope this helps...
Thanks for the response I can see why currently Cisco don't support CCM on VMWare and fully understand the reasons why.
The reason for my orginal question was because Cisco have already developed a virtual switch with VMWare they obviously realise that there is a shift to virtualisation and was wondering if anyone had heard if they had it on there "road map" to look at this for call manager in the future.
If you're going to "virtualize" your LAB environment, it's one thing. Virtualizing your production environment does not give you much benefits. New CallManagers require 2Gb memory, 80 Gb HDDs (with RAID for redundancy), 2 CPUs, etc. So, to put, for example, 3 CallManagers "virtually", you should have damn good machine, or cluster of three average servers. So, you're placing three CCMs on three servers? Where is virtualization? Furthermore, if you're going to put Unity in the same virtual environment, you need even better "VM platform". So, I don't see a point to place a production CallManagers on VMWare. Another thing, if you're playing with it in the Lab. But when you're working in the Lab, you don't need real support from TAC. So, it does not matter, if Cisco oficially supports CallManagers on VMWare. :-)
What about this:
Devote a VMware virtualized hardware cluster to your CCM cluster. TAC could support that if they wanted to.
You abstract the CCM cluster infrastructure from the hardware. Thus, if you have your VMware based CCM cluster running on a bladecenter or something and you want to replace a drive, cpu, or whatever, no Callmanager nodes go down but only a physical resource. Today if I need to replace a drive on a subscriber, I lose that subscriber while I perform hardware repairs and phones must reregister with another sub. Yes performance could be impaired during the repair depending on your set up but no CCM cluster fault tolerance features would even be engaged.
Also, what about scaling? Could you just add processing power and storage to the harware layer to increase call handling etc, without adding more publishers which
would only be virtualized entities? Is not the current scaling strategy of CCM derived from the one to one relationship between software nodes and hardware nodes, such that if you need more capacity in your cluster you must add both? It is even stated in CQS training material that the primary requirement for adding more phones to CCM is more HD space. It seems to me that it would be very beneficial to abstract the hardware nodes from the software nodes in a CCM environment. Mixing with other app servers would not be neccessary to reap most of the rewards.
It sounds good IN THEORY. Practically, if one server fails in your cluster, it will affect WHOLE Callmanager cluster. Unless you have a lot of resources "reserved". While "reregistering" is not that bad as you describe.
From the price perspective, Cisco has some profit from reselling HP and IBM servers, but mostly it's just a convinience for TAC. Now they have two vendors, and 3-4 servers from each vendor. So, they have to have parts for 4-7 models.
Now, just imagine, that Cisco supports CallManagers on VMWare cluster. OK, VMWare has couple versions of the software. But one client will run it on DELL, anoter on ASUS, third on IBM, etc. If something goes wrong with youre voice environment, who and how will troubleshoot this zoo?