Fix included in qemu-kvm-rhev-2.12.0-18.el7_6.3

Host:
kernel-3.10.0-957.1.2.el7.x86_64
qemu-kvm-rhev-2.12.0-18.el7_6.2.x86_64

Guest:
kernel-3.10.0-957.el7.x86_64

This issue was reproduced with above test environment.

(gdb) bt
#0  0x00007ff47f77b207 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1  0x00007ff47f77c8f8 in __GI_abort () at abort.c:90
#2  0x00007ff47f774026 in __assert_fail_base (fmt=0x7ff47f8ceea0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55a658647e18 "bs->open_flags & 0x0800", file=file@entry=0x55a6585ad7cc "block.c", line=line@entry=855, function=function@entry=0x55a658649b60 <__PRETTY_FUNCTION__.30767> "bdrv_child_cb_inactivate") at assert.c:92
#3  0x00007ff47f7740d2 in __GI___assert_fail (assertion=assertion@entry=0x55a658647e18 "bs->open_flags & 0x0800", file=file@entry=0x55a6585ad7cc "block.c", line=line@entry=855, function=function@entry=0x55a658649b60 <__PRETTY_FUNCTION__.30767> "bdrv_child_cb_inactivate") at assert.c:101
#4  0x000055a65840020e in bdrv_child_cb_inactivate (child=<optimized out>) at block.c:855
#5  0x000055a658401f92 in bdrv_inactivate_recurse (bs=0x55a65a410800, setting_flag=setting_flag@entry=true) at block.c:4460
#6  0x000055a6584042fd in bdrv_inactivate_all () at block.c:4512
#7  0x000055a6583a55d2 in qemu_savevm_state_complete_precopy (f=0x55a65b2d4000, iterable_only=<optimized out>, inactivate_disks=<optimized out>) at migration/savevm.c:1198
#8  0x000055a6583a146e in migration_thread (opaque=0x55a65a358280) at migration/migration.c:2144
#9  0x00007ff47fb19dd5 in start_thread (arg=0x7ff358cb3700) at pthread_create.c:307
#10 0x00007ff47f842ead in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Host:
kernel-3.10.0-957.1.2.el7.x86_64
qemu-kvm-rhev-2.12.0-18.el7_6.3.x86_64

Guest:
kernel-3.10.0-957.el7.x86_64

With qemu-kvm-rhev-2.12.0-18.el7_6.3, this issue fixed. 

Hot plugging a backend image with 'blockdev-add', and no device is attached to it, then could do migration operation successfully.

Steps:
1)Boot up both src and dst guests:
/usr/libexec/qemu-kvm \
       	-S \
       	-name 'vm-test-2' \
	-boot menu=on \
       	-sandbox off \
       	-machine pc \
       	-nodefaults \
       	-device qxl-vga,bus=pci.0,addr=0x2 \
	-drive id=drive_win,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=/home/kvmtest_lchai/win.qcow2 \
	-device virtio-blk-pci,id=sys_disk,drive=drive_win,bus=pci.0,addr=0x4 \
	-device virtio-net-pci,mac=30:9c:23:c7:45:78,id=iddd,vectors=4,netdev=idttt \
	-netdev tap,id=idttt,vhost=on \
	-m 4G \
	-smp 12,maxcpus=12,cores=6,threads=1,sockets=2 \
	-cpu 'Penryn' \
	-rtc base=utc,clock=host,driftfix=slew \
	-enable-kvm \
	-monitor stdio \
	-vnc :1 \
        -qmp tcp:127.0.0.1:4444,server,nowait

For dst guest, 
        -incoming tcp:0:5200 \ 
	-vnc :2 \
        -qmp tcp:127.0.0.1:4445,server,nowait

2)In both src and dst sides, hot plug the image with blockdev-add in qmp:
# qemu-img create -f qcow2 fullbackup.qcow2 10G
 {"execute":"blockdev-add","arguments":{"driver":"file","node-name":"fullbackup","filename":"/home/kvmtest_lchai/fullbackup.qcow2"}}
 { 'execute':'blockdev-add','arguments':{'driver':'qcow2','node-name':'fbk','file':'fullbackup'}}

3)In src, do migration and check its status in qmp:
 {"execute":"migrate","arguments":{"uri":"tcp:0:5200"}}
=> The migration operation succeeded.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0209