There is can and then there is should. A corvette can go 150 mph, but should you on public highways? You can harm yourself unnecessarily.
Databases are guest operating systems. By design when they start they grab blocks of a resource and manage it directly for performance reasons. As soon as you make the core operating system of the database server a guest in virtualized hosting environment then you are placing an arbitration layer with the hypervisor between the block allocated element of disk and RAM and the database server. It will slow down. The more inefficient your queries, the more it will slow. These inefficiencies may be masked today on dedicated hardware, but as soon as you introduce arbitration to your dependent resource you are going to find out real fast.
What a lot of bean counters who are demanding virtualization fail to recognize is that database servers, as guest operating systems, offer their own consolidation layer. There is no reason why you cannot move consolidate multiple logical database instances on one physical server, even to the point of moving IP addresses, setting up additional host names, etc..., to allow for this natural coalescing of services to take place. And, with this model not only do you retain the cost savings that the management is pushing for reduced number of physical hosts, but you retain the block access to physical resources without the impingement of the arbitrary hypervisor, which can make beneficial decisions sometimes and not others.
The same holds true for other guest operating systems, like Java. Virtualization solutions are typically busy environments and the hypervisor has to make lots of decisions on who "gets the token" on a resource. Anytime you can eliminate that layer you are going to be better off.
Coalesce multiple instances using the natural guest operating system layer first. Odds are you will be able to hit your platform consolidation and performance targets easier.