Follow these steps to reappear the bug:
1. start qemu
2. add persistent bitmap: '{ "execute": "block-dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": "bitmap0", "persistent":true }}'
3. stop qemu (Friendly shutdown)
4. re-start qemu
5. kill -9 qemu (simulate Host crash, eg. lose power)
6. re-start qemu
Now, the '{ "execute": "query-block" }' can't find the bitmap0. I can understand at this point, because the bitmap0 has not been synchronized yet.
But, when I try to add persistent bitmap0 again: '{ "execute": "block-dirty-bitmap-add", "arguments": {"node": "drive-virtio-disk1","name": "bitmap0", "persistent":true }}', It failed:
{"id":"libvirt-42","error":{"class":"GenericError","desc":"Can't make bitmap 'bitmap0' persistent in 'drive-virtio-disk1': Bitmap with the same name is already stored"}}
In other word, when qemu crash, the qcow2 image remain the incomplete persistent bitmap.
---
host: centos 7.5
qemu version: 2.12.0 and 3.1.0, other version I does not test yet.
qemu command: qemu-system-x86_64 -name guest=test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-190-test./master-key.aes -machine pc-i440fx-3.1,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -m 1024 -mem-prealloc -mem-path /dev/hugepages1G/libvirt/qemu/190-test -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 1c8611c2-a18a-4b1c-b40b-9d82040eafa4 -smbios type=1,manufacturer=IaaS -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot menu=on,strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/opt/vol/sas/fb0c7c37-13e7-41fe-b3f8-f0fbaaeec7ce,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on -drive file=/opt/vol/sas/bde66671-536d-49cd-8b46-a4f1ea7be513,format=qcow2,if=none,id=drive-virtio-disk1,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1,write-cache=on -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:85:45:3e:d4:3a,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=35,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on
On 2/2/19 11:52 PM, Cheng Chen wrote: dirty-bitmap- add", "arguments": {"node": "drive- virtio- disk1", "name": "bitmap0", "persistent":true }}'
> Public bug reported:
>
> Follow these steps to reappear the bug:
>
> 1. start qemu
> 2. add persistent bitmap: '{ "execute": "block-
> 3. kill -9 qemu (simulate Host crash, eg. lose power)
> 4. restart qemu
>
> Now, the '{ "execute": "query-block" }' can't find the bitmap0. I can
> understand at this point, because the bitmap0 has not been synchronized
> yet.
This matches my observations here: /lists. gnu.org/ archive/ html/qemu- devel/2019- 01/msg07700. html
https:/
I'm of the opinion that updating the qcow2 headers any time a persistent
bitmap is created or destroyed is worthwhile, even if the headers must
still mark the bitmap as in-use. True, the crash will leave the bitmap
as inconsistent, which is no different than if the bitmap is never
written to the qcow2 header (when booting a new qemu, an inconsistent
bitmap on disk has the same status as a missing bitmap - both imply that
an incremental backup is not possible, and so a full backup is needed
instead). But the creation of bitmaps is not a common occasion, and
having the metadata track that a persistent bitmap has been requested
seems like it would be useful information during a debugging session.
> virtio- disk1", "name": libvirt- 42","error" :{"class" :"GenericError" ,"desc" :"Can't make virtio- disk1': Bitmap with the
> But, when I try to add persistent bitmap0 again: '{ "execute": "block-
> dirty-bitmap-add", "arguments": {"node": "drive-
> "bitmap0", "persistent":true }}', It failed:
>
> {"id":"
> bitmap 'bitmap0' persistent in 'drive-
> same name is already stored"}}
>
> In other word, when qemu crash, the qcow2 image remain the incomplete
> persistent bitmap.
Does Andrey's proposed patch adding persistent bitmap details to
'qemu-img info' show anything after you first kill qemu?
/me goes and tests...
Oh weird - with Andrey's patch, we get semi-duplicated information
during query-block (at least, after an initial clean shutdown prior to
attempting an abrupt shutdown):
{"return": [{"io-status": "ok", "device": "ide0-hd0", "locked": false, file_depth" : 0, "drv": "qcow2", "iops": 0, key_missing" : false}, "qdev": unattached/ device[ 18]", "dirty-bitmaps": [{"name": "b2",
"removable": false, "inserted": {"iops_rd": 0, "detect_zeroes": "off",
"image": {"virtual-size": 104857600, "filename": "file5",
"cluster-size": 65536, "format": "qcow2", "actual-size": 208896,
"format-specific": {"type": "qcow2", "data": {"compat": "1.1",
"lazy-refcounts": false, "bitmaps": [{"flags": ["in-use", "auto"],
"name": "b2", "granularity": 65536}], "refcount-bits": 16, "corrupt":
false}}, "dirty-flag": false}, "iops_wr": 0, "ro": false, "node-name":
"#block172", "backing_
"bps_wr": 0, "write_threshold": 0, "encrypted": false, "bps": 0,
"bps_rd": 0, "cache": {"no-flush": false, "direct": false, "writeback":
true}, "file": "file5", "encryption_
"/machine/
"status": "active", "granularity": 65536, "count": 0}, {"name": "b",
"status": "active", "granularity": 65536, "count": 0}], "type": "unknown"}]}
Note that the "format-specific" listing has a "bitmaps" entry resulting
fro...