I would agree with the other posters, IO is still an issue. That is generally true for most databases anyway when they get large enough.

The real reason for not using MySQL on VMware in production is that VMware is not some magical tool for combining CPU/IO resources. You have this big iron box and you are using the VM software to split the resources, rather than what would be more compelling, you have a bunch of little irons which VM software is combining to look like a big iron. The second option allows you to plug-in additional resources as required, the first is just a budget overspend.

It is interesting that the SAN is in some respects a VM/clustering for disks. Network bandwidth and latency is biggest issue for any clustering of resources.
Maybe we will have a CAN (Cpu Area Network), MAN (Memory Area Network) or even a WOMAN (Wireless Optimized Memory Area Network)
in the future.

Have Fun
Paul

IO is definitely an issue with VMWare, so load testing will not be accurate. But it works for day-to-day use for developing and trying out new technologies - Oracle RAC, for instance.

To solve the scsi timeouts we've made sure all databases are on a raw LUN partitions accessed by the VM - and did I mention this storage is all on a SAN? For high CPU use, our ESX servers are on quad-core systems.
We have one entire RAC cluster on one system and one on another. For development and testing, this really works nicely.

One drawback is that because of the RAC clustering protocol that goes on behind the scenes, VMotion actually does interrupt that long enough that it automatically fails the cluster.

Because, quite frankly, IO performance sucks in vmware. We've tried various things - but IO is always slow. There are other nasties that come and bite us too - such as the "scsi timeout" error which hangs the box.

It would be impossible to run more than one VM in the same hardware because of IO contention - therefore, it seems a little pointless.

There's also the not inconsiderable cost of vmware licences for our very large number of production servers (no, they CANNOT be consolidated by vmware, they are numerous for performance reasons)

Thanx! Can you add more about why one wouldn't want MySQL on a virtual machine (in general) or VMWare (specifically) in production? Is it because you don't want a virtual machine in production? Or is it something about MySQL on a virtual machine?

How does one load test and find bottlenecks on a virtual machine that doesn't have the same resource allocation as a production machine would? If the CPU is much slower, your load testing might break on a query that goes slowly because of the slow CPU, and that wouldn't be an issue in production. And if the CPU is much slower and, say, the disk I/O speed slightly slower, how would you know whether the bottleneck is disk write-related (changing many records and then writing that change to a binlog, and perhaps writing to rollback/undo buffers as well) or CPU-related?

Hi Sheeri,

As a training, development/prototyping environment Virtual Machines (VM) are awesome. Testing a new technology or functionality without requiring a new box and new budget.
For people wanting to test various OS and configuration setups, it will help out too.
I can see it being used as a tool to test scalability of the app as well, using something like Amazon EC2 to scale your database to see where the bottlenecks are.

Seriously, I know more about MySQL replication, MySQL Cluster and some of the various toolkits by being able to install and test for myself. This puts the DBA who has done similar in a much better position to provide advice for clients who may been looking at those technologies in a future production environment.

Have Fun
Paul