Ubuntu 20.10 (Groovy Gorilla) has reached end of life, so this bug will
not be fixed for that specific release.
** Changed in: libvirt (Ubuntu Groovy)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Changed in: zfs
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshotting
To manage notifications about this bug go to
** Changed in: zfs-linux (Ubuntu)
Importance: Low => Undecided
** Changed in: zfs-linux (Ubuntu)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very
This bug was fixed in the package virt-manager - 1:2.2.1-3ubuntu2.1
---
virt-manager (1:2.2.1-3ubuntu2.1) focal; urgency=medium
* d/p/lp-1847105-addstorage-Return-to-using-qcow2-sparse-by-default.patch:
fix slow disk allocation when using the defaults to to falloc (LP: #1847105)
On a system affected by the issue I was upgrading to focal-proposed:
The time on ZFS got down from >20sec to ~<2sec now and in ps I can catch
it is back on metadata as intended:
$ ps axlf | grep -e qemu-img | grep -v grep
0 0 48981 11928 20 0 164860 5020 ? Sl ? 0:00 \
Hello Andreas, or anyone else affected,
Accepted virt-manager into focal-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/virt-
manager/1:2.2.1-3ubuntu2.1 in a few hours, and then in the -proposed
repository.
Please help us by testing this new package.
As you explained I acknowledge that we are changing behaviour in Focal
here, but I agree with you that this is the least worst option.
** Description changed:
[Impact]
- * The defaults of virt-manager for disk allocation always worked fine
-when qcow2 had nothing but sparse support. So
** Tags added: focal regression-release
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshotting
To manage notifications about this bug go to:
https://bugs
** Description changed:
- This is a regression in eoan for me. I use virt-manager to create vms,
- and I noticed that creating one now takes more than a minute.
+ [Impact]
+
+ * The defaults of virt-manager for disk allocation always worked fine
+when qcow2 had nothing but sparse support. So
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/virt-manager/+git/virt-manager/+merge/391188
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow d
This bug was fixed in the package virt-manager - 1:2.2.1-4ubuntu2
---
virt-manager (1:2.2.1-4ubuntu2) groovy; urgency=medium
* d/p/lp-1847105-addstorage-Return-to-using-qcow2-sparse-by-default.patch:
fix slow disk allocation when using the defaults to to falloc (LP: #1847105)
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/virt-manager/+git/virt-manager/+merge/391055
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow d
It works (as expected):
before:
4 0 17337 263 20 0 163108 4240 - Sl ? 0:47 \_
/usr/bin/qemu-img create -f qcow2 -o
preallocation=falloc,compat=1.1,lazy_refcounts
/var/lib/libvirt/images/ubuntu20.04.qcow2 26214400K
Now:
4 0 43901 263 20 0 163108 5436
Now that we got the change we sort of wanted from the beginning I have
created a test build of virt-manager with the change applied.
I need to debug if that now really enters the right code paths for non
fallocate.
--
You received this bug notification because you are a member of Ubuntu
Bugs, wh
** Changed in: virt-manager
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshotting
To manage notifications about
FYI:
Related potential improvements in libvirt got identified, but a fix of the
"slowness" might indeed eventually land via ZFS (Details in the ML discussion
linked above).
And thanks Richard btw!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribe
Thanks Christian.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshotting
To manage notifications about this bug go to:
https://bugs.launchpad.net/virt-ma
Once the fix in libvirt landed we still have to change virt-manager as the
current storage request exactly matches the definition of the "then use falloc"
case.
I've requested that on the upstream bug [1], we will have to see how that turns
out.
Until we have a change to land in virt-manager (u
** Changed in: virt-manager
Status: Fix Released => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshotting
To manage notifications about
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/390220
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creati
grmls/, lets/and/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshotting
To manage notifications about this bug go to:
https://bugs.launchpad.net/vir
Got one Reviewed-by, lets 6.7.0 is released so it is not Frozen atm.
Giving it another day before pushing it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, sn
FYI CI is good and now it is also on the ML
https://www.redhat.com/archives/libvir-list/2020-September/msg00105.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creat
Updated the upstream bug and testing a fix in
https://gitlab.com/paelzer/libvirt/-/pipelines/184813619
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshott
Thread 6 "rpc-worker" hit Breakpoint 4, storageBackendCreateQemuImgOpts
(encinfo=0x0, opts=0x7fd1791102a0, info=0x7fd179110380) at
../../../src/storage/storage_util.c:712
(gdb) p *info
$3 = {format = 14, type = 0x7fd17ef920f0 "qcow2", inputType = 0x0, path =
0x7fd164018440 "/var/lib/libvirt/image
Tracing qemu-img calls when creating a new disk image from virt-manager:
Before change the qemu-img that libvirt emits due to the XML from virt-manager
is:
$ /usr/bin/qemu-img create -f qcow2 -o
preallocation=falloc,compat=1.1,lazy_refcounts
/var/lib/libvirt/images/ubuntu20.04.qcow2 26214400K
The underlying fallocate mode/0 compat was added to upstream ZFS with
the following commit:
commit f734301d2267cbb33eaffbca195fc93f1dae7b74
Author: adilger
Date: Thu Jun 18 12:22:11 2020 -0600
linux: add basic fallocate(mode=0/2) compatibility
While the change isn't too large for a SRU, I
** Changed in: libvirt (Ubuntu Focal)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshotting
To manage notifications about
** Changed in: virt-manager
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshotting
To manage notifications about
** Changed in: libvirt (Ubuntu Disco)
Status: Triaged => Won't Fix
** Changed in: virt-manager (Ubuntu Disco)
Status: Triaged => Won't Fix
** Changed in: zfs-linux (Ubuntu Disco)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubun
** Changed in: zfs
Status: Unknown => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshotting
To manage notifications about this bug go to:
htt
** Changed in: virt-manager
Importance: Undecided => Low
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshotting
To manage notifications about this bug
I've commented upstream (with ZFS) that we should fake the pre-
allocation (i.e. return success from fallocate() when mode == 0) because
with ZFS it's worthless at best and counterproductive at worst:
https://github.com/zfsonlinux/zfs/issues/326#issuecomment-540162402
Replies (agreeing or disagre
Thanks Andreas for already commenting on the upstream ZFS issue!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshotting
To manage notifications about thi
FYI - it seems upstream of libvirt/virt-manager settles on the new
behavior actually being preferable. I tend to agree, and the pain only
happens if you also run things on ZFS which would be resolved if [1] is
ever fully resolved.
Adding a ZFS task for that.
[1]: https://github.com/zfsonlinux/zfs
ZFS has https://github.com/zfsonlinux/zfs/issues/326
Which as TL;DR: fallocate is only supported with certain flags, and not really
matches the ZFS COW design. That might explain the slowness, as the fallback is
to write zeros.
** Bug watch added: Github Issue Tracker for ZFS #326
https://git
Andreas and I checked the effect of backing store to this as upstream
correctly mentioned that fallocate is supposed to be rather fast.
SLOW: EXT4 -> ZFS-image file -> LXD container -> libvirt
SLOW: Host-on-ZFS -> libvirt
Fast: Host-on-ext4 -> libvirt
Fast: Host-on-tmpfs -> libvirt
It seems we ca
I mentioned this only in the bug title, let me clarify a bit.
Snapshotting that machine (via virt-manager again) also takes over a
minute.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
Launchpad has imported 3 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=1759454.
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://hel
Also in https://bugzilla.redhat.com/show_bug.cgi?id=1759454 now
** Bug watch added: Red Hat Bugzilla #1759454
https://bugzilla.redhat.com/show_bug.cgi?id=1759454
** Also affects: virt-manager via
https://bugzilla.redhat.com/show_bug.cgi?id=1759454
Importance: Unknown
Status: Unkno
Reported at https://github.com/virt-manager/virt-manager/issues/56
Unfortunately LP can only conder one bug tracker for a project but virt-manager
has bugzilla AND github-issues so I can't link it as-is.
Maybe I should report it in BZ instead ...
** Bug watch added: github.com/virt-manager/virt-
With the older (pre 4.3) libvirt in place this creates it with metadata
preallocation.
/usr/bin/qemu-img create -f qcow2 -o
preallocation=metadata,compat=1.1,lazy_refcounts
/var/lib/libvirt/images/ubuntu18.04.qcow2 15728640K
In the related code this looks like:
834 if (info.size_arg
Since (for now) I assume it is a virt-manager bug I'll mark that medium and
libvirt as low.
It isn't higher as no other component has triggered it for a full cycle of
Disco and UCA-Rocky in the field as well as being "only" slower with the
benefit of actually being faster later.
--
You receive
In 18.04 it still passes the same XML for creation, but is fast (as
expected/reported).
Exchanging just the libvirt e.g. from UCA Rocky triggers the new behavior.
** Also affects: virt-manager (Ubuntu)
Importance: Undecided
Status: New
** Changed in: virt-manager (Ubuntu)
Status
Some updates for proper tracking.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshotting
To manage notifications about this bug go to:
https://bugs.launc
Interesting - at first the only related change seems to be in libvirt.
Function storageBackendCreateQemuImgOpts of src/storage/storage_util.c.
It is in there since [1] which on itself makes sense to me.
Also that particular change is in libvirt since v4.3 which means >=Cosmic and
we haven't had ma
Checking that in Disco confirms the same behavior:
[Di, 08 Okt 2019 07:19:27 virt-manager 12667] DEBUG (storage:719) Creating
storage volume 'ubuntu19.04.qcow2' with xml:
ubuntu19.04.qcow2
16106127360
16106127360
Into:
/usr/bin/qemu-img create -f qcow2 -o
pre
A quick check confirmed your report, thanks Andreas!
"preallocation" does exactly what expected and that takes the time you are
seeing:
Preallocation mode (allowed values: "off", "falloc", "full"). "falloc" mode
preallocates space for image by calling posix_fallocate(). "full" mode
preallocat
48 matches
Mail list logo
