[
https://issues.apache.org/jira/browse/CLOUDSTACK-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14723325#comment-14723325
]
Ronald van Zantvoort edited comment on CLOUDSTACK-1302 at 8/31/15 11:54 AM:
----------------------------------------------------------------------------
IMHO This feature is implemented in the wrong place.
The cache setting is a vital tunable which determines QEMU's cache behaviour
and it's proper setting is both based on how much risk you wish to take with
your data and the combined settings of the backend stores you're connecting to.
For example, Ceph will demand writeback for safe RBD's cache operation, while
for an NFS or a battery-backed RAID you'd might want to resort to none or even
writethrough (since the caching can reside on another level).
The Disk Offerings have the explicit ability to resolve to different kinds of
Stores which might/will need different settings. It therefore makes no sense to
put it there; it'd merely reflect a quite likely dangerous preference. Whether
or not anyone would *want* it to be a *preference* is another question.
Personally I believe Cloud Providers should never try to play fast & loose with
customers' data (and there's already plenty of ways to do that anyway, even if
the setting sits with the Stores), and customers wishing to take it easy on
their transaction safety have a plethora of options of doing that within their
VM.
This is probably the same reason the OP requested "Ideally this would get set
on a per datastore basis."
was (Author: theloeki):
IMHO This feature is implemented in the wrong place.
The cache setting is a vital tunable which determines QEMU's cache behaviour
and it's proper setting is both based on how much risk you wish to take with
your data and the combined settings of the backend stores you're connecting to.
For example, Ceph will demand writeback for safe RBD's cache operation, while
for an NFS or a battery-backed RAID you'd might want to resort to none or even
writethrough (since the caching can reside on another level).
The Disk Offerings have the explicit ability to resolve to different kinds of
Stores which might/will need different settings. It therefore makes no sense to
put it there; it'd merely reflect a quite likely dangerous preference. Whether
or not anyone would *want* it to be a *preference* is another question.
Personally I believe Cloud Providers should never try to play fast & loose with
customers' data (and there's already plenty of ways to do that anyway, even if
the setting sits with the Stores), and customers wishing to take it easy on
their transaction safety have a plethora of options of doing that within their
VM.
> Add per storage setting for cache="none/writeback/writethrough" options for
> VMs on KVM hypervisor
> -------------------------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-1302
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1302
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
> Affects Versions: 4.0.0
> Environment: Ubuntu 12.04.2 Host, KVM hypervisor
> Reporter: Jason Villalta
> Assignee: Wido den Hollander
> Priority: Minor
> Fix For: 4.4.0, 4.5.0
>
>
> Version 4.0.0 of Cloudstack has a hard coded value of cache=none for virtual
> machines deployed. This causes conflict with filesystems mounted with fuse
> such as ZFS, GlusterFs and CEPH as fuse does not support directio with these
> file systems. When starting VMs libvirt throws an error "could not open disk
> image <disk> Invalid argument"
> Changing the cache= setting to writethough or writeback solves this problem
> but there currently is no way to set this. Ideally this would get set on a
> per datastore basis.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
