Okay now that I actually look into this and wrap my head around it,
virt-manager should change.
See this previously mentioned change:
https://github.com/virt-manager/virt-manager/commit/15a6a7e2105440df528f75c4df4d2471df28bd1e
The idea behind virt-manager's default was if user selected 'raw' for disk
images, assume the user wants
to maximize performance, so fully allocate the disk.
qcow2 didn't support anything except sparse, so the sparse=True vs sparse=False
made no difference.
So we always set sparse=False
Then qcow2 grows non-sparse support, and virt-manager is suddenly defaulting to
it. That's a pretty big semantic
change. Even if falloc is fast enough in most cases, it is still claiming all
the storage up front. Which
is not the historically intended behavior.
So I pushed a change to virt-manager to default to only use non-sparse for raw
format by default.
That should side step this issue
I'll be pushing a new release with the fix sometime this coming week
commit ba08f84b3408744e9aa9763d100e8aa217c1f5ff
Author: Cole Robinson <crobi...@redhat.com>
Date: Sat Sep 19 18:06:45 2020 -0400
addstorage: Return to using qcow2 sparse by default
--
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-manager/+bug/1847105/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
