Bug 960793

Summary:	Check support for O_DIRECT before using it
Product:	[Community] Virtualization Tools	Reporter:	Zeeshan Ali <zeenix>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED DEFERRED	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	alejandro.mankowski, berrange, cfergeau, crobinso, libvirt-maint, mclasen, rbalakri, rjones
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-09 23:05:39 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Zeeshan Ali 2013-05-08 02:28:59 UTC

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.

Comment 1 Zeeshan Ali 2014-10-15 00:06:26 UTC

Hello?

Comment 2 Zeeshan Ali 2014-10-15 23:14:17 UTC

Since nobody showed any interest, I marked the original Boxes bug as WONTFIX. Feel free to prove me wrong. :)

Comment 3 Zeeshan Ali 2014-10-20 15:22:22 UTC

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?

Comment 4 Daniel Berrangé 2014-10-20 15:31:11 UTC

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.

Comment 5 Daniel Berrangé 2014-10-20 16:08:12 UTC

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.

Comment 6 Zeeshan Ali 2014-10-20 16:14:49 UTC

or maybe just translate 'default' to some smart options so apps don't have to hardcode the cache mode?

Comment 7 Cole Robinson 2016-04-09 23:05:39 UTC

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