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

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

[lma]

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

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

[Paolo Bonzini]

On 08/07/20 16:44, lma wrote:
> 
> 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?

Request start and length are checked even for passthrough disks (see
scsi_disk_dma_command in hw/scsi/scsi-disk.c, called by
scsi_block_dma_command), but the maximum LBA is snooped from READ
CAPACITY commands (see scsi_read_complete in hw/scsi/scsi-generic.c).
So as long as rescan-scsi-bus.sh results in a READ CAPACITY command, it
should work.

It's not recommended however, because block_resize will report the
change to the guest directly with a CAPACITY HAS CHANGED unit attention
condition.

Thanks,

Paolo

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

[Lin Ma]

On 2020-07-08 15:11, Paolo Bonzini wrote:
> On 08/07/20 16:44, lma wrote:
>> 
>> 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?
> 
> Request start and length are checked even for passthrough disks (see
> scsi_disk_dma_command in hw/scsi/scsi-disk.c, called by
> scsi_block_dma_command), but the maximum LBA is snooped from READ
> CAPACITY commands (see scsi_read_complete in hw/scsi/scsi-generic.c).
> So as long as rescan-scsi-bus.sh results in a READ CAPACITY command, it
> should work.

Yeah, the rescan-scsi-bus.sh does result in a READ CAPACITY command.

> It's not recommended however, because block_resize will report the
> change to the guest directly with a CAPACITY HAS CHANGED unit attention
> condition.

Got it, The 'block_resize' is the recommended or necessary step, Even 
for
passthrough disk online resizing.

Thanks for your information,
Lin

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

[Paolo Bonzini]

On 09/07/20 13:52, Lin Ma wrote:
>> It's not recommended however, because block_resize will report the
>> change to the guest directly with a CAPACITY HAS CHANGED unit attention
>> condition.
> 
> Got it, The 'block_resize' is the recommended or necessary step, Even for
> passthrough disk online resizing.

If your target is able to report the unit attention itself, it is okay
to skip it.  AFAIK drivers/target/ doesn't, though.

Paolo

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

[Lin Ma]

On 2020-07-09 12:00, Paolo Bonzini wrote:
> On 09/07/20 13:52, Lin Ma wrote:
>>> It's not recommended however, because block_resize will report the
>>> change to the guest directly with a CAPACITY HAS CHANGED unit 
>>> attention
>>> condition.
>> 
>> Got it, The 'block_resize' is the recommended or necessary step, Even 
>> for
>> passthrough disk online resizing.
> 
> If your target is able to report the unit attention itself, it is okay
> to skip it.  AFAIK drivers/target/ doesn't, though.

Got you.
I happen to use the drivers/target/ :-)

Thank you very much,
Lin