or timebound ? or don't you have any load on your DB at all ?
I personally don't see many reasons to virtualize your database, apart from the , we plan to start small and scale out, or the we need it now and we don't have the hardware yet , putting your database on a virtual platform where you have to share resources with other virtual machines doesn't really sound like a tempting proposition to me. Small, almost idle databases , maybe. But enterprise production level databases no thnx.
Sheeri Cabral also mentions the above reasons .. and there also .. Enterprise Production use isn't listed.
Databases typically require a good amount of memory , and steady disk access.
So if you are in a production environment with a fairly loaded database, would you want a 4Gb machine with full direct memory access, Or 3.5Gb of virtual memory that can be ballooned to 3 if underused. My pick is at the 4Gb real memory.
The original article at Sun argues the use of Virtual Harddisk to move around workloads between different servers or even Virtualization platforms. But it fails to describe the guaranteed performance penalty of not using raw disks but a filesystem on top of a loopback device. How many layers do you want before actually write to the disks. Good practice in a virtual environment is to dedicate full disks or LVM parts to the virtual machine hence lowering the overhead, but most (default) setups do the opposite.
And don't get me started about the myth of using virtualization for high-availability :)
Now can somebody please remove all the clueless marketing people from planetmysql.org , thnx. (they can be identified with by a blogs.sun.com source and posts that mainly talk about Sun products including only a slight hint to MySQL)
(PS. What's a Market Development Engineer's job description anyhow ? , that's just a different name for Marketing Assistant right ?)
