We received a bug report some time ago against Boxes where user was unable to create (actually launch) VMs because his home directory was on a filesystem that doesn't support O_DIRECT: https://bugzilla.gnome.org/show_bug.cgi?id=679837 IMO either libvirt should a. check if O_DIRECT is available and ignore 'cache=none' (probably with some warning or debug in the log) or b. provide some API for apps to query which cache options are available for a particular disk driver.
Hello?
Since nobody showed any interest, I marked the original Boxes bug as WONTFIX. Feel free to prove me wrong. :)
Turns out that this is a problem on plain ext4 too: https://bugzilla.gnome.org/show_bug.cgi?id=738872 which makes this bug much more important. Could the solution be as simple as not specificying cache=none explicitly to libvirt and libvirt uses a good default based on filesystem support?
ext4 supports O_DIRECT just fine, so I don't really believe that b.g.o report. There must be some other unmentioned factor involved causing that bug reporter problems.
We recently introduced a way to report finer grained capability info per guest emulator type, but this doesn't quite fit in that since we need per-storage pool instance. I think it would be reasonable to look at some way to report what cache options a storage pool supports. Probably not doing it as part of the storage pool XML, but as a separate method to query capabilities of the storage pool perhaps. A completely different idea would be to have an node levle API that reports host filesystems and their cache modes.
or maybe just translate 'default' to some smart options so apps don't have to hardcode the cache mode?
Rich had a good write up about cache modes here: https://rwmj.wordpress.com/2013/09/02/new-in-libguestfs-allow-cache-mode-to-be-selected/ Basically what virt-manager does is only use cache=none for block devices, since that's it will reliably work there and that's the main place it adds benefits AFAIK. Having some sort of adaptive cache default would be handy, like cache=none-if-it-will-work or cache=give-me-the-optimal-value. But if someone is going to do that work I'd suggest doing it at the qemu level anyways which is a) in a better spot to make those decisions, and b) it's then shared by libvirt and direct qemu users alike. So I don't think the ideas floated here should live in libvirt