virtio-win.iso was softed link to virtio-win-1.9.8.iso, details as:

[root@hp-dl385g10-17 home]# ll /usr/share/virtio-win
total 252736
drwxr-xr-x. 4 root root        31 Jun 25 10:12 drivers
drwxr-xr-x. 2 root root        56 Aug 19 04:41 guest-agent
-rw-r--r--. 1 root root 258799616 Jul  1 20:26 virtio-win-1.9.8.iso
lrwxrwxrwx. 1 root root        20 Jul  1 20:26 virtio-win.iso -> virtio-win-1.9.8.iso

>Install a guest win2019 with /usr/share/virtio-win/virtio-win.iso failed,
>but install guest win2019 with /usr/share/virtio-win/virtio-win-1.9.8.iso successfully.
...
>Additional info:
>1. Reproduced this issue on win2012 guest.
>2. Cannot reproduce this issue with virtio-win-1.9.8-6.el8

I have two theories:

1. There's a difference in the iso files packaged in virtio-win-1.9.8-6 (that works) and virtio-win-1.9.8-7 (that doesn't work).
2. The virtio-win-1.9.8.iso file is treated by Windows as a .lnk file, but the thing it points to does not exist, possibly due to a configuration error.

Reassigning for further analysis.

After some research:

virtio-win.iso is a symlink since a long time.
virtio-win.iso is a symlink in 1.9.8-7 and also 1.9.8-6.

Now, comparing both packages:
virtio-win-1.9.8-6 and virtio-win-1.9.8-7 have the same set of drivers.
The difference between them is that virtio-win-1.9.8-6 was released as supplementary, while virtio-win-1.9.8-7 was released in the regular RHEL channel.

Checking the spec file, virtio-win-1.9.8-6  and virtio-win-1.9.8-7 are built from the same source: virtio-win-1.9.8-4-bin-for-rpm.tar.gz
They are suppose to be exactly the same.

Checking both isos, 1.9.8-6 and and 1.9.8.7 have the same file set.
Even more: both isos have the same size:

1.9.8-6:
-rw-r--r-- 1 danilo danilo 258799616 Jun 26 19:31 virtio-win-1.9.8.iso
lrwxrwxrwx 1 danilo danilo        20 Aug 27 20:41 virtio-win.iso -> virtio-win-1.9.8.iso

1.9.8-7:
-rw-r--r-- 1 danilo danilo 258799616 Jul  1 21:26 virtio-win-1.9.8.iso
lrwxrwxrwx 1 danilo danilo        20 Aug 27 20:41 virtio-win.iso -> virtio-win-1.9.8.iso

Unless mkisofs got corrupted in brew's buildroot between 1.9.8-6 and 1.9.8-7 (by building a bad iso),  both images are suppose to be valid.

A quick check in both images (mounted with mkdir mount; sudo mount -o loop virtio-win.iso mount/ ) shows that they are valid and have the exactly same set of files (which is expected).

$ diff -r 1.9.8-6/usr/share/virtio-win/mount 1.9.8-7/usr/share/virtio-win/mount
$

^ this means that the content of them is the same.

My conclusion of this is that this bug is not package-related - because they are virtually the same 
We got lucky that we had to build '-7' with the same content as -6 just because of the distribution channel.

I don't know how many times OP tried to reproduce this with 1.9.8-6 (or virtio-win.iso in 1.9.8-7), but I believe OP will be able to reproduce this issue there as well.

