Production Oracle DB 11g on a virtual server. Bad idea?

Question

We will soon switch our IT Manager, he is also not been very professional, so we are not believing on everything he says anymore.
We just got a new Dell R720 server that will host our Oracle DB.
The server hasn't even been turned on yet but we know that the load on the server will be very low for a long time.
One of our problems is that we need to run a VERY important application. Since it is not very resource consuming compared to it's importance we chose to run it on a not so new Xeon 5110 1.60 GHz - 4GB RAM server. He said it's not a good idea and that we should buy a new server. (money is very low)
The software vendor suggested to virtualize our R720 server, host a vm running our database, and along with it other smaller machines like the one I described above.
I suggested the use of Oracle VM, Oracle Linux for the database host and transforming the physical servers servers in VM with P2V.
Our IT Manager didn't like that, he said that it's not recommended to run a database on a virtual machine. But our software vendor said that many of their clients run their solution this way.
What are our options? Is it really that bad to virtualize?

Answer 1

>
In our case, implementing a VM system is cheaper than new hardware. Not just by the fact that this is Brazil and taxes on hardware are very high...
>
When you say implementing 'a VM system' you are starting to raise a red flag. Have you worked with VM systems before? Have you worked with the setup you say you recommended?
>
I suggested the use of Oracle VM, Oracle Linux for the database host and transforming the physical servers servers in VM with P2V.
>
There are typically a MINIMUM of three components for that configuration: VM Manager, VM Servers (of which you say your DB will be one) and a VM repository. You can merge the Manager and Repository on the same machine but that isn't best practice. The repository would generally be on a reasonably fast storage device that is well protected by a high-level RAID.
On top of that you would typically have some sort-of online failover perhaps even live migration.
So one NUT of the issue are the questions: 1) if your DB is on a VM server by itself then why virtualize it at all, and 2) if there are other apps or VM servers on the same box then if the box goes you lose them ALL.
Implied in that is that you also run the risk that problems with one of your non-critical VMs or apps could take the box itself down and your critical app with it.
>
Our DB will be acquired, setup and managed by a company indicated by our software vendor. It will be their responsibility to keep the server running, backups, growth management, optimization... One version of their contract is that they will set up the hole VM environment for us, that's what we want to sign.
>
Have you talked to any of their current clients about their experience with this company?
>
Apart from the management issues, how much does the virtualization degrades the database performance?
>
But one of the 'management' issues that your 3rd-party company can't deal with is hardware that is physically located on your site. Above you said this
>
Right now there is only a couple of guys to deal with hardware problems, everything related to software is done by a company contracted to manage that. Everything is done over the phone and remote access, they are even form a different state. We will soon stop working with them and have an actual IT staff.
>
Will that hardware be on your site? Will your IT people be responsible for hardware issues? Are you (or your 3rd party company) knowledgable about the importance of multiple servers in a VM system needing to be as compatible as possible in terms of CPU make and model, memory and even the cpus hardware virtualization support?
If your DB VM goes down do you plan to perform live migrations to another VM server? Or do you plan to just stay unavailable until the original VM server can be brought back up.
The performance issues will depend on the type and volume of activity and the amount of data being moved in and out of the VM environment. For the use case you cited I would not expect that to be an issue for you.