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
Okay now that I actually look into this and wrap my head around it, virt-manager should change. /github. com/virt- manager/ virt-manager/ commit/ 15a6a7e2105440d f528f75c4df4d24 71df28bd1e
See this previously mentioned change: https:/
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 ba08f84b3408744 e9aa9763d100e8a a217c1f5ff
Author: Cole Robinson <email address hidden>
Date: Sat Sep 19 18:06:45 2020 -0400
addstorage: Return to using qcow2 sparse by default