I've run databases in VM with no significant problems (both small live databases and large test/dev ones, though no large live databases to date). Other than the potential official support issue you key, as with a physical DB server, is going to be I/O performance and RAM.
For I/O performance, my experience is that virtual drive never perform quite as well as relevant technology stakeholders claim, but never nearly as badly as the ney-sayers claim. As long as you have a good physical I/O subsystem serving the VMs (a nice shiny RAID10 array of fast drives, for instance) all should be well. All the normal performance tweaks hold out for VMs, like keeping data and logs on separate arrays (or separate drives if using single drives instead of RAID) and temporary data (assuming Oracle has an equivalent to MSSQLs tempdb
on another array (some suggest RAID0 for performance, though I'm wary of RAID0 in production use even for temporary data as I don't want the downtime when a drive fails) if you can too. Do your RAID either completely in hardware (with a good RAID controller) or in software on the physical host machine. As daft as it sounds I have seen people recommend doing RAID in the VMs instead...
For RAM, just give the DB VMs as much as you can and make sure it is dedicated to them and won't be swapped by the host.
IMO: databases work in VMs and certainly perform well enough if you have the hardware to serve them and don't overcommit the hardware (two database running VMs that see significant load will cause more I/O load then one database server handling the same content as the two instances can't manage RAM and I/O ordering between themselves, where a single DB server instance can juggle resources between jobs as needed).