Questions about online resizing a lun passthrough disk with virtio-scsi

[lma <lma@suse.de>]

Hi all,

I have questions about online resizing a scsi lun passthrough disk.
Here is my test scenario:
host A:
- the local 50GB sata /dev/sdd1 is configured as a physical volume,
   Created a 10GB logical volume.
- exported the lv by iscsi target by targetcli.

host B:
- connected to the above iscsi target to obtain a 'local' scsi disk,
   say the /dev/sdb.
- scsi lun passed through this /dev/sdb to a qemu-kvm linux guest.

hostA:~ # lvresize -L +5G /dev/vg0/lv0
hostB:~ # rescan-scsi-bus.sh -s //this script is in sg3_utils, '-s'
look for resized disks.
hostB:~ # block_resize via qmp to notify qemu self and guest os.
guest:~ # rescan-scsi-bus.sh -s
guest:~ # use the extended disk space.

My questions are:
Is the 'block_resize' mandatory to notify guest os after online resizing
a lun passed through disk? I'm curious it because I found there're 
couple
of ways can make guest os realize the disk capacity change.
e.g:
* run 'block_resize' via qmp to let virtio-scsi notify the frontend 
about
   capacity change.
* run 'rescan-scsi-bus.sh -s' inside guest.
* run 'sg_readcap --16 /dev/sda' inside guest.

I knew that the purpose of 'block_resize' is not only to notify guest 
os,
but also to update some internal structure's member, say 
bs->total_sectors.
What if I forgot to run 'block_resize', but run 'rescan-scsi-bus.sh -s' 
in guest?
In this case, Although the qemu's bs->total_sectors value isn't updated 
due
to missing 'block_resize', The guest os is still able to see the 
capacity
change, I'm curious is there any potential risks while using the 
extended
disk space in guest?

What is the best practice for online resizing a lun passed through disk?
Are all of below steps mandatory? OR may I omit either step 3 of 4?
1. online resize on storage side.
2. scsi rescan to realize the capacity change on hypervisor side.
3. block_resize via qmp.
4. scsi rescan to realize the capacity change in guest.
5. use the extended disk space in guest.

Many thanks,
Lin