user-level: 0.910
permissions: 0.840
risc-v: 0.826
hypervisor: 0.825
virtual: 0.817
mistranslation: 0.816
debug: 0.814
KVM: 0.800
TCG: 0.787
graphic: 0.785
vnc: 0.782
files: 0.779
VMM: 0.777
arm: 0.775
device: 0.771
register: 0.769
peripherals: 0.768
assembly: 0.766
boot: 0.765
performance: 0.763
architecture: 0.761
socket: 0.756
semantic: 0.753
ppc: 0.748
PID: 0.746
network: 0.742
kernel: 0.734
i386: 0.732
x86: 0.724

 Failed to make dirty bitmaps writable: Can't update bitmap directory: Operation not permitted

blockcommit does not work if there is dirty block.

virsh version
Compiled against library: libvirt 4.10.0
Using library: libvirt 4.10.0
Using API: QEMU 4.10.0
Running hypervisor: QEMU 2.12.0

Scenario:
1. Create an instance
2. Add dirty bitmap to vm disk.
3. create a snapshot(external or internal)
4. revert snapshot or blockcommit disk

virsh blockcommit rota-test vda  --active
Active Block Commit started

virsh blockjob rota-test vda --info
No current block job for vda


rota-test.log:
 starting up libvirt version: 4.10.0, package: 1.el7 (CBS <email address hidden>, 2018-12-05-12:27:12, c1bk.rdu2.centos.org), qemu version: 2.12.0qemu-kvm-ev-2.12.0-18.el7_6.1.1, kernel: 4.1.12-103.9.7.el7uek.x86_64, hostname: vm-kvm07
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name guest=rota-test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-101-rota-test/master-key.aes -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off -cpu SandyBridge,hypervisor=on,xsaveopt=on -m 8192 -realtime mlock=off -smp 3,sockets=3,cores=1,threads=1 -uuid 50dec55c-a80a-4adc-a788-7ba23230064e -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=59,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/var/lib/libvirt/images/rota-0003,format=qcow2,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -netdev tap,fd=61,id=hostnet0,vhost=on,vhostfd=62 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e8:09:94,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -spice port=5902,addr=0.0.0.0,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on
2019-01-03T07:50:43.810142Z qemu-kvm: -chardev pty,id=charserial0: char device redirected to /dev/pts/3 (label charserial0)
main_channel_link: add main channel client
red_qxl_set_cursor_peer:
inputs_connect: inputs channel client create
inputs_channel_detach_tablet:
#block339: Failed to make dirty bitmaps writable: Can't update bitmap directory: Operation not permitted

Acknowledged; target is 4.2.

Vladimir Sementsov-Ogievskiy has some patches in-flight that seek to correct block commit behavior with bitmaps: https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg01160.html


Hi, this should be fixed in 4.2. It looks like you're still on 2.12.0 based on the report. Closing under the assumption this is fixed. If you discover otherwise, please feel free to re-open (or file a new bug.)