From: "Richard W.M. Jones" <rjones@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: folkert <folkert@vanheusden.com>,
kvm@vger.kernel.org, virt-tools-list@redhat.com
Subject: Re: [virt-tools-list] cache write back & barriers
Date: Sun, 16 Jun 2013 13:06:13 +0100 [thread overview]
Message-ID: <20130616120315.GA11734@redhat.com> (raw)
In-Reply-To: <20130614105304.GB26780@stefanha-thinkpad.redhat.com>
On Fri, Jun 14, 2013 at 12:53:04PM +0200, Stefan Hajnoczi wrote:
> On Thu, Jun 13, 2013 at 10:47:32AM +0200, folkert wrote:
> > Hi,
> >
> > > > In virt-manager I saw that there's the option for cache writeback for
> > > > storage devices.
> > > > I'm wondering: does this also make kvm to ignore write barriers invoked
> > > > by the virtual machine?
Looking at current git, the cache types supported by virt-manager are:
- none
- writethrough
- writeback
- default [virt-manager only, not in virt-install]
These translate directly into the libvirt <driver ... cache="...">
field which you can find documented here:
http://libvirt.org/formatdomain.html#elementsDisks
As far as I can tell (from looking at libvirt sources) as long as you
have a modern qemu these will translate to the same names on the qemu
command line.
> > > No, that would be unsafe. When the guest issues a flush then QEMU will
> > > ensure that data reaches the disk with -drive cache=writeback.
> >
> > Aha so the writeback behaves like the consume harddisks with write-cache
> > on them.
In answer to the original question by 'folkert':
> > In that case maybe an extra note could be added to the virt-manager
> > (excellent software by the way!) that if the client vm supports
> > barriers, that write-back in that case then is safe. Agree?
I suspect the problem with doing this is it depends on the hypervisor.
Likely for qemu and Xen (since it uses a qemu device model) this would
be true. Possibly not for other hypervisors that virt-manager can
control.
Generally speaking, it would be nice to document these properly and
also how they are implemented in different hypervisors, because I know
I for one don't find these settings very obvious. So, patches welcome!
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
next prev parent reply other threads:[~2013-06-16 12:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-12 8:03 cache write back & barriers folkert
2013-06-13 8:26 ` Stefan Hajnoczi
2013-06-13 8:47 ` folkert
2013-06-14 10:53 ` Stefan Hajnoczi
2013-06-16 12:06 ` Richard W.M. Jones [this message]
2013-06-13 14:40 ` Alexandre DERUMIER
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130616120315.GA11734@redhat.com \
--to=rjones@redhat.com \
--cc=folkert@vanheusden.com \
--cc=kvm@vger.kernel.org \
--cc=stefanha@gmail.com \
--cc=virt-tools-list@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.