Is paravirtualization worth the hassle?

Question

I've been experimenting with both fully virtualized and paravirtualized guests (OEL 5.4 64-bits with Database 11g and user apps) under VM Server 2.2 to see how I want to make my final live production decisions, and have run into some strange issues with paravirtualization.
I've read that a paravirtualized guest can be faster than a fully-virtualized guest and wanted to test it for myself with my database and apps.
Creating a fully virtualized guest using the install-from-media method is straightforward and seems to give no problems and runs quite well.
Creating a paravirtualized guest the same method has been giving me problems, but I finally got one running.
First of all, it seems like only about one out of three paravirtualized guests created will actually start up and run. I've followed the exact same steps each time, but most times, after completing the Anaconda installer phases all the way to the point where you reboot the guest for the first time, it failed to start with an error something like: VmError: (1, 'Internal error', 'xc_dom_do_gunzip: inflate failed (rc=-3)\n'). I blew away the virtual machine and started over, and after the third attempt, it finally started up, but failed to mount the /boot filesystem, so I dropped into single user mode and ran fsck on /boot. After another restart, I finally was able to get a paravirtualized guest up and running.
I've gone thru this ordeal over a dozen times now creating a paravirtualized guest, and only successfully been able to make three of them start and run. All these numerous failures to start with the gunzip error and having to manually fsck the /boot filesystems has made my confidence level in paravirtualized guests pretty much zero. I doubt if I could put my faith in running one as a production VM now. Even when I get one running, it still gives one boot error message of unable to update the Intel cpu microcode, but I understand what's going on there and that step of the boot process could be deleted. The install process probably should've detected that it was running in a paravirtualized VM and not included that script to begin with.
Anyway, I've got my database and apps installed into a paravirtualized guest now, and have begun testing performance. I did run into the issue that the whole jvm subsystem of the database had to be ripped out and reinstalled under the paravirtualized guest, and also the dbconsole had to be removed and re-installed as well. I'm using tarballs of my database and application filesystems that were built within a fully virtualized guest, and even though they work fine when untarred into another freshly-created fully-virtualized guest without any repairs or modifications, these two issues arose when simply unloading the tarballs into a paravirtualized guest that was otherwise identical to the fully-virtualized guest.
I seem to be getting slightly better query times on the paravirtualized guest, and it might be worth the effort put into making a paravirtualized guest run, but I'm now worried that paravirtualized guests will be flakey and unstable.
Anybody else run into these kinds of issues with paravirtualization?
The fully-virtualized guests seem to be rock-solid and very straightforward to build, configure and run.
Is sticking with fully virtualized guests the safer choice?
My VM Server is a brand new HP Proliant DL370 with dual quad-core 2.9GHz Nehalem-core Xeons and 64GB ram, and does seem to have ample horsepower to get the speed I need with fully-virtualized guests running my database and apps.

Answer 1

I haven't heard of anyone running into the issues you mention with paravirt guests. We have extensively tested it in-house, and have also provided pre-built templates for paravirt database guests. Maybe you could give one of those a try, and see if they're more stable. There is a small chance that a guest OS configuration issue is causing the instability.