Bug 1855000 - RFE: set 'nodatacow' by default on VM image containing dir when on Btrfs
Summary: RFE: set 'nodatacow' by default on VM image containing dir when on Btrfs
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1851166
TreeView+ depends on / blocked
 
Reported: 2020-07-08 15:35 UTC by Chris Murphy
Modified: 2020-08-23 02:48 UTC (History)
14 users (show)

Fixed In Version: libvirt-daemon-6.6.0-1.fc33.x86_64
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-08-23 02:48:27 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Chris Murphy 2020-07-08 15:35:58 UTC
It's generally recommended by upstream Btrfs development to set 'nodatacow' using 'chattr +C' on the containing directory for VM images. 

Is this something libvirt can and should do? 

It implies no compression and no data checksums. Could there be use cases in which it's preferred to do compression and checksumming on VM images? In that case the fragmentation problem can be mitigated by periodic defragmentation.

Another option is to have the installer set 'chattr +C' in the short term?

Three advantages of libvirt awareness of Btrfs:

(a) GNOME Boxes and other users of libvirt can then use this same mechanism, and apply to their locations

(b) creating the containing directory as a subvolume instead of a directory
    (1) btrfs snapshots are not recursive so this subvolume would prevent this location from being snapshot and thus (temporarily) resuming datacow.
    (2) in heavy workloads there can be lock contention on file btrees, and a subvolume is a dedicated file btree so this might reduce any tendency for lock contention

(c) virtiofs might be able to take advantage of btrfs subvolumes

Comment 1 Chris Murphy 2020-07-08 15:39:08 UTC
Relates to approved Fedora 33 feature, BtrfsByDefault
https://fedoraproject.org/wiki/Changes/BtrfsByDefault

Comment 2 Daniel Berrangé 2020-07-09 08:12:08 UTC
Would you mind taking this set of questions to the libvirt upstream mailing list, as I think the general task of optimization of KVM virt wrt Btrfs needs broader discussion than will happen in Fedora bugzilla https://www.redhat.com/archives/libvir-list/

Comment 3 Chris Murphy 2020-07-20 19:49:12 UTC
Latest update on the plan from libvirt folks
https://www.redhat.com/archives/libvir-list/2020-July/msg01382.html

Comment 4 Neal Gompa 2020-07-26 21:42:18 UTC
Upstream libvirt will resolve this issue with version 6.6.0. The 6.6.0~rc1 release already includes the necessary enhancements.

Comment 5 Chris Murphy 2020-08-20 04:05:16 UTC
Tested with GNOME Boxes, ~/.local/share/gnome-boxes/images does have chattr +C set, and each qcow2 created or copied there does too.

Comment 6 Chris Murphy 2020-08-20 04:14:48 UTC
Also tested with virt-manager, /var/lib/libvirt/images does NOT have chattr +C set. Reproduce steps:

1. Create a new virtual machine
2. Local install media
3. Browse and choose Fedora-Workstation-Live-x86_64-33-20200818.n.0.iso
4. Set operating system to Fedora Rawhide
5. Accept defaults for memory and cpu
6. Create a disk image size of 5G
7. Finish

# lsattr /var/lib/libvirt
-------------------- ./boot
-------------------- ./dnsmasq
-------------------- ./filesystems
-------------------- ./images
-------------------- ./network
-------------------- ./qemu
-------------------- ./swtpm
# lsattr /var/lib/libvirt/images
-------------------- ./Fedora-Workstation-Live-x86_64-33-20200818.n.0.iso
-------------------- ./vm1.qcow2

Comment 7 Chris Murphy 2020-08-22 23:15:39 UTC
I did a new clean install of Fedora-Workstation-Live-x86_64-33-20200821.n.0.iso on baremetal, and before step 1 above, /var/lib/libvirt/images has had chattr +C set correctly. It appeared to happen during a second authentication dialog about local security policy. 

In the comment 6 case, I'd already had the storage pool activated with an older version of libvirtd.

Comment 8 Neal Gompa 2020-08-23 02:40:39 UTC
Then this is working as intended, since it only kicks in for newly initialized storage pools...


Note You need to log in before you can comment on or make changes to this bug.