(In reply to Jeff Nelson from comment #3)
> >Install a guest win2019 with /usr/share/virtio-win/virtio-win.iso failed,
> >but install guest win2019 with /usr/share/virtio-win/virtio-win-1.9.8.iso successfully.
> ...
> >Additional info:
> >1. Reproduced this issue on win2012 guest.
> >2. Cannot reproduce this issue with virtio-win-1.9.8-6.el8
> 
> I have two theories:
> 
> 1. There's a difference in the iso files packaged in virtio-win-1.9.8-6
> (that works) and virtio-win-1.9.8-7 (that doesn't work).
> 2. The virtio-win-1.9.8.iso file is treated by Windows as a .lnk file, but
> the thing it points to does not exist, possibly due to a configuration error.
> 
> Reassigning for further analysis.

My theory is that the drivers contains a intermittent bug.
Amnon/Jeff, in that case, who's suppose to handle this?

Maybe even qemu-kvm.

I think we need someone with windows expertise to investigate what's going on with the windows installation. Reassigning based on investigation in comment 4 and comment 5.

(In reply to Danilo Cesar de Paula from comment #4)
> After some research:
> 
> virtio-win.iso is a symlink since a long time.
> virtio-win.iso is a symlink in 1.9.8-7 and also 1.9.8-6.
> 
> Now, comparing both packages:
> virtio-win-1.9.8-6 and virtio-win-1.9.8-7 have the same set of drivers.
> The difference between them is that virtio-win-1.9.8-6 was released as
> supplementary, while virtio-win-1.9.8-7 was released in the regular RHEL
> channel.
> 
> Checking the spec file, virtio-win-1.9.8-6  and virtio-win-1.9.8-7 are built
> from the same source: virtio-win-1.9.8-4-bin-for-rpm.tar.gz
> They are suppose to be exactly the same.
> 
> Checking both isos, 1.9.8-6 and and 1.9.8.7 have the same file set.
> Even more: both isos have the same size:
> 
> 1.9.8-6:
> -rw-r--r-- 1 danilo danilo 258799616 Jun 26 19:31 virtio-win-1.9.8.iso
> lrwxrwxrwx 1 danilo danilo        20 Aug 27 20:41 virtio-win.iso ->
> virtio-win-1.9.8.iso
> 
> 1.9.8-7:
> -rw-r--r-- 1 danilo danilo 258799616 Jul  1 21:26 virtio-win-1.9.8.iso
> lrwxrwxrwx 1 danilo danilo        20 Aug 27 20:41 virtio-win.iso ->
> virtio-win-1.9.8.iso
> 
> Unless mkisofs got corrupted in brew's buildroot between 1.9.8-6 and 1.9.8-7
> (by building a bad iso),  both images are suppose to be valid.
> 
> A quick check in both images (mounted with mkdir mount; sudo mount -o loop
> virtio-win.iso mount/ ) shows that they are valid and have the exactly same
> set of files (which is expected).
> 
> $ diff -r 1.9.8-6/usr/share/virtio-win/mount
> 1.9.8-7/usr/share/virtio-win/mount
> $
> 
> ^ this means that the content of them is the same.
> 
> My conclusion of this is that this bug is not package-related - because they
> are virtually the same 
> We got lucky that we had to build '-7' with the same content as -6 just
> because of the distribution channel.
> 
> I don't know how many times OP tried to reproduce this with 1.9.8-6 (or
> virtio-win.iso in 1.9.8-7), but I believe OP will be able to reproduce this
> issue there as well.

Hi Danilo,

I tried do follows tests:

1) Tested with virtio-win.iso in 1.9.8-6, also can reproduce this issue.  After the attachment picture occurred, restart guest to reinstall os, found that the system reserved partition 1 can be deleted, but the partition 2 for os installed cannot be deleted, the button of Delete is gray.

2) Tested with virtio-win.iso in 1.9.8-2, also can reproduce this issue. situation is same as 1).

3) When test with virtio-win.iso in 1.9.8-6, hit another failed error, hit two times with info "The operating system couldn't be loaded because a critical system driver is missing or contains errors", and show status: 0xc0000221, I attached pictures as windows_failed_installation_1,2.

Created attachment 1608968 [details]
windows_failed_installation_1

Created attachment 1608970 [details]
windows_failed_installation_2

I can re-install os successfully if failed as picture windows_failed_installation_1/2, the partition 1 and partition 2 both can be deleted successfully, then os install can be finished normally.

Thanks wyu~

I also reproduced this issue with virtio-scsi-pci on rhel8.1.0 fast train.
1) Reproduced this issue with aio=native and /usr/share/virtio-win/virtio-win.iso for virtio-win-1.9.8-7.
2) Cannot reproduce this issue with aio=thread and /usr/share/virtio-win/virtio-win.iso for virtio-win-1.9.8-7.
3) Reproduced this issue with both /usr/share/virtio-win/virtio-win-1.9.8.iso and /usr/share/virtio-win/virtio-win.iso for virtio-win-1.9.8-7 with aio=native.
4) Reproduced this issue with latest virtio-win-1.9.9-3.rpm package with aio=native.

And it cannot be reproduced on rhel8.1 slow train, tested step same with comment#0.

Fast train used qemu version: qemu-kvm-4.1.0-4.module+el8.1.0+4020+16089f93.x86_64
Slow train used qemu version: qemu-kvm-2.12.0-85.module+el8.1.0+4066+0f1aadab.x86_64

Best Regards~
Peixiu

Tested with aio=native on latest QEMU 4.0, not hit this issue.


Host:
kernel-4.18.0-131.el8.x86_64
qemu-kvm-4.0.0-6.module+el8.1.0+3736+a2aefea3


Guest:
win10 x86_64 with virtio-win-prewhql-0.1-172

