Description of problem: Running IOzone to an fedora RHEL5 or f9 guest, adding -I flag for directI/O give 3-4x the performance of the raw device. Version-Release number of selected component (if applicable): 2.6.25-0.218.rc8.git7.fc9.x86_64 How reproducible: 100% Steps to Reproduce: 1. copy iozone kit http://people.redhat.com/dshaks/.kits/iozone-3-233.i386.rpm 2. moutn a data disk in the guest (either file or phy based) 3. ./iozone -s 1g -r 64k -I -f /perf1 Actual results: f9_base achieved 161 MB/sec f9_fv in fv guest achieved 785 MB/sec Expected results: <= 161 MB/sec as it can't run faster than the raw device Additional info:
Just to make it clear for everyone reading - the issue with the fact that FV is outperforming baremetal is that it implies that writes aren't being flushed to the host's disk before being acknowledged which, in turn, means the guests could be corrupted when something goes wrong.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Core problem here is that libvirt is not setting the 'cache=off' flag to -drive argument when launching QEMU.
Patch posted http://www.redhat.com/archives/libvir-list/2008-October/msg00180.html
libvirt now has the ability to set the caching mode in the XML for a disk, as of 0.6.0 release. So going to close this bug now.