Launchpad has imported 5 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=623188.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help
** Bug watch added: Red Hat Bugzilla #623188
https://bugzilla.redhat.com/show_bug.cgi?id=623188
** Also affects: virt-manager via
https://bugzilla.redhat.com/show_bug.cgi?id=623188
Importance: Unknown
Status: Unknown
--
LVM backed drives should default to cache='none'
https://bug
Anthony, upstream virt-manager doesn't change the cache default, though
we do in RHEL.
Wasn't the idea of having an adaptive cache default for qemu given the
okay on qemu-devel, particularly for cache=none for block devs? or am I
imagining things (could be the case since I can't seem to find the
t
Can't seem to find anything in the upstream changelogs or source to
indicate that such a change was made.
--
LVM backed drives should default to cache='none'
https://bugs.launchpad.net/bugs/568445
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to U
cache=writethrough and cache=none have equivalent data integrity.
FWIW, I believe most recent versions of virt-manager default to
cache=none for physical devices.
--
LVM backed drives should default to cache='none'
https://bugs.launchpad.net/bugs/568445
You received this bug notification because
@Anthony,
I'm aware that I can manipulate the cache settings via libvirt's XML.
That's currently what I've been doing, manually after every VM creation.
However, my point is that qemu clearly recommends that caching not be
used with disks stored on raw volumes. Additionally, virt-manager does
not
I noticed the high iowait times a few weeks back when my guest backups
were taking a long time to complete. I believe this was sometime after
I added a VM to serve as a transparent proxy for my network, but can't
be entirely certain. Looking at the e-mail'd cron output, it was fairly
obvious that
** Attachment added: "lvm.txt"
http://launchpadlibrarian.net/45041031/lvm.txt
--
LVM backed drives should default to cache='none'
https://bugs.launchpad.net/bugs/568445
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
** Attachment added: "memory.txt"
http://launchpadlibrarian.net/45040936/memory.txt
--
LVM backed drives should default to cache='none'
https://bugs.launchpad.net/bugs/568445
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu
** Attachment added: "cpu.txt"
http://launchpadlibrarian.net/45040921/cpu.txt
--
LVM backed drives should default to cache='none'
https://bugs.launchpad.net/bugs/568445
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
** Attachment added: "drives.txt"
http://launchpadlibrarian.net/45040905/drives.txt
--
LVM backed drives should default to cache='none'
https://bugs.launchpad.net/bugs/568445
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu
The use-case of virt-manager is casual desktop virtualization. Usually,
a user of desktop virtualization benefits from using the host page cache
because subsequent launches of a VM are considerably faster since the IO
is kept in memory.
You can manipulate the cache settings via libvirt XML if you
@Jamin-
Okay, thanks for that last bit.
So given that information, I think this bug is triaged/wishlist against
virt-manager. If virt-manager can detect that you've selected a LVM
volume for the backing disk, then it could perhaps force cache=none.
I doubt, however, that we'll have time to work
Copying bug upstream, refiling against qemu-kvm, marking
incomplete/wishlist.
Anthony-
Can you share the reasoning for the default disk caching method with
upstream QEMU? Would it be a good or bad idea to change that in Ubuntu?
** Package changed: virt-manager (Ubuntu) => qemu-kvm (Ubuntu)
**
Looks like even upstream suggests disabling cache for best performance when
using raw volumes:
http://www.linux-kvm.org/page/Tuning_KVM
>From the above page:
QEMU also supports a wide variety of caching modes. Writeback is useful
for testing but does not offer storage guarantees. Writethrough (t
I fail to see how not using a cache provides any less data integrity
than using one. The default caching method, as you quote, is
writethrough which according to the manpage states:
By default, writethrough caching is used for all block device.
This means that the host page
16 matches
Mail list logo