(In reply to Xueqiang Wei from comment #22)
> Tested with aio=native on latest QEMU 4.0, not hit this issue.
> 
> 
> Host:
> kernel-4.18.0-131.el8.x86_64
> qemu-kvm-4.0.0-6.module+el8.1.0+3736+a2aefea3
> 
> 
> Guest:
> win10 x86_64 with virtio-win-prewhql-0.1-172

Hi Peixiu,

Could you please confirm if this issue has been fixed in latest qemu from your side?

Thanks.

(In reply to CongLi from comment #24)
> (In reply to Xueqiang Wei from comment #22)
> > Tested with aio=native on latest QEMU 4.0, not hit this issue.
> > 
> > 
> > Host:
> > kernel-4.18.0-131.el8.x86_64
> > qemu-kvm-4.0.0-6.module+el8.1.0+3736+a2aefea3
> > 
> > 
> > Guest:
> > win10 x86_64 with virtio-win-prewhql-0.1-172
> 
> Hi Peixiu,
> 
> Could you please confirm if this issue has been fixed in latest qemu from
> your side?
> 

Hi coli,

I tested with latest qemu version qemu-kvm-4.1.0-7.module+el8.1.0+4177+896cb282.x86_64,
also reproduced this issue, tested with virtio-scsi-pci.

device command as:
    -device pcie-root-port,id=pcie.0-root-port-3,slot=3,chassis=3,addr=0x3,bus=pcie.0 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,num_queues=40,bus=pcie.0-root-port-3,addr=0x0 \
    -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/win2019.qcow2 \
    -device scsi-hd,id=image1,drive=drive_image1,bootindex=0 \

Used versions:
kernel-4.18.0-135.el8.x86_64
qemu-kvm-4.1.0-7.module+el8.1.0+4177+896cb282.x86_64
virtio-win-1.9.8-7
seabios-bin-1.12.0-5.module+el8.1.0+4022+29a53beb.noarch

BR~
Peixiu
> Thanks.

Did you run 'qemu-img check' on the image file after seeing the problem?

I'm wondering if this is related to this upstream bug: https://bugs.launchpad.net/qemu/+bug/1846427

So far we haven't found a root cause for it, but it looks like disabling the handle_alloc_space() code path in the qcow2 driver, which was introduced in 4.1, makes the problem go away. If you like, I can prepare a scratch build with that code path disabled for testing.

(In reply to Kevin Wolf from comment #30)
> Did you run 'qemu-img check' on the image file after seeing the problem?
> 
> I'm wondering if this is related to this upstream bug:
> https://bugs.launchpad.net/qemu/+bug/1846427
> 
> So far we haven't found a root cause for it, but it looks like disabling the
> handle_alloc_space() code path in the qcow2 driver, which was introduced in
> 4.1, makes the problem go away. If you like, I can prepare a scratch build
> with that code path disabled for testing.

Yes, please. It will be quite helpful for the future testing.

Thanks,
Vadim.

You can use the scratch build I made for bug 1764721:

https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=24263824

Hi, 

From my latest test, in 'qemu-kvm-4.1.0-13.module+el8.1.0+4313+ef76ec61', I reproduced this bug. 

In 'qemu-kvm-4.1.0-14.module+el8.1.0+4548+ed1300f4', there is no the issue anymore.



Both of the install cmls are:

# /usr/libexec/qemu-kvm \
    -S  \
    -name 'avocado-vt-vm1' \
    -machine q35  \
    -nodefaults \
    -device VGA,bus=pcie.0,addr=0x1  \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/var/tmp/avocado_7butsiko/monitor-qmpmonitor1-20191029-223544-b36zYRAD,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control  \
    -chardev socket,id=qmp_id_catch_monitor,path=/var/tmp/avocado_7butsiko/monitor-catch_monitor-20191029-223544-b36zYRAD,server,nowait \
    -mon chardev=qmp_id_catch_monitor,mode=control \
    -device pvpanic,ioport=0x505,id=idMn0gON \
    -chardev socket,id=chardev_serial0,server,nowait,path=/var/tmp/avocado_7butsiko/serial-serial0-20191029-223544-b36zYRAD \
    -device isa-serial,id=serial0,chardev=chardev_serial0  \
    -chardev socket,id=seabioslog_id_20191029-223544-b36zYRAD,path=/var/tmp/avocado_7butsiko/seabios-20191029-223544-b36zYRAD,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20191029-223544-b36zYRAD,iobase=0x402 \
    -device pcie-root-port,id=pcie.0-root-port-2,slot=2,chassis=2,addr=0x2,bus=pcie.0 \
    -device qemu-xhci,id=usb1,bus=pcie.0-root-port-2,addr=0x0 \
    -device pcie-root-port,id=pcie.0-root-port-3,slot=3,chassis=3,addr=0x3,bus=pcie.0 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pcie.0-root-port-3,addr=0x0 \
    -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/win2019-64-virtio-scsi.qcow2 \
    -device scsi-hd,id=image1,drive=drive_image1,bootindex=0,serial=SYSTEM_DISK0 \
    -drive id=drive_stg,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage.qcow2 \
    -device scsi-hd,id=stg,drive=drive_stg \
    -drive id=drive_stg2,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage2.qcow2 \
    -device scsi-hd,id=stg2,drive=drive_stg2 \
    -drive id=drive_stg3,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage3.qcow2 \
    -device scsi-hd,id=stg3,drive=drive_stg3 \
    -drive id=drive_stg4,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage4.qcow2 \
    -device scsi-hd,id=stg4,drive=drive_stg4 \
    -drive id=drive_stg5,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage5.qcow2 \
    -device scsi-hd,id=stg5,drive=drive_stg5 \
    -drive id=drive_stg6,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage6.qcow2 \
    -device scsi-hd,id=stg6,drive=drive_stg6 \
    -drive id=drive_stg7,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage7.qcow2 \
    -device scsi-hd,id=stg7,drive=drive_stg7 \
    -drive id=drive_stg8,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage8.qcow2 \
    -device scsi-hd,id=stg8,drive=drive_stg8 \
    -drive id=drive_stg9,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage9.qcow2 \
    -device scsi-hd,id=stg9,drive=drive_stg9 \
    -drive id=drive_stg10,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage10.qcow2 \
    -device scsi-hd,id=stg10,drive=drive_stg10 \
    -drive id=drive_stg11,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage11.qcow2 \
    -device scsi-hd,id=stg11,drive=drive_stg11 \
    -drive id=drive_stg12,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage12.qcow2 \
    -device scsi-hd,id=stg12,drive=drive_stg12 \
    -drive id=drive_stg13,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage13.qcow2 \
    -device scsi-hd,id=stg13,drive=drive_stg13 \
    -drive id=drive_stg14,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage14.qcow2 \
    -device scsi-hd,id=stg14,drive=drive_stg14 \
    -drive id=drive_stg15,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage15.qcow2 \
    -device scsi-hd,id=stg15,drive=drive_stg15 \
    -drive id=drive_stg16,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage16.qcow2 \
    -device scsi-hd,id=stg16,drive=drive_stg16 \
    -drive id=drive_stg17,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage17.qcow2 \
    -device scsi-hd,id=stg17,drive=drive_stg17 \
    -drive id=drive_stg18,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage18.qcow2 \
    -device scsi-hd,id=stg18,drive=drive_stg18 \
    -drive id=drive_stg19,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage19.qcow2 \
    -device scsi-hd,id=stg19,drive=drive_stg19 \
    -drive id=drive_stg20,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage20.qcow2 \
    -device scsi-hd,id=stg20,drive=drive_stg20 \
    -drive id=drive_stg21,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage21.qcow2 \
    -device scsi-hd,id=stg21,drive=drive_stg21 \
    -drive id=drive_stg22,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage22.qcow2 \
    -device scsi-hd,id=stg22,drive=drive_stg22 \
    -drive id=drive_stg23,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage23.qcow2 \
    -device scsi-hd,id=stg23,drive=drive_stg23 \
    -drive id=drive_stg24,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/storage24.qcow2 \
    -device scsi-hd,id=stg24,drive=drive_stg24 \
    -device pcie-root-port,id=pcie.0-root-port-4,slot=4,chassis=4,addr=0x4,bus=pcie.0 \
    -device virtio-net-pci,mac=9a:73:b6:4e:16:3a,id=idu0UeT8,netdev=idGsOwTt,bus=pcie.0-root-port-4,addr=0x0  \
    -netdev tap,id=idGsOwTt,vhost=on,vhostfd=23,fd=17 \
    -m 15360  \
    -smp 16,maxcpus=16,cores=1,threads=1,dies=8,sockets=2  \
    -cpu 'IvyBridge',hv_stimer,hv_synic,hv_vpindex,hv_reset,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv-tlbflush,+kvm_pv_unhalt \
    -drive id=drive_cd1,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/home/kvm_autotest_root/iso/ISO/Win2019/en_windows_server_2019_updated_march_2019_x64_dvd_2ae967ab.iso \
    -device ide-cd,id=cd1,drive=drive_cd1,bus=ide.0,unit=0 \
    -drive id=drive_winutils,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/home/kvm_autotest_root/iso/windows/winutils.iso \
    -device ide-cd,id=winutils,drive=drive_winutils,bus=ide.1,unit=0 \
    -drive id=drive_unattended,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/home/kvm_autotest_root/images/win2019-64/autounattend.iso \
    -device ide-cd,id=unattended,drive=drive_unattended,bus=ide.2,unit=0 \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -vnc :0  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot order=cdn,once=d,menu=off,strict=off \
    -enable-kvm \
    -device pcie-root-port,id=pcie_extra_root_port_0,slot=5,chassis=5,addr=0x5,bus=pcie.0

Thanks for testing!  I think it’s a duplicate then.

Max

*** This bug has been marked as a duplicate of bug 1751934 ***