Bug 1518095

Hi Vadim,

Is this issue 100%?

QE can see the resized unallocated volume after step3, and can enlarge the disk.

The only step is to press refresh button,no need to rescan neither reboot guest.

Do you mean we do not need the "refresh" step at all?

(In reply to lijin from comment #2)
> Hi Vadim,
> 
> Is this issue 100%?
> 
> QE can see the resized unallocated volume after step3, and can enlarge the
> disk.
> 
> The only step is to press refresh button,no need to rescan neither reboot
> guest.
> 
> Do you mean we do not need the "refresh" step at all?

Storport miniport driver needs to notify OS that some changes have happened (it's what we already do) and then make sure that OS can recognise and handle these changes automatically. Most likely that Windows will not perform partition resizing immediately after getting such notification but it should be do it on a first write request after resizing. Try to check how it works with virtio-scsi,
just resize the disk and then copy a file to this disk, without running manual rescan first. virtio-scsi should be able to handle resize automatically, so virtio-blk should be able to operate the same way.

Merged upstream:
https://github.com/virtio-win/kvm-guest-drivers-windows/commit/daa82e93d7525b751f54ff474c514cfb8683df91

Please give a try to build 145 https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=629923.

Thanks,
Vadim.

(In reply to Vadim Rozenfeld from comment #5)
> Please give a try to build 145
> https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=629923.
> 
> Thanks,
> Vadim.

Virtio-scsi and virtio-blk work in the same way. Resize the disk and then copy a file to this disk, after that need click "refresh" in disk management to get the resized value. 

And build 143 and 145 have the same behavior,so I don't know how to verify this bug.

Could you tell me how to reproduce in old build and how to verify in the latest build?



Detailed steps:
1) start a windows guest with virtio-blk disk(1G) and virtio-scsi disk(1G).
-drive file=my_data_disk.raw,if=none,id=data_drive,format=raw,aio=native,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=data_drive,id=blk_data \
-device virtio-scsi-pci,id=scsi1,bus=pci.0,num_queues=4 -drive file=disk111.raw,if=none,id=drive-scsi-disk1,format=raw,cache=none,aio=native,werror=stop,rerror=stop,discard=on -device scsi-hd,drive=drive-scsi-disk1,bus=scsi1.0,id=scsi-disk1

2)create volume on the two disks

3)change them to 5G
(qemu) block_resize data_drive 5G
(qemu) block_resize drive-scsi-disk1 5G

4)copy file to the two disks

5)check them in "Disk Management"

6)click "refresh" button in "Disk Management"

Results:
after step 5),their size is still 1G
after step 6),their size is 5G

(In reply to xiagao from comment #6)
> (In reply to Vadim Rozenfeld from comment #5)
> > Please give a try to build 145
> > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=629923.
> > 
> > Thanks,
> > Vadim.
> 
> Virtio-scsi and virtio-blk work in the same way. Resize the disk and then
> copy a file to this disk, after that need click "refresh" in disk management
> to get the resized value. 
> 
> And build 143 and 145 have the same behavior,so I don't know how to verify
> this bug.
> 
> Could you tell me how to reproduce in old build and how to verify in the
> latest build?
> 
> 
> 
> Detailed steps:
> 1) start a windows guest with virtio-blk disk(1G) and virtio-scsi disk(1G).
> -drive
> file=my_data_disk.raw,if=none,id=data_drive,format=raw,aio=native,cache=none,
> werror=stop,rerror=stop -device virtio-blk-pci,drive=data_drive,id=blk_data \
> -device virtio-scsi-pci,id=scsi1,bus=pci.0,num_queues=4 -drive
> file=disk111.raw,if=none,id=drive-scsi-disk1,format=raw,cache=none,
> aio=native,werror=stop,rerror=stop,discard=on -device
> scsi-hd,drive=drive-scsi-disk1,bus=scsi1.0,id=scsi-disk1
> 
> 2)create volume on the two disks
> 
> 3)change them to 5G
> (qemu) block_resize data_drive 5G
> (qemu) block_resize drive-scsi-disk1 5G
> 
> 4)copy file to the two disks
> 
> 5)check them in "Disk Management"
> 
> 6)click "refresh" button in "Disk Management"
> 
> Results:
> after step 5),their size is still 1G
> after step 6),their size is 5G

