The usage of VM depends on several factors. What type of deployment do you have? (business, school, etc). How many devices do you have? Will this number grow?
Here's a few knowledge base articles that could help:
http://kb.airwave.com/?sid=50140000000MetG - some guidelines when considering virtualizing AMP
http://kb.airwave.com/?sid=50140000000Mf99 - steps for installing on VMware ESXi
There's active support for VMWare ESX and ESXi installations, Hyper-V is not currently supported, but other customers have gotten it to work (one trick I found is that you have to install 3rd party legacy network drivers).
In the lab, I'm running several instances on a AMP-Pro box, but I never reach higher than 200 devices per instance in most of the test runs I perform. If you're only running a single AMP instance, then it's suggested that you make the system a dedicated server to give AMP as much resources as possible.
Performance-wise, you'll see that the disk i/o usage is very high, that's due to the intensive amounts of read/writes to the database. The server sizing guide on support.arubanetworks.com suggests you scale an additional 20% resources for a server. The extra 20% accounts for some VMHost overhead and shared resource distribution. We've seen a lot of success when the data is off-server on a SAN, but many use the minimum of 15k rpm drives. The largest deployment I've worked with involved several instances of AMP-Pro (1000 devices per VMinstance), and couldn't grow any larger due to disk utilization. I've yet to see any setup on VM that exceeded a 1000 device count.
1. Things to do:
- Definitely make use of the snapshot feature in VMWare
- Make sure you size the VM properly
- Everyonce in a while check for jitter of time/date. VM-tools is supposed to mitigate this, but doesn't always do so successfully.
- Take backups off of the instance to either the VMHost disk space or to another server / repository.
2. Things to not do:
- If on a shared host, do not give AMP a low priority (data will reflect the low priority with gaps in graphs, and you'll noticeably see the slow down)
- Do not try to manage the OS, treat AMP as an appliance.
- After initial setup, do not rely heavily on VMware vSphere client as the interface to connect to the CLI. I personally find the client slower than directly SSHing into the VMinstance.
3. Optimization:
- You may have to trade off the granularity of data by reducing poll cycles if the disk i/o's climb too high. This depends mostly on the type of deployment being monitored and number of devices in the deployment.
- You may also have to reduce the number of thread allocated to the system if your trying to run multiple VMs on the same host, and not enough CPUs to maintain all instance.
Support can give you more feedback as to other customers who've run the same. What we do know is that if you have a high load of single instance users (like an airport or coffee shop hot spot), you may find yourself having a hard time unless you shorten your historical retention periods. Also, if you have a high number of VisualRF floor plans, you'll see a performance hit there as well. But these last two items are true across all AMP deployments in general.