Re: [Qemu-devel] [Bug 1814418] [NEW] persistent bitmap will be inconsistent when qemu crash,

[John Snow]

On 2/12/19 5:56 AM, Vladimir Sementsov-Ogievskiy wrote:
> 12.02.2019 4:10, John Snow wrote:
>> On 2/4/19 11:22 AM, Vladimir Sementsov-Ogievskiy wrote:

>>> In-use bitmaps in the image may appear only after some kind of qemu crash. 
>>> Isn't
>>> it a good reason to call qemu-img check? So, haw about just forbid to start 
>>> qemu
>>> if there are any in-use bitmaps?
>>>
>>
>> I have wondered this recently.
>>
>> I am against just silently loading and deleting the bitmaps because I
>> don't want any chance for data corruption if the bitmap gets lost
>> accidentally. I like the loud failure.
>>
>> I kind of like the idea of just failing to load the image at all,
>> because it does necessitate user action, but it feels a little user hostile.
> 
> Yes, it may be to noisy to have to call qemu-img check after any unexpected 
> process
> kill, and it's not like real machine behave.
> 
>>
>> Maybe we can do some kind of soft-load for corrupted bitmaps where they
>> will remain "locked" and cannot be re-written to disk until the user
>> issues a clear command to reset them -- so the user knows full well the
>> backup chain is broken. Maybe this is a good solution to the problem?
>>
>> What do you think?
> 
> It should not be just "locked", it should be visibly "corrupted", for user to 
> understand
> the reason of why bitmap is unusable. So, it should be a new state of flag.
> 

Right, sure. It will behave similarly to a locked, disabled bitmap. You
can't do anything to it, it doesn't record writes, etc. A new flag is
helpful for the purpose.

> So, instead of just ignoring in-use bitmaps on start, we load them, benefit of
> having them in list, but the only thing which can be done with them is
> block-dirty-bitmap-remove (and it's additional reason, why it can't be 
> "locked" state).
> 

I'd say remove or clear, both would make sense. I suppose we only *need*
one and remove covers all cases, so I'll go with this suggestion and
offer clear as an additional patch that we could take or leave.

> I'm not sure that we should load data for such bitmaps, so they may be loaded 
> as
> BdrvDirtyBitmaps with .corrupted = true and .bitmap = NULL.
> 

Probably doesn't hurt to just load a blank bitmap instead of trying to
special case it with the NULL, but understood: we don't have to load the
data because it's junk.

> 
> Hmm, go and check that it will not break bitmaps migration related logic, 
> which is described
> in BIG comment in block/qcow2.c. Looks like all is ok, and in only valid case 
> when we could
> see in-use bitmaps is
> 
>       * One remaining possible case when we don't want load bitmaps:
>       *
>       * 4. Open disk in inactive mode in target vm (bitmaps are migrating or
>       *    will be loaded on invalidation, no needs try loading them before)
> 
> 
> and we don't try loading bitmaps in this case:
> 
>      if (!(bdrv_get_flags(bs) & BDRV_O_INACTIVE)) {
>         < load bitmaps >
> 
> So the only thing to do additionally here is enhance the comment, to
> s/no needs/must not do it, as they will be loaded as corrupted/.
> 
> 

Sounds good to me, I'll get cooking.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1814418

Title:
  persistent bitmap will be inconsistent when qemu  crash,

Status in QEMU:
  New

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1814418/+subscriptions