Thanks, 
I will recheck it shortly. 
What is your guest version?
Vadim.

(In reply to Vadim Rozenfeld from comment #7)
> (In reply to xiagao from comment #6)
> > (In reply to Vadim Rozenfeld from comment #5)
> > > Please give a try to build 145
> > > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=629923.
> > > 
> > > Thanks,
> > > Vadim.
> > 
> > Virtio-scsi and virtio-blk work in the same way. Resize the disk and then
> > copy a file to this disk, after that need click "refresh" in disk management
> > to get the resized value. 
> > 
> > And build 143 and 145 have the same behavior,so I don't know how to verify
> > this bug.
> > 
> > Could you tell me how to reproduce in old build and how to verify in the
> > latest build?
> > 
> > 
> > 
> > Detailed steps:
> > 1) start a windows guest with virtio-blk disk(1G) and virtio-scsi disk(1G).
> > -drive
> > file=my_data_disk.raw,if=none,id=data_drive,format=raw,aio=native,cache=none,
> > werror=stop,rerror=stop -device virtio-blk-pci,drive=data_drive,id=blk_data \
> > -device virtio-scsi-pci,id=scsi1,bus=pci.0,num_queues=4 -drive
> > file=disk111.raw,if=none,id=drive-scsi-disk1,format=raw,cache=none,
> > aio=native,werror=stop,rerror=stop,discard=on -device
> > scsi-hd,drive=drive-scsi-disk1,bus=scsi1.0,id=scsi-disk1
> > 
> > 2)create volume on the two disks
> > 
> > 3)change them to 5G
> > (qemu) block_resize data_drive 5G
> > (qemu) block_resize drive-scsi-disk1 5G
> > 
> > 4)copy file to the two disks
> > 
> > 5)check them in "Disk Management"
> > 
> > 6)click "refresh" button in "Disk Management"
> > 
> > Results:
> > after step 5),their size is still 1G
> > after step 6),their size is 5G
> 
> Thanks, 
> I will recheck it shortly. 
> What is your guest version?
> Vadim.

I tried win2008-64 and win832.

(In reply to xiagao from comment #8)
> (In reply to Vadim Rozenfeld from comment #7)
> > (In reply to xiagao from comment #6)
> > > (In reply to Vadim Rozenfeld from comment #5)
> > > > Please give a try to build 145
> > > > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=629923.
> > > > 
> > > > Thanks,
> > > > Vadim.
> > > 
> > > Virtio-scsi and virtio-blk work in the same way. Resize the disk and then
> > > copy a file to this disk, after that need click "refresh" in disk management
> > > to get the resized value. 
> > > 
> > > And build 143 and 145 have the same behavior,so I don't know how to verify
> > > this bug.
> > > 
> > > Could you tell me how to reproduce in old build and how to verify in the
> > > latest build?
> > > 
> > > 
> > > 
> > > Detailed steps:
> > > 1) start a windows guest with virtio-blk disk(1G) and virtio-scsi disk(1G).
> > > -drive
> > > file=my_data_disk.raw,if=none,id=data_drive,format=raw,aio=native,cache=none,
> > > werror=stop,rerror=stop -device virtio-blk-pci,drive=data_drive,id=blk_data \
> > > -device virtio-scsi-pci,id=scsi1,bus=pci.0,num_queues=4 -drive
> > > file=disk111.raw,if=none,id=drive-scsi-disk1,format=raw,cache=none,
> > > aio=native,werror=stop,rerror=stop,discard=on -device
> > > scsi-hd,drive=drive-scsi-disk1,bus=scsi1.0,id=scsi-disk1
> > > 
> > > 2)create volume on the two disks
> > > 
> > > 3)change them to 5G
> > > (qemu) block_resize data_drive 5G
> > > (qemu) block_resize drive-scsi-disk1 5G
> > > 
> > > 4)copy file to the two disks
> > > 
> > > 5)check them in "Disk Management"
> > > 
> > > 6)click "refresh" button in "Disk Management"
> > > 
> > > Results:
> > > after step 5),their size is still 1G
> > > after step 6),their size is 5G
> > 
> > Thanks, 
> > I will recheck it shortly. 
> > What is your guest version?
> > Vadim.
> 
> I tried win2008-64 and win832.

This is what I see on my Win8/32 system:
I have two data disks attached just as you said:

data_drive (#block387): /home/vrozenfe/work/images/disk1.qcow2 (qcow2)
    Attached to:      /machine/peripheral/blk_data/virtio-backend
    Cache mode:       writeback, direct

drive-scsi-disk1 (#block586): /home/vrozenfe/work/images/disk2.qcow2 (qcow2)
    Attached to:      scsi-disk1
    Cache mode:       writeback, direct

I have Disk Management Dialog and command prompt (cmd.exe) running.
Now, with drivers from build 143 installed (both viostor and vioscsi):
1. I'm resizing both disks from qemu monitor. 
2. Disk Management keeps displaying the same disks' size as before
3. In command prompt console I copy a file to disk D: (virtio-blk), but nothing happens. The disk size didn't change.
4. I copy a file to disk E: (virtio-scsi), the disk size has changed automatically, without running rescan.
5. The only way to see changes on disk D: is to run rescan or refresh manually.

With drivers from build 145 installed (both viostor and vioscsi):
1. Vioscsi behaves exactly as in the previous case described above,
2. viostor behaves as viostor, which means it needs no manual restart or refresh to see the disk size changed after changing the disk size and running a copy operation on it.

While it looks like a quite small behavioural difference, the real improvement
between those two versions is that viostor drivers in build 145 know how report unit attention condition to the higher level of storage stack.

Hi Vadim,

Any update about this issue?

(In reply to lijin from comment #11)
> Hi Vadim,
> 
> Any update about this issue?

Hi Li Jin
I still can see the updated volume size even without manual rescan.
Trying to do more testing cycles to reproduce the problem.
However, if we started hitting any time limits, lets move this bug
to 7.6 as well.

Best regards,
Vadim.

(In reply to Vadim Rozenfeld from comment #12)
> (In reply to lijin from comment #11)
> > Hi Vadim,
> > 
> > Any update about this issue?
> 
> Hi Li Jin
> I still can see the updated volume size even without manual rescan.
> Trying to do more testing cycles to reproduce the problem.
> However, if we started hitting any time limits, lets move this bug
> to 7.6 as well.
> 

Hi Vadim,

Could you check QE's test env provided in comment10? Could you reproduce it as well?
I just want to make sure there is any misunderstanding of the reproduce steps.
Thanks a lot

Created attachment 1370707 [details]
how to check this feature

Hi Li Jin. 
I tried to reproduce the problem and log all the steps I did into this document,
I also added some screenshots for fun. Only one difference from my previous explanation is that this time I was using diskpart utility to initiate an access
to a disk instead of trying to copy a file.

All the best,
Vadim.

Hi Vadim,

Thanks a lot for the detailed docs.

I try with the same steps with you, with BOTH virtio-win-prewhql-143 and virtio-win-prewhql-145, blk and scsci BOTH can the resized volume after "list disk".

My guest is win8.1-64, I also try on upstream qemu, got the same result.

qemu cli:
/usr/local/bin/qemu-system-x86_64 \
-M pc \
-cpu host,+x2apic,family=0xf \
-enable-kvm \
-nodefaults \
-m 4G \
-smp 4 \
-nodefconfig \
-rtc base=localtime,driftfix=slew \
-drive file=win8.1-64.raw,if=none,format=raw,cache=none,werror=stop,rerror=stop,id=drive-virtio-disk0 \
-device ide-drive,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \
-device piix3-usb-uhci,id=usb \
-device usb-tablet,id=tablet0 \
-vnc 0.0.0.0:10 -vga std \
-k en-us \
-monitor stdio \
-qmp tcp:0:4444,server,nowait \
-boot menu=on \
-drive file=disk1.raw,if=none,format=raw,cache=none,aio=threads,werror=stop,rerror=stop,id=drive-virtio-disk1 \
-device virtio-blk-pci,scsi=off,drive=drive-virtio-disk1,id=virtio-disk1 \
-device virtio-scsi-pci,id=scsi0,num_queues=4 \
-drive file=disk2.raw,if=none,format=raw,cache=none,aio=threads,werror=stop,rerror=stop,discard=on,id=drive-virtio-disk2 \
-device scsi-hd,bus=scsi0.0,drive=drive-virtio-disk2,id=virtio-disk2 \

(In reply to lijin from comment #15)
> Hi Vadim,
> 
> Thanks a lot for the detailed docs.
> 
> I try with the same steps with you, with BOTH virtio-win-prewhql-143 and
> virtio-win-prewhql-145, blk and scsci BOTH can the resized volume after
> "list disk".

Hi LiJin,
just to confirm that I understand it correctly. With virtstor driver from build 143, you resize the virtio-blk attached volume, run "list disk", and it gives you 
the correct volume size. You observe exactly the same behaviour as with viostor driver from build 145, right?

Thanks,
Vadim.

(In reply to Vadim Rozenfeld from comment #16)
> (In reply to lijin from comment #15)
> > Hi Vadim,
> > 
> > Thanks a lot for the detailed docs.
> > 
> > I try with the same steps with you, with BOTH virtio-win-prewhql-143 and
> > virtio-win-prewhql-145, blk and scsci BOTH can the resized volume after
> > "list disk".
> 
> Hi LiJin,
> just to confirm that I understand it correctly. With virtstor driver from
> build 143, you resize the virtio-blk attached volume, run "list disk", and
> it gives you 
> the correct volume size. You observe exactly the same behaviour as with
> viostor driver from build 145, right?

Sorry for missing this comment.
Yes, 143 behaves exactly same with build 145.

(In reply to lijin from comment #17)
> (In reply to Vadim Rozenfeld from comment #16)
> > (In reply to lijin from comment #15)
> > > Hi Vadim,
> > > 
> > > Thanks a lot for the detailed docs.
> > > 
> > > I try with the same steps with you, with BOTH virtio-win-prewhql-143 and
> > > virtio-win-prewhql-145, blk and scsci BOTH can the resized volume after
> > > "list disk".
> > 
> > Hi LiJin,
> > just to confirm that I understand it correctly. With virtstor driver from
> > build 143, you resize the virtio-blk attached volume, run "list disk", and
> > it gives you 
> > the correct volume size. You observe exactly the same behaviour as with
> > viostor driver from build 145, right?
> 
> Sorry for missing this comment.
> Yes, 143 behaves exactly same with build 145.

Thanks LiJin,
Can you please specify guest version/kernel build number as well as qemu version?
Thanks,
Vadim.

windows guest:
win8.1-64:
version:6.3.9600
iso:en_windows_8.1_enterprise_with_update_x64_dvd_6054382.iso
qemu-kvm-rhev-2.10.0-13.el7.x86_64
kernel-3.10.0-823.el7.x86_64
seabios-bin-1.11.0-1.el7.noarch

(In reply to lijin from comment #19)
> windows guest:
> win8.1-64:
> version:6.3.9600
> iso:en_windows_8.1_enterprise_with_update_x64_dvd_6054382.iso
> qemu-kvm-rhev-2.10.0-13.el7.x86_64
> kernel-3.10.0-823.el7.x86_64
> seabios-bin-1.11.0-1.el7.noarch

Thanks a lot, Li Jin

Will it be a problem to check Win8.1 32-bit version as well?

Vadim.

(In reply to Vadim Rozenfeld from comment #20)
> (In reply to lijin from comment #19)
> > windows guest:
> > win8.1-64:
> > version:6.3.9600
> > iso:en_windows_8.1_enterprise_with_update_x64_dvd_6054382.iso
> > qemu-kvm-rhev-2.10.0-13.el7.x86_64
> > kernel-3.10.0-823.el7.x86_64
> > seabios-bin-1.11.0-1.el7.noarch
> 
> Thanks a lot, Li Jin
> 
> Will it be a problem to check Win8.1 32-bit version as well?

win8.1-32 behaves same as win8.1-64.

Anything else, please let me know.

Thanks

Hi Li Jin,
Can you please run update on your both 32 and 64-bit Windows 8.1 VMs and check it
it makes any difference ?

Thanks,
Vadim.

(In reply to Vadim Rozenfeld from comment #25)
> Hi Li Jin,
> Can you please run update on your both 32 and 64-bit Windows 8.1 VMs and
> check it
> it makes any difference ?

I re-install a new image with latest win8.1-32 iso and do windows update after installation, then try to reproduce this issue.

I CAN reproduce it with build 143 now.
And with build 145, this issue is gone. 

I think we can change it to verified.

Thanks very much, Vadim.

(In reply to lijin from comment #26)
> (In reply to Vadim Rozenfeld from comment #25)
> > Hi Li Jin,
> > Can you please run update on your both 32 and 64-bit Windows 8.1 VMs and
> > check it
> > it makes any difference ?
> 
> I re-install a new image with latest win8.1-32 iso and do windows update
> after installation, then try to reproduce this issue.
> 
> I CAN reproduce it with build 143 now.
> And with build 145, this issue is gone. 
> 
> I think we can change it to verified.
> 
> Thanks very much, Vadim.

Thanks a lot Li Jin.
I truly appreciate your effort.

Best regards,
Vadim.

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-2018:0657

Hi Vadim,

I'm testing blk cases on win2008-64 recently and found that online block_resize does not work well on it.

The win2008-64 version I used is Build 6002, should be the latest. And I also install windows update, but it does not help. I downgrade to build 145, both scsi and blk not work.

I still need to do "refresh" step to see disk is increased.

Our QE found it doesn't work on win7-32 as well. So I'd like to confirm with you that is it normal? Does this feature only work for newer windows guests?

(In reply to lijin from comment #30)
> Hi Vadim,
> 
> I'm testing blk cases on win2008-64 recently and found that online
> block_resize does not work well on it.
> 
> The win2008-64 version I used is Build 6002, should be the latest. And I
> also install windows update, but it does not help. I downgrade to build 145,
> both scsi and blk not work.
> 
> I still need to do "refresh" step to see disk is increased.
> 
> Our QE found it doesn't work on win7-32 as well. So I'd like to confirm with
> you that is it normal? Does this feature only work for newer windows guests?

You should be able to see changes when reading from or writing to the resized volume. Here is how it works - the driver triggers the event of resizing the volume, but cannot notify the class driver about this, until some other component tries to run read or write IO request. Then driver can complete this request with status, saying that media geometry has been changed.

(In reply to Vadim Rozenfeld from comment #31)
> (In reply to lijin from comment #30)
> > Hi Vadim,
> > 
> > I'm testing blk cases on win2008-64 recently and found that online
> > block_resize does not work well on it.
> > 
> > The win2008-64 version I used is Build 6002, should be the latest. And I
> > also install windows update, but it does not help. I downgrade to build 145,
> > both scsi and blk not work.
> > 
> > I still need to do "refresh" step to see disk is increased.
> > 
> > Our QE found it doesn't work on win7-32 as well. So I'd like to confirm with
> > you that is it normal? Does this feature only work for newer windows guests?
> 
> You should be able to see changes when reading from or writing to the
> resized volume. Here is how it works - the driver triggers the event of
> resizing the volume, but cannot notify the class driver about this, until
> some other component tries to run read or write IO request. Then driver can
> complete this request with status, saying that media geometry has been
> changed.

Here is our testing result:
win2012R2 and win10-32 work as expected;
win2008-64 and win7-32 still need refresh to see resized volume.

Should QE file a new bug for this issue?

(In reply to lijin from comment #32)
> (In reply to Vadim Rozenfeld from comment #31)
> > (In reply to lijin from comment #30)
> > > Hi Vadim,
> > > 
> > > I'm testing blk cases on win2008-64 recently and found that online
> > > block_resize does not work well on it.
> > > 
> > > The win2008-64 version I used is Build 6002, should be the latest. And I
> > > also install windows update, but it does not help. I downgrade to build 145,
> > > both scsi and blk not work.
> > > 
> > > I still need to do "refresh" step to see disk is increased.
> > > 
> > > Our QE found it doesn't work on win7-32 as well. So I'd like to confirm with
> > > you that is it normal? Does this feature only work for newer windows guests?
> > 
> > You should be able to see changes when reading from or writing to the
> > resized volume. Here is how it works - the driver triggers the event of
> > resizing the volume, but cannot notify the class driver about this, until
> > some other component tries to run read or write IO request. Then driver can
> > complete this request with status, saying that media geometry has been
> > changed.
> 
> Here is our testing result:
> win2012R2 and win10-32 work as expected;
> win2008-64 and win7-32 still need refresh to see resized volume.
> 
> Should QE file a new bug for this issue?

Hi Li Jin.
Let me check it firs. Just to be sure that we are on the same page, could you please confirm that both win2008-64 and win7-32 VMs have the latest Windows Updates installed?

Thanks,
Vadim.