Commit 9a4c0e220d (hw/virtio-pci: fix virtio behaviour) modified virtio devices
behavior to be 1.0 by default for PCIe Ports and Downstream Ports.

What happens is that the Windows guests do not have virtio 1.0 drivers
installed, so Windows can't access the disk. (Possibly virtio 0.9 drivers
are installed in the images used by the QE.


For QE: please check again with virtio 1.0 drivers.

(In reply to Marcel Apfelbaum from comment #4)
> Commit 9a4c0e220d (hw/virtio-pci: fix virtio behaviour) modified virtio
> devices
> behavior to be 1.0 by default for PCIe Ports and Downstream Ports.
> 
> What happens is that the Windows guests do not have virtio 1.0 drivers
> installed, so Windows can't access the disk. (Possibly virtio 0.9 drivers
> are installed in the images used by the QE.
> 
> 
> For QE: please check again with virtio 1.0 drivers.

Hi Marcel

  First, I check the driver when the virtio-blk device attached to the pcie bus, and it is really the virtio1.0 driver(check the screenshot-bug1372086).then I used the default driver and the device attach to root.1 port and hit the issue.

  Second, I used the disalbe-modern parameter and also hit the bz again


/usr/libexec/qemu-kvm \
-M q35 \
-cpu SandyBridge \
-nodefaults -rtc base=utc \
-m 4G \
-smp 2,sockets=2,cores=1,threads=1 \
-enable-kvm \
-name rhel7.3 \
-k en-us \
-serial unix:/tmp/console,server,nowait \
-boot menu=on \
-bios /usr/share/seabios/bios.bin \
-chardev file,path=/home/e1000e/seabios.log,id=seabios \
-device isa-debugcon,chardev=seabios,iobase=0x402 \
-qmp tcp::8887,server,nowait \
-vga qxl \
-spice port=5932,disable-ticketing \
-device ioh3420,id=root.0,slot=1 \
-device x3130-upstream,bus=root.0,id=upstream1 \
-device xio3130-downstream,bus=upstream1,id=downstream1,chassis=1 \
-device ioh3420,id=root.1,slot=2 \
-drive file=/home/win7bk,if=none,id=drive-virtio-disk0,format=qcow2,cache=none,werror=stop,rerror=stop \
-device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,bus=root.1,disable-legacy=on,disable-modern=off \
-drive file=/home/e1000e/test.qcow2,if=none,id=drive-virtio-disk1,format=qcow2,cache=none,werror=stop,rerror=stop \
-device virtio-blk-pci,drive=drive-virtio-disk1,id=virtio-disk1 \
-netdev tap,id=hostnet1 \
-device virtio-net-pci,netdev=hostnet1,id=net1,mac=54:52:00:B6:40:22 \
-netdev tap,id=hostnet2 \
-device virtio-net-pci,netdev=hostnet2,id=net2,mac=54:52:00:B6:40:23 \
-drive file=/usr/share/virtio-win/virtio-win-1.9.0.iso,if=none,id=ide1,format=raw,media=cdrom \
-device ide-drive,bus=ide.0,unit=0,drive=ide1,id=ide1 \
-monitor stdio \


Thanks
Jing Zhao

Created attachment 1205766 [details]
screenshot-bug1375086

virtio-win driver version
[root@jinzhao e1000e]# rpm -qa |grep virtio-win
virtio-win-1.9.0-3.el7.noarch

(In reply to jingzhao from comment #5)
> (In reply to Marcel Apfelbaum from comment #4)
> > Commit 9a4c0e220d (hw/virtio-pci: fix virtio behaviour) modified virtio
> > devices
> > behavior to be 1.0 by default for PCIe Ports and Downstream Ports.
> > 
> > What happens is that the Windows guests do not have virtio 1.0 drivers
> > installed, so Windows can't access the disk. (Possibly virtio 0.9 drivers
> > are installed in the images used by the QE.
> > 
> > 
> > For QE: please check again with virtio 1.0 drivers.
> 
> Hi Marcel
> 

Hi,

>   First, I check the driver when the virtio-blk device attached to the pcie
> bus, and it is really the virtio1.0 driver(check the
> screenshot-bug1372086).then I used the default driver and the device attach
> to root.1 port and hit the issue.
> 

Hi,
Please show the driver details with version number, not the resources page.


>   Second, I used the disalbe-modern parameter and also hit the bz again
> 

You need to use: "disable-legacy=off".

> 
[...]

> -device
> virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,bus=root.
> 1,disable-legacy=on,disable-modern=off \

You used "disable-legacy=on,disable-modern=off", which is done by default
for PCIe ports.


Please use: disable-legacy=off, it should be enough to load Windows.
  
Thanks,
Marcel


[...]

OK, I tried by myself with the virtio drivers from brew-build:
    https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=513949
and it doesn't work.

The problem seems to be that virtio-win drivers don't work with option
"disable-legacy=on". (you don't need a root port or switch, maybe even Q35)
Vadim, Ladi, can you please have a look?

Thanks,
Marcel

"disable-legacy=on" changes the device ID (from 1001 to 1042 for virtio-blk-pci) so it looks like a different device to Windows than the one it installed the driver for. I don't think that Windows does full driver discovery, ID matching, and all that jazz at boot time so in this scenario it just gives up.

My Win7 VM loads a different viostor driver depending on the disable-legacy switch (it's not a fresh install and has already seen both) so that would support the theory I think.

Can you try adding a second virtio-blk-pci non-boot disk with "disable-legacy=on", installing a driver for the controller, and then removing it and switching the boot disk to "disable-legacy=on"? That should do it.

(In reply to Ladi Prosek from comment #10)

Hi Ladi, nice trick, thanks!
Before that, I tried the same, but without a second disk...

Now the question is how we document the transition to virtio 1.0 ?
Q35 for example uses virtio 1.0 (with no legacy) for devices
connected to root ports or switches. When upgrading to 7.3 they need
to follow those instructions.

Thanks,
Marcel

Hi Marcel,

Wait, so we support upgrading existing VMs from i440fx to Q35? Or moving devices between ports/switches as part of migrations? I would expect this issue to come up only when someone toggles the switch manually. If the VM was installed with this specific virtual HW config, everything should be fine. If the VM changes underneath an already installed guest OS (which I believe is the case of this BZ), all bets are off.

Would a blog post be appropriate or do you think that it calls for something more formal?

Thanks,
Ladi

(In reply to Ladi Prosek from comment #12)
> Hi Marcel,
> 
> Wait, so we support upgrading existing VMs from i440fx to Q35?

No

 Or moving
> devices between ports/switches as part of migrations?

No

 I would expect this
> issue to come up only when someone toggles the switch manually.

What happens is starting with 7.3 the virtio devices have no legacy support by default (if connected to PCIe ports).

So a Windows VM on a RHEL 7.2 host would see virtio 0.95 devices. After upgrade to 7.3 the VM will see virtio 1.0 devices if connected to PCie Root Ports or Downstream Ports.

 If the VM
> was installed with this specific virtual HW config, everything should be
> fine. If the VM changes underneath an already installed guest OS (which I
> believe is the case of this BZ), all bets are off.
> 


> Would a blog post be appropriate or do you think that it calls for something
> more formal?
> 

I think we need something more formal, I'll ask for documentation, please
review my doc proposal.

> Thanks,
> Ladi

(In reply to Marcel Apfelbaum from comment #13)
> What happens is starting with 7.3 the virtio devices have no legacy support
> by default (if connected to PCIe ports).
> 
> So a Windows VM on a RHEL 7.2 host would see virtio 0.95 devices. After
> upgrade to 7.3 the VM will see virtio 1.0 devices if connected to PCie Root
> Ports or Downstream Ports.

I see, so technically a breaking a change.

> I think we need something more formal, I'll ask for documentation, please
> review my doc proposal.

Looks good!

I don't know if upgrading virtio-win drivers is usually communicated as a must when upgrading to a new RHEL version. If not, it should be in this case, or at least it should be emphasized that all drivers, not just blk/scsi, could break.