Bug 1754822
| Summary: | [virtio-win][viostor] Add TRIM support. | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Vadim Rozenfeld <vrozenfe> | |
| Component: | virtio-win | Assignee: | Vadim Rozenfeld <vrozenfe> | |
| virtio-win sub component: | virtio-win-prewhql | QA Contact: | Yu Wang <wyu> | |
| Status: | CLOSED ERRATA | Docs Contact: | ||
| Severity: | low | |||
| Priority: | unspecified | CC: | ailan, jamshaid, kanderso, knoel, lijin, mdean, phou, qinwang, wyu | |
| Version: | 8.1 | Keywords: | RFE | |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
|
| Target Release: | 8.0 | |||
| Hardware: | Unspecified | |||
| OS: | Windows | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1779875 (view as bug list) | Environment: | ||
| Last Closed: | 2020-02-04 12:27:28 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1779875 | |||
| Attachments: | ||||
|
Description
Vadim Rozenfeld
2019-09-24 07:52:08 UTC
The problem should be fixed in build 172 Reproduce this with virtio-win-prewhql-171, and verified with virtio-win-prewhql-172 on Win10-32 and win8.1-64 Steps as comment#0 Above all, this bug is fixed, so change status to verified, and have added a case for this scenario. Thanks Yu Wang Hi Vadim, I found that there is no "defrag.exe /l" command for windows7 and win2008R2, so we cannot test this case for win7 and 2008/2008r2 guests, am I right? Thanks Yu Wang (In reply to Yu Wang from comment #5) > Hi Vadim, > > I found that there is no "defrag.exe /l" command for windows7 and win2008R2, > so we cannot test this case for win7 and 2008/2008r2 guests, am I right? > > Thanks > Yu Wang Sorry, pls ignore my comment, it is already wrote in comment#0 Hi Vadim, I have a doubt, when I test with qemu-kvm-rhev on rhel7 or rhel8 slowtrain, it shows "not supported by the hardware backing the volume(ox8900002A)" when using defrag.exe in guest, so this function cannot support on rhel7 and rhel8 slowtrain, only support on rhel8 fast-trian, right? And it can boot with "trim" params on rhel7/rhel8 slowtrain without any error. Thanks Yu Wang (In reply to Yu Wang from comment #7) > Hi Vadim, > > I have a doubt, when I test with qemu-kvm-rhev on rhel7 or rhel8 slowtrain, > it shows "not supported by the hardware backing the volume(ox8900002A)" when > using defrag.exe in guest, so this function cannot support on rhel7 and > rhel8 slowtrain, only support on rhel8 fast-trian, right? > And it can boot with "trim" params on rhel7/rhel8 slowtrain without any > error. > > > Thanks > Yu Wang Hi Yu Wang, I think that the best way to check if trim is supported by qemu is checking with "info qtree" qemu monitor command if virtio-blk-device has "discard" feature and it is turned to true. 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/RHEA-2020:0351 Hi Vadim,
If qemu 4.0 supports discards when using virtio-scsi? I see this bug is only for virtio-blk.
I tested with virtio-scsi device, commands as:
-device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x4 \
-blockdev node-name=file_image1,driver=file,aio=threads,filename=/home/kvm_autotest_root/images/win10-64-virtio-scsi.qcow2,cache.direct=on,cache.no-flush=off \
-blockdev node-name=drive_image1,driver=qcow2,cache.direct=on,cache.no-flush=off,file=file_image1 \
-device scsi-hd,id=image1,drive=drive_image1,write-cache=on \
-blockdev node-name=file_data1,driver=file,aio=threads,filename=disk1.qcow2,cache.direct=on,cache.no-flush=off,discard=unmap \
-blockdev node-name=drive_data1,driver=qcow2,cache.direct=on,cache.no-flush=off,file=file_data1,discard=unmap \
-device scsi-hd,id=data1,drive=drive_data1,write-cache=on \
Checked 'info qtree', no discard=True shown under dev: scsi-hd, id "data1".
If it mean discards is not supported when using virtio-scsi?
Thanks a lot~
Peixiu
The current bug is for viostor (virtio-blk) driver, because it needed some pice of code that propagates trim request properly from file system to back-end. virtio-scsi does support trim natively at qemu level. No need in any special handler in vioscsi driver, because the driver just by-pass the trim request to qemu directly. Best, Vadim. (In reply to Vadim Rozenfeld from comment #13) > The current bug is for viostor (virtio-blk) driver, because it needed some > pice of code that propagates trim > request properly from file system to back-end. > > virtio-scsi does support trim natively at qemu level. No need in any special > handler in vioscsi driver, because > the driver just by-pass the trim request to qemu directly. > Ok, got it, thanks a lot~ Best Regards~ Peixiu > > Best, > Vadim. Hi This problem still exist in Virtio-win-0.1.189-1 Windows 10/2k19 wont run Trimming on virtio-blk based drives I am using QEMU emulator version 5.0.93, And yes qemu support discard. Fstrim works on Centos 7/8 Virtual machines with kernel 5.x on virtio-blk drives. (In reply to jamshaid from comment #15) > Hi > > This problem still exist in Virtio-win-0.1.189-1 > > Windows 10/2k19 wont run Trimming on virtio-blk based drives > > I am using QEMU emulator version 5.0.93, And yes qemu support discard. > Fstrim works on Centos 7/8 Virtual machines with kernel 5.x on virtio-blk > drives. Do you mean that after running defrag.exe successfully, "du -h" is still giving you the same size as before? I mean running below command in power shell gives error Optimize-Volume -DriveLetter c -ReTrim -Verbose The volume optimization operation requested is not supported by the hardware backing the volume (In reply to jamshaid from comment #17) > I mean running below command in power shell gives error > > Optimize-Volume -DriveLetter c -ReTrim -Verbose > > The volume optimization operation requested is not supported by the hardware > backing the volume Does Windows recognize drive C: as a thin provisioning drive? (In reply to Vadim Rozenfeld from comment #18) > (In reply to jamshaid from comment #17) > > I mean running below command in power shell gives error > > > > Optimize-Volume -DriveLetter c -ReTrim -Verbose > > > > The volume optimization operation requested is not supported by the hardware > > backing the volume > > Does Windows recognize drive C: as a thin provisioning drive? sure thats the drive windows is booted on. if i switch to virtio-scsi in VM config and reboot, then same command can successfully run and reclaim the space. But not with virtio-blk Created attachment 1711453 [details]
virtio-blk error screenshot
Thats the error message for virtio-blk based drive on windows 10
Created attachment 1711454 [details]
virtio-scsi succesfull Trimming of same virtual machine
Thats the successful Trimming of virtio-scsi drive in same vm which fail to trim if vm is booted on virtio-blk
(In reply to jamshaid from comment #19) > (In reply to Vadim Rozenfeld from comment #18) > > (In reply to jamshaid from comment #17) > > > I mean running below command in power shell gives error > > > > > > Optimize-Volume -DriveLetter c -ReTrim -Verbose > > > > > > The volume optimization operation requested is not supported by the hardware > > > backing the volume > > > > Does Windows recognize drive C: as a thin provisioning drive? > > sure thats the drive windows is booted on. > if i switch to virtio-scsi in VM config and reboot, then same command can > successfully run and reclaim the space. > But not with virtio-blk Can you please run "Defragment and Optimize Drives" application and check that Drive "(C:)" has a media type "Thin provisioned drive" ? I've just tried viostor driver from build 189 on Win10 (2004) 32bit version, qemu version 5.0.50 and it seems to be working fine. As the next step, I'm going to update my qemu to the latest upstream version and check trimming support on WS2019. (In reply to Vadim Rozenfeld from comment #22) > (In reply to jamshaid from comment #19) > > (In reply to Vadim Rozenfeld from comment #18) > > > (In reply to jamshaid from comment #17) > > > > I mean running below command in power shell gives error > > > > > > > > Optimize-Volume -DriveLetter c -ReTrim -Verbose > > > > > > > > The volume optimization operation requested is not supported by the hardware > > > > backing the volume > > > > > > Does Windows recognize drive C: as a thin provisioning drive? > > > > sure thats the drive windows is booted on. > > if i switch to virtio-scsi in VM config and reboot, then same command can > > successfully run and reclaim the space. > > But not with virtio-blk > > Can you please run "Defragment and Optimize Drives" application and check > that Drive > "(C:)" has a media type "Thin provisioned drive" ? > I've just tried viostor driver from build 189 on Win10 (2004) 32bit version, > qemu > version 5.0.50 and it seems to be working fine. > As the next step, I'm going to update my qemu to the latest upstream version > and > check trimming support on WS2019. Thanks for looking in to this. For virtio-blk "Defragment and optimize Drives" dont show it as Thin provisioned drive. But for virtio-scsi it show same drive as Thin provisioned. Here is some more information, i will also attach screenshots with more detail. - Windows 10 Pro (Version 10.0.19041 Build 19041) 64 Bit - Tested with both Qemu 5.0.0 and Qemu 5.0.93 - Storage is a Ceph based network storage, so Qemu is compiled with --enable-rbd - virtio-win-0.1.189 #Here is disk configuration when i boot vm on virtio-blk <disk type='network' device='disk'> <source protocol='rbd' name='xxx/xxxxxxxx'> </source> <auth username='xxxxxx'> <secret type='ceph' uuid='xxxxx-xxxx-xxxx-xxxx'/> </auth> <target dev='vda' bus='virtio'/> </disk> #Thats the disk configuration for virtio-scsi <disk type='network' device='disk'> <source protocol='rbd' name='xxx/xxxxxxxx'> </source> <auth username='xxxxxxx'> <secret type='ceph' uuid='xxxxx-xxxx-xxxx-xxxx'/> </auth> <target dev='sda' bus='scsi'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <controller type='scsi' index='0' model='virtio-scsi'/> # (Just for general information) How do i switch same Virtual machine from virtio-blk to virtio-scsi is like this - Make sure all virtio drivers are installed - Open an elevated command prompt and set the VM to boot into safe mode by typing..... bcdedit /set {current} safeboot minimal - shut-down the VM and change the boot device type to virtio-scsi in vm config file - boot the VM. It will enter in safe mode. - Execute this command in elevated command prompt to disable safe mode.... bcdedit /deletevalue {current} safeboot - reboot , it will boot normally on virtio-scsi Created attachment 1711496 [details]
virtio-blk failure to detect ceph storage as thin provisioned
Thats the screen shot of complete information mentioned earilier
When booted on virtio-blk device windows wont detect the drive as Thin provisioned
Created attachment 1711497 [details]
virtio-scsi detecting ceph storage as Thin provisioned
Thats the screen shot of complete information mentioned earilier
When booted on virtio-scsi drive windows detect the drive as Thin provisioned
(In reply to jamshaid from comment #23) > (In reply to Vadim Rozenfeld from comment #22) > > (In reply to jamshaid from comment #19) > > > (In reply to Vadim Rozenfeld from comment #18) > > > > (In reply to jamshaid from comment #17) > > > > > I mean running below command in power shell gives error > > > > > > > > > > Optimize-Volume -DriveLetter c -ReTrim -Verbose > > > > > > > > > > The volume optimization operation requested is not supported by the hardware > > > > > backing the volume > > > > > > > > Does Windows recognize drive C: as a thin provisioning drive? > > > > > > sure thats the drive windows is booted on. > > > if i switch to virtio-scsi in VM config and reboot, then same command can > > > successfully run and reclaim the space. > > > But not with virtio-blk > > > > Can you please run "Defragment and Optimize Drives" application and check > > that Drive > > "(C:)" has a media type "Thin provisioned drive" ? > > I've just tried viostor driver from build 189 on Win10 (2004) 32bit version, > > qemu > > version 5.0.50 and it seems to be working fine. > > As the next step, I'm going to update my qemu to the latest upstream version > > and > > check trimming support on WS2019. > > > Thanks for looking in to this. > For virtio-blk "Defragment and optimize Drives" dont show it as Thin > provisioned drive. > But for virtio-scsi it show same drive as Thin provisioned. > > It is a storage controller's function to to let Windows know if it can or can not support trimming (discard/unmap) functionality. Storage controller does it by reporting VPD_LOGICAL_BLOCK_PROVISIONING VPD viostor does it only if VIRTIO_BLK_F_DISCARD bit was set on by QEMU https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/viostor/virtio_stor.c#L1426 You can try running "info qtree" command from qemu monitor and check if "discard" property for your virtio-blk-device is equal to "true". Alternatively, you can run Windows port of sg3 utilities and check if VPD_LOGICAL_BLOCK_PROVISIONING (0xB2) VPD page reported as supported. I tried WS2019 on QEMU 5.1.0 and it seems to be Working fine. my QEMU command line is as below: #viostor boot sudo $QEMU -cpu host$FLGS -m 2G -smp 4,maxcpus=4,cores=4,threads=1,sockets=1 -usb -device usb-tablet,id=tablet0 -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,mac=24:3A:40:3F:2F:13,id=net0 -boot c -uuid 5b959a71-e33f-4419-97b4-da6fe8fb7062 -rtc driftfix=slew -global kvm-pit.lost_tick_policy=discard -monitor stdio -name 2004 -enable-kvm -device VGA -no-hpet -object iothread,id=iothread0 -device virtio-blk-pci,id=blk-virtio1,iothread=iothread0,num-queues=4,packed=off,scsi=off,drive=drive-virtio1,config-wce=off,bootindex=1 -drive file=$IMG,if=none,media=disk,format=qcow2,rerror=stop,werror=stop,readonly=off,cache=none,aio=native,id=drive-virtio1 BTW, for old qemu versions it was required to specify discard explicitly (discard=unmap): -drive file=$DSK,if=none,media=disk,rerror=stop,werror=stop,readonly=off,cache=none,aio=native,id=drive-hotadd,discard=unmap > Here is some more information, i will also attach screenshots with more > detail. > > - Windows 10 Pro (Version 10.0.19041 Build 19041) 64 Bit > - Tested with both Qemu 5.0.0 and Qemu 5.0.93 > - Storage is a Ceph based network storage, so Qemu is compiled with > --enable-rbd > - virtio-win-0.1.189 > > #Here is disk configuration when i boot vm on virtio-blk > > <disk type='network' device='disk'> > <source protocol='rbd' name='xxx/xxxxxxxx'> > </source> > <auth username='xxxxxx'> > <secret type='ceph' uuid='xxxxx-xxxx-xxxx-xxxx'/> > </auth> > <target dev='vda' bus='virtio'/> > </disk> > > > #Thats the disk configuration for virtio-scsi > > <disk type='network' device='disk'> > <source protocol='rbd' name='xxx/xxxxxxxx'> > </source> > <auth username='xxxxxxx'> > <secret type='ceph' uuid='xxxxx-xxxx-xxxx-xxxx'/> > </auth> > <target dev='sda' bus='scsi'/> > <address type='drive' controller='0' bus='0' target='0' unit='0'/> > </disk> > <controller type='scsi' index='0' model='virtio-scsi'/> > > > > # (Just for general information) How do i switch same Virtual machine from > virtio-blk to virtio-scsi is like this > - Make sure all virtio drivers are installed > - Open an elevated command prompt and set the VM to boot into safe mode by > typing..... bcdedit /set {current} safeboot minimal > - shut-down the VM and change the boot device type to virtio-scsi in vm > config file > - boot the VM. It will enter in safe mode. > - Execute this command in elevated command prompt to disable safe mode.... > bcdedit /deletevalue {current} safeboot > - reboot , it will boot normally on virtio-scsi (In reply to Vadim Rozenfeld from comment #26) > (In reply to jamshaid from comment #23) > > (In reply to Vadim Rozenfeld from comment #22) > > > (In reply to jamshaid from comment #19) > > > > (In reply to Vadim Rozenfeld from comment #18) > > > > > (In reply to jamshaid from comment #17) > > > > > > I mean running below command in power shell gives error > > > > > > > > > > > > Optimize-Volume -DriveLetter c -ReTrim -Verbose > > > > > > > > > > > > The volume optimization operation requested is not supported by the hardware > > > > > > backing the volume > > > > > > > > > > Does Windows recognize drive C: as a thin provisioning drive? > > > > > > > > sure thats the drive windows is booted on. > > > > if i switch to virtio-scsi in VM config and reboot, then same command can > > > > successfully run and reclaim the space. > > > > But not with virtio-blk > > > > > > Can you please run "Defragment and Optimize Drives" application and check > > > that Drive > > > "(C:)" has a media type "Thin provisioned drive" ? > > > I've just tried viostor driver from build 189 on Win10 (2004) 32bit version, > > > qemu > > > version 5.0.50 and it seems to be working fine. > > > As the next step, I'm going to update my qemu to the latest upstream version > > > and > > > check trimming support on WS2019. > > > > > > Thanks for looking in to this. > > For virtio-blk "Defragment and optimize Drives" dont show it as Thin > > provisioned drive. > > But for virtio-scsi it show same drive as Thin provisioned. > > > > > > It is a storage controller's function to to let Windows know if it > can or can not support trimming (discard/unmap) functionality. > Storage controller does it by reporting VPD_LOGICAL_BLOCK_PROVISIONING VPD > > viostor does it only if VIRTIO_BLK_F_DISCARD bit was set on by QEMU > https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/viostor/ > virtio_stor.c#L1426 > > You can try running "info qtree" command from qemu monitor and check > if "discard" property for your virtio-blk-device is equal to "true". > Alternatively, you can run Windows port of sg3 utilities and check > if VPD_LOGICAL_BLOCK_PROVISIONING (0xB2) VPD page reported as supported. > > I tried WS2019 on QEMU 5.1.0 and it seems to be Working fine. > my QEMU command line is as below: > > #viostor boot > sudo $QEMU -cpu host$FLGS -m 2G -smp 4,maxcpus=4,cores=4,threads=1,sockets=1 > -usb -device usb-tablet,id=tablet0 -netdev tap,id=hostnet0 -device > e1000,netdev=hostnet0,mac=24:3A:40:3F:2F:13,id=net0 -boot c -uuid > 5b959a71-e33f-4419-97b4-da6fe8fb7062 -rtc driftfix=slew -global > kvm-pit.lost_tick_policy=discard -monitor stdio -name 2004 -enable-kvm > -device VGA -no-hpet -object iothread,id=iothread0 -device > virtio-blk-pci,id=blk-virtio1,iothread=iothread0,num-queues=4,packed=off, > scsi=off,drive=drive-virtio1,config-wce=off,bootindex=1 -drive > file=$IMG,if=none,media=disk,format=qcow2,rerror=stop,werror=stop, > readonly=off,cache=none,aio=native,id=drive-virtio1 > > BTW, for old qemu versions it was required to specify discard explicitly > (discard=unmap): > -drive > file=$DSK,if=none,media=disk,rerror=stop,werror=stop,readonly=off,cache=none, > aio=native,id=drive-hotadd,discard=unmap > > > > Here is some more information, i will also attach screenshots with more > > detail. > > > > - Windows 10 Pro (Version 10.0.19041 Build 19041) 64 Bit > > - Tested with both Qemu 5.0.0 and Qemu 5.0.93 > > - Storage is a Ceph based network storage, so Qemu is compiled with > > --enable-rbd > > - virtio-win-0.1.189 > > > > #Here is disk configuration when i boot vm on virtio-blk > > > > <disk type='network' device='disk'> > > <source protocol='rbd' name='xxx/xxxxxxxx'> > > </source> > > <auth username='xxxxxx'> > > <secret type='ceph' uuid='xxxxx-xxxx-xxxx-xxxx'/> > > </auth> > > <target dev='vda' bus='virtio'/> > > </disk> > > > > > > #Thats the disk configuration for virtio-scsi > > > > <disk type='network' device='disk'> > > <source protocol='rbd' name='xxx/xxxxxxxx'> > > </source> > > <auth username='xxxxxxx'> > > <secret type='ceph' uuid='xxxxx-xxxx-xxxx-xxxx'/> > > </auth> > > <target dev='sda' bus='scsi'/> > > <address type='drive' controller='0' bus='0' target='0' unit='0'/> > > </disk> > > <controller type='scsi' index='0' model='virtio-scsi'/> > > > > > > > > # (Just for general information) How do i switch same Virtual machine from > > virtio-blk to virtio-scsi is like this > > - Make sure all virtio drivers are installed > > - Open an elevated command prompt and set the VM to boot into safe mode by > > typing..... bcdedit /set {current} safeboot minimal > > - shut-down the VM and change the boot device type to virtio-scsi in vm > > config file > > - boot the VM. It will enter in safe mode. > > - Execute this command in elevated command prompt to disable safe mode.... > > bcdedit /deletevalue {current} safeboot > > - reboot , it will boot normally on virtio-scsi Thanks for your kind effort to help us resolve it. As you suggested i checked with qemu-monitor and you were right. it was showing .... discard = false I further dig it out and it seems i was using machine type pc-i440fx-3.0 if i switch it to machine type pc-i440fx-5.0, It worked. So the problem was pc-i440fx-3.0 as machine type in VM config. I am not sure if that is considered as a Bug or not, but anyway for now our problem is solved. Thanks to you. To switch from pc-i440fx-3.0 to pc-i440fx-5.0 i had to sacrifice below two features <synic state='on'/> <stimer state='on'/> The qemu-monitor command i used to fetch info was virsh qemu-monitor-command --hmp XXX-VMID-XXX 'info qtree' | grep discard (In reply to jamshaid from comment #27) > (In reply to Vadim Rozenfeld from comment #26) > > (In reply to jamshaid from comment #23) > Thanks for your kind effort to help us resolve it. > As you suggested i checked with qemu-monitor and you were right. it was > showing .... > discard = false > > I further dig it out and it seems i was using machine type pc-i440fx-3.0 > if i switch it to machine type pc-i440fx-5.0, It worked. > > So the problem was pc-i440fx-3.0 as machine type in VM config. > I am not sure if that is considered as a Bug or not, but anyway for now our > problem is solved. Thanks to you. > This is not a bug, but rather a feature that technically should simplify VM migration. In any case, glad to know that the problem was solved. (In reply to jamshaid from comment #27) > (In reply to Vadim Rozenfeld from comment #26) > > (In reply to jamshaid from comment #23) > > > (In reply to Vadim Rozenfeld from comment #22) > > > > (In reply to jamshaid from comment #19) > > > > > (In reply to Vadim Rozenfeld from comment #18) > > > > > > (In reply to jamshaid from comment #17) > > > > > > > I mean running below command in power shell gives error > > > > > > > > > > > > > > Optimize-Volume -DriveLetter c -ReTrim -Verbose > > > > > > > > > > > > > > The volume optimization operation requested is not supported by the hardware > > > > > > > backing the volume > > > > > > > > > > > > Does Windows recognize drive C: as a thin provisioning drive? > > > > > > > > > > sure thats the drive windows is booted on. > > > > > if i switch to virtio-scsi in VM config and reboot, then same command can > > > > > successfully run and reclaim the space. > > > > > But not with virtio-blk > > > > > > > > Can you please run "Defragment and Optimize Drives" application and check > > > > that Drive > > > > "(C:)" has a media type "Thin provisioned drive" ? > > > > I've just tried viostor driver from build 189 on Win10 (2004) 32bit version, > > > > qemu > > > > version 5.0.50 and it seems to be working fine. > > > > As the next step, I'm going to update my qemu to the latest upstream version > > > > and > > > > check trimming support on WS2019. > > > > > > > > > Thanks for looking in to this. > > > For virtio-blk "Defragment and optimize Drives" dont show it as Thin > > > provisioned drive. > > > But for virtio-scsi it show same drive as Thin provisioned. > > > > > > > > > > It is a storage controller's function to to let Windows know if it > > can or can not support trimming (discard/unmap) functionality. > > Storage controller does it by reporting VPD_LOGICAL_BLOCK_PROVISIONING VPD > > > > viostor does it only if VIRTIO_BLK_F_DISCARD bit was set on by QEMU > > https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/viostor/ > > virtio_stor.c#L1426 > > > > You can try running "info qtree" command from qemu monitor and check > > if "discard" property for your virtio-blk-device is equal to "true". > > Alternatively, you can run Windows port of sg3 utilities and check > > if VPD_LOGICAL_BLOCK_PROVISIONING (0xB2) VPD page reported as supported. > > > > I tried WS2019 on QEMU 5.1.0 and it seems to be Working fine. > > my QEMU command line is as below: > > > > #viostor boot > > sudo $QEMU -cpu host$FLGS -m 2G -smp 4,maxcpus=4,cores=4,threads=1,sockets=1 > > -usb -device usb-tablet,id=tablet0 -netdev tap,id=hostnet0 -device > > e1000,netdev=hostnet0,mac=24:3A:40:3F:2F:13,id=net0 -boot c -uuid > > 5b959a71-e33f-4419-97b4-da6fe8fb7062 -rtc driftfix=slew -global > > kvm-pit.lost_tick_policy=discard -monitor stdio -name 2004 -enable-kvm > > -device VGA -no-hpet -object iothread,id=iothread0 -device > > virtio-blk-pci,id=blk-virtio1,iothread=iothread0,num-queues=4,packed=off, > > scsi=off,drive=drive-virtio1,config-wce=off,bootindex=1 -drive > > file=$IMG,if=none,media=disk,format=qcow2,rerror=stop,werror=stop, > > readonly=off,cache=none,aio=native,id=drive-virtio1 > > > > BTW, for old qemu versions it was required to specify discard explicitly > > (discard=unmap): > > -drive > > file=$DSK,if=none,media=disk,rerror=stop,werror=stop,readonly=off,cache=none, > > aio=native,id=drive-hotadd,discard=unmap > > > > > > > Here is some more information, i will also attach screenshots with more > > > detail. > > > > > > - Windows 10 Pro (Version 10.0.19041 Build 19041) 64 Bit > > > - Tested with both Qemu 5.0.0 and Qemu 5.0.93 > > > - Storage is a Ceph based network storage, so Qemu is compiled with > > > --enable-rbd > > > - virtio-win-0.1.189 > > > > > > #Here is disk configuration when i boot vm on virtio-blk > > > > > > <disk type='network' device='disk'> > > > <source protocol='rbd' name='xxx/xxxxxxxx'> > > > </source> > > > <auth username='xxxxxx'> > > > <secret type='ceph' uuid='xxxxx-xxxx-xxxx-xxxx'/> > > > </auth> > > > <target dev='vda' bus='virtio'/> > > > </disk> > > > > > > > > > #Thats the disk configuration for virtio-scsi > > > > > > <disk type='network' device='disk'> > > > <source protocol='rbd' name='xxx/xxxxxxxx'> > > > </source> > > > <auth username='xxxxxxx'> > > > <secret type='ceph' uuid='xxxxx-xxxx-xxxx-xxxx'/> > > > </auth> > > > <target dev='sda' bus='scsi'/> > > > <address type='drive' controller='0' bus='0' target='0' unit='0'/> > > > </disk> > > > <controller type='scsi' index='0' model='virtio-scsi'/> > > > > > > > > > > > > # (Just for general information) How do i switch same Virtual machine from > > > virtio-blk to virtio-scsi is like this > > > - Make sure all virtio drivers are installed > > > - Open an elevated command prompt and set the VM to boot into safe mode by > > > typing..... bcdedit /set {current} safeboot minimal > > > - shut-down the VM and change the boot device type to virtio-scsi in vm > > > config file > > > - boot the VM. It will enter in safe mode. > > > - Execute this command in elevated command prompt to disable safe mode.... > > > bcdedit /deletevalue {current} safeboot > > > - reboot , it will boot normally on virtio-scsi > > Thanks for your kind effort to help us resolve it. > As you suggested i checked with qemu-monitor and you were right. it was > showing .... > discard = false > > I further dig it out and it seems i was using machine type pc-i440fx-3.0 > if i switch it to machine type pc-i440fx-5.0, It worked. > > So the problem was pc-i440fx-3.0 as machine type in VM config. > I am not sure if that is considered as a Bug or not, but anyway for now our > problem is solved. Thanks to you. > > To switch from pc-i440fx-3.0 to pc-i440fx-5.0 i had to sacrifice below two > features > <synic state='on'/> > <stimer state='on'/> Just an update that a little modification in vm config as per below link can let to still use synic and stimer features with pc-i440fx-5.0 https://unix.stackexchange.com/questions/534155/win10-guests-high-kvm-host-cpu-usage > > > The qemu-monitor command i used to fetch info was > virsh qemu-monitor-command --hmp XXX-VMID-XXX 'info qtree' | grep discard |