Description of problem: Commit af1b80ae56c9 ("i386/acpi: fix inconsistent QEMU/OVMF device paths") fixed UID of PCI root bridge in ACPI tables for all pc/q35 machine versions. It has caused device re-ennumeration on Windows, which is not big deal when guest gets IP address over DHCP. However if NIC was configured with static IP address, Windows will make original 'network connection' inactive and create a new one (which is not configured as desired). As result guest looses network connectivity. Original issue report: https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg08484.html Version-Release number of selected component (if applicable): qemu-kvm-5.2.0-9 How reproducible: 100% Steps to Reproduce: 1. on QEMU older than 5.2 install Windows Server 2016 guest with virtio NIC 2. configure NIC with static IP and shutdown guest 3. start guest on qemu-5.2 with same machine version as in step 1 Actual results: Guest looses network connectivity on previously configure IP address and new 'network connection' is created Expected results: 'network connection' configured in step 1 stays functional. Additional info:
there was another bug report upstream with the same root cause: "Windows 10 fails with "Boot device inaccessible" https://bugs.launchpad.net/qemu/+bug/1917565 so in some cases it's not limited to static NIC config only. Though guest boots fine on preinstalled images I test with, perhaps it depends on specific configuration and/or version of Windows10
Instructions to reproduce: 1. Install qemu-kvm-4.2.0-xxx 2. Create Q35 8.2 VM (BIOS) with virio-net network adapter and install guest using en_windows_server_2016_x64_dvd_9718492.iso and virtio-win-1.9.15-0 3. After updating NIC to virtio-net driver, go to 'Network Connections', where one connection 'Ethernet' will be present configure it with static IP address and shutdown guest 4. Install broken qemu-kvm-5.2.0-8, start VM again and got to 'Network Connections', where new connection 'Ethernet 2' with DHCP config will be present and old one is gone (if network VM is connected to doesn't have DHCP server guest looses network connectivity until new connection is reconfigured) shutdown VM 5. Install fixed qemu-kvm-5.2, start VM and got to 'Network Connections' where old 'Ethernet' connection is present again with its static IP configuration. Brew build for verification: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=35317921
(In reply to Igor Mammedov from comment #8) > Instructions to reproduce: > > 1. Install qemu-kvm-4.2.0-xxx > > 2. Create Q35 8.2 VM (BIOS) with virio-net network adapter and install guest > using > en_windows_server_2016_x64_dvd_9718492.iso > and > virtio-win-1.9.15-0 > 3. After updating NIC to virtio-net driver, go to > 'Network Connections', where one connection 'Ethernet' will be present > configure it with static IP address > and shutdown guest > 4. Install broken qemu-kvm-5.2.0-8, start VM again and got to > 'Network Connections', where new connection 'Ethernet 2' with DHCP > config will be present and old one is gone > (if network VM is connected to doesn't have DHCP server guest looses > network connectivity until new connection is reconfigured) > shutdown VM > 5. Install fixed qemu-kvm-5.2, start VM and got to 'Network Connections' > where old 'Ethernet' connection is present again with its static IP > configuration. > > Brew build for verification: > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=35317921 Thanks, Igor, for the very detailed reproducer. QE would like to know if the defect affects other pci devices other than virtio-net. Your reply will help identify our test scope. Could you please help clarify? Thanks!
*** Bug 1925893 has been marked as a duplicate of this bug. ***
(In reply to Chao Yang from comment #9) > (In reply to Igor Mammedov from comment #8) > > Instructions to reproduce: > > > > 1. Install qemu-kvm-4.2.0-xxx > > > > 2. Create Q35 8.2 VM (BIOS) with virio-net network adapter and install guest > > using > > en_windows_server_2016_x64_dvd_9718492.iso > > and > > virtio-win-1.9.15-0 > > 3. After updating NIC to virtio-net driver, go to > > 'Network Connections', where one connection 'Ethernet' will be present > > configure it with static IP address > > and shutdown guest > > 4. Install broken qemu-kvm-5.2.0-8, start VM again and got to > > 'Network Connections', where new connection 'Ethernet 2' with DHCP > > config will be present and old one is gone > > (if network VM is connected to doesn't have DHCP server guest looses > > network connectivity until new connection is reconfigured) > > shutdown VM > > 5. Install fixed qemu-kvm-5.2, start VM and got to 'Network Connections' > > where old 'Ethernet' connection is present again with its static IP > > configuration. > > > > Brew build for verification: > > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=35317921 > > Thanks, Igor, for the very detailed reproducer. QE would like to know if the > defect affects other pci devices other than virtio-net. Your reply will help > identify our test scope. Could you please help clarify? Thanks! Yes. Other PCI devices are affected as well. For example, QXL (Spice) resolution setting will be lost as well. But checking NIC name and settings is the most apparent way to verify the fix. You can alternatively use "ipconfig" from the command line to check the adapter name and IP settings.
(In reply to Yan Vugenfirer from comment #12) > (In reply to Chao Yang from comment #9) > > (In reply to Igor Mammedov from comment #8) > > > Instructions to reproduce: > > > > > > 1. Install qemu-kvm-4.2.0-xxx > > > > > > 2. Create Q35 8.2 VM (BIOS) with virio-net network adapter and install guest > > > using > > > en_windows_server_2016_x64_dvd_9718492.iso > > > and > > > virtio-win-1.9.15-0 > > > 3. After updating NIC to virtio-net driver, go to > > > 'Network Connections', where one connection 'Ethernet' will be present > > > configure it with static IP address > > > and shutdown guest > > > 4. Install broken qemu-kvm-5.2.0-8, start VM again and got to > > > 'Network Connections', where new connection 'Ethernet 2' with DHCP > > > config will be present and old one is gone > > > (if network VM is connected to doesn't have DHCP server guest looses > > > network connectivity until new connection is reconfigured) > > > shutdown VM > > > 5. Install fixed qemu-kvm-5.2, start VM and got to 'Network Connections' > > > where old 'Ethernet' connection is present again with its static IP > > > configuration. > > > > > > Brew build for verification: > > > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=35317921 > > > > Thanks, Igor, for the very detailed reproducer. QE would like to know if the > > defect affects other pci devices other than virtio-net. Your reply will help > > identify our test scope. Could you please help clarify? Thanks! > > Yes. Other PCI devices are affected as well. > For example, QXL (Spice) resolution setting will be lost as well. But > checking NIC name and settings is the most apparent way to verify the fix. > You can alternatively use "ipconfig" from the command line to check the > adapter name and IP settings. Thanks!
It's not all PCI devices, for example is I use e1000e nic, adapter stays the same not works as expected. Perhaps there is some magic that virtio drivers don't know about (maybe we should look into that as well). (as to affected devices you may add virtio-scsi (there was report upstream that guest failed to boot)) (I usually don't run ACPI tests with virtio devices, that's probably why we didn't notice it earlier)
Hi Igor I reproduced this problem with "virtio-net + windows_2016/windows_10" Test Steps: 1. Install qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 and boot guest /usr/libexec/qemu-kvm -name Win2016 \ -M q35,kernel-irqchip=split -m 8G \ -nodefaults \ -cpu Haswell-noTSX \ -smp 4,sockets=1,cores=4,threads=1 \ -device pcie-root-port,id=root.1,chassis=1,addr=0x2.0,multifunction=on \ -device pcie-root-port,id=root.2,chassis=2,addr=0x2.1 \ -device pcie-root-port,id=root.3,chassis=3,addr=0x2.2 \ -device pcie-root-port,id=root.4,chassis=4,addr=0x2.3 \ -device pcie-root-port,id=root.5,chassis=5,addr=0x2.4 \ -device pcie-root-port,id=root.6,chassis=6,addr=0x2.5 \ -device pcie-root-port,id=root.7,chassis=7,addr=0x2.6 \ -device pcie-root-port,id=root.8,chassis=8,addr=0x2.7 \ -blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/images/win2016.qcow2,node-name=my_file \ -blockdev driver=qcow2,node-name=my,file=my_file \ -device virtio-blk-pci,drive=my,id=virtio-blk0,bus=root.1 \ -drive id=drive_cd1,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/home/images/en_windows_server_2016_updated_feb_2018_x64_dvd_11636692.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=/usr/share/virtio-win/virtio-win-1.9.15.iso \ -device ide-cd,id=winutils,drive=drive_winutils,bus=ide.1,unit=0 \ -vnc :0 \ -vga qxl \ -monitor stdio \ -usb -device usb-tablet \ -boot menu=on \ -device virtio-net-pci,netdev=nic1,id=vnet0,mac=54:43:00:1a:11:33,bus=root.2 \ -netdev tap,id=nic1,vhost=on \ 2.Configure a static IP address for the nic nic name: Ethernet static ip: netsh interface ip set address "Ethernet" static 192.168.10.10 255.255.225.0 192.168.10.1 3.shutdown guest 4.Install qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 and boot guest again. nic name: "Ethernet" change to "Ethernet 3" The static ip address disappears and a new ip address is obtained with dhcp.(So successfully reproduced this problem.) 5.Install fixed qemu-kvm-5.2.0-9.el8.imammedo202103081132.x86_64 nic name: Ethernet The static ip address still exits. As described above comments, other PCI devices will also be affected. Can you help list other PCI devices that need to be tested？ Please let me know if you need QE for more testing. Best Regards Lei Yang
(In reply to Lei Yang from comment #15) > Hi Igor [...] for testing it's important to use versioned machine type that comes with qemu-4.2 [...] > As described above comments, other PCI devices will also be affected. Can > you help list other PCI devices that need to be tested？ Please let me know > if you need QE for more testing. I don't have a list of devices that needs testing, So far I suspect only virtio devices are affected (it worked fine with e1000 nic and default disk adapters for me) I only can suggest test all and find ones that's broken. From what I can see in 'Device Manager' is you turn on 'show hidden devices' you can see second (inactive) instance of affected device and if you click on device and go to 'events' tab, you can check 'device install' event. It contains some kind of device path, and for broken devices the last numbers will differ which probably causes creation of new device. But I'm not windows expert it's better to ask someone from windows team about it. (maybe even open a BZ on virtio drivers, with justification that enumerate differently between qemu-4.2 and 5.2 while non virtio devices work as expected)
(In reply to Igor Mammedov from comment #17) > (In reply to Lei Yang from comment #15) > > Hi Igor > [...] > for testing it's important to use versioned machine type that comes with > qemu-4.2 > > [...] > > As described above comments, other PCI devices will also be affected. Can > > you help list other PCI devices that need to be tested？ Please let me know > > if you need QE for more testing. > > I don't have a list of devices that needs testing, > So far I suspect only virtio devices are affected (it worked fine with e1000 > nic and default disk adapters for me) > I only can suggest test all and find ones that's broken. > > From what I can see in 'Device Manager' is you turn on 'show hidden devices' > you can see second (inactive) instance of affected device and if you click > on device and go to 'events' tab, you can check 'device install' event. It > contains some kind of device path, and for broken devices the last numbers > will differ which probably causes creation of new device. > But I'm not windows expert it's better to ask someone from windows team > about it. Hi Lei Yang, Checking the device manager is a great test. I suggest testing virtio-net, virtio-block, virtio-scsi, and QXL devices. > > (maybe even open a BZ on virtio drivers, with justification that > enumerate differently between qemu-4.2 and 5.2 while non virtio devices work > as expected)
Test failed with qemu-kvm-5.2.0-9.el8.imammedo202103081132.x86_64 and qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 Test steps: 1 install and boot vm under qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 /usr/libexec/qemu-kvm -name Win2016 \ -M q35,kernel-irqchip=split -m 8G \ -nodefaults \ -cpu Haswell-noTSX \ -smp 4,sockets=1,cores=4,threads=1 \ -device pcie-root-port,id=root.1,chassis=1,addr=0x2.0,multifunction=on \ -device pcie-root-port,id=root.2,chassis=2,addr=0x2.1 \ -device pcie-root-port,id=root.3,chassis=3,addr=0x2.2 \ -device pcie-root-port,id=root.4,chassis=4,addr=0x2.3 \ -device pcie-root-port,id=root.5,chassis=5,addr=0x2.4 \ -device pcie-root-port,id=root.6,chassis=6,addr=0x2.5 \ -device pcie-root-port,id=root.7,chassis=7,addr=0x2.6 \ -device pcie-root-port,id=root.8,chassis=8,addr=0x2.7 \ -device virtio-scsi-pci,id=scsi0,bus=root.3 \ -blockdev driver=file,filename=/home/kvm_autotest_root/images/win2016-64-virtio.qcow2,node-name=my_file \ -blockdev driver=qcow2,node-name=my,file=my_file \ -device virtio-blk-pci,drive=my,id=virtio-blk0,bus=root.1,bootindex=0 \ -blockdev driver=file,filename=/home/kvm_autotest_root/images/data1.qcow2,node-name=my_file1 \ -blockdev driver=qcow2,node-name=mydata1,file=my_file1 \ -device virtio-blk-pci,drive=mydata1,id=data1,bus=root.2,bootindex=2 \ -blockdev driver=file,filename=/home/kvm_autotest_root/images/data2.qcow2,node-name=my_file2 \ -blockdev driver=qcow2,node-name=mydata2,file=my_file2 \ -device scsi-hd,drive=mydata2,id=data2,bus=scsi0.0,bootindex=3 \ \ -blockdev node-name=file_cd1,driver=file,auto-read-only=on,discard=unmap,aio=threads,filename=/home/kvm_autotest_root/iso/windows/virtio-win-1.9.15-0.el8.iso,cache.direct=on,cache.no-flush=off \ -blockdev node-name=drive_cd1,driver=raw,read-only=on,cache.direct=on,cache.no-flush=off,file=file_cd1 \ -device ide-cd,id=cd1,drive=drive_cd1,bootindex=1,write-cache=on,bus=ide.0,unit=0 \ -vnc :5 \ -vga qxl \ -monitor stdio \ -qmp tcp:0:5955,server,nowait \ -usb -device usb-tablet \ -boot menu=on \ -device virtio-net-pci,netdev=nic1,id=vnet0,mac=54:43:00:1a:11:33,bus=root.6 \ -netdev tap,id=nic1,vhost=on \ 2.Configure a static IP address for the nic nic name: Ethernet static ip: netsh interface ip set address "Ethernet" static 192.168.10.10 255.255.225.0 192.168.10.1 3.online data disks and format them system detech E and F disks 4.shutdown guest 5.Install qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 and boot guest again. nic name: "Ethernet" change to "Ethernet 3" The static ip address disappears and a new ip address is obtained with dhcp.(So successfully reproduced this problem.) data disks display offline in disk managerment It have same result on qemu-kvm-5.2.0-9.el8.imammedo202103081132.x86_64
Created attachment 1763584 [details] change qemu before
Created attachment 1763585 [details] change qemu after
version info : Red Hat Enterprise Linux release 8.4 Beta (Ootpa) 4.18.0-293.el8.x86_64 qemu-kvm-common-5.2.0-9.el8.imammedo202103081132.x86_64
(In reply to qing.wang from comment #24) > Test failed with qemu-kvm-5.2.0-9.el8.imammedo202103081132.x86_64 and > qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 > Test steps: > 1 install and boot vm under > qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 > > /usr/libexec/qemu-kvm -name Win2016 \ > -M q35,kernel-irqchip=split -m 8G \ ^^^ this has to be versioned machine type, and the same machine type should be used after QEMU upgrade. Reason for failure is that, old PCI UIDs are kept only for machine types older than 8.4 and new UIDs are used for 8.4 machine type and newer (which includes default q35). So when using default 'q35' machine type installing Windows on qemu-kvm-4.2.0-47 you are installing on q35 RHEL-8.2.0 PC (Q35 + ICH9, 2009) (alias of pc-q35-rhel8.2.0) pc-q35-rhel8.2.0 RHEL-8.2.0 PC (Q35 + ICH9, 2009) and then when you update to fixed version qemu-kvm-common-5.2.0-9.el8.imammedo202103081132.x86_64 and still using 'q35', you are using q35 RHEL-8.4.0 PC (Q35 + ICH9, 2009) (alias of pc-q35-rhel8.4.0) pc-q35-rhel8.4.0 RHEL-8.4.0 PC (Q35 + ICH9, 2009) which is incompatible with 'pc-q35-rhel8.2.0' you need to use 'pc-q35-rhel8.2.0' machine type instead of 'q35' > -nodefaults \ > -cpu Haswell-noTSX \ > -smp 4,sockets=1,cores=4,threads=1 \ > -device pcie-root-port,id=root.1,chassis=1,addr=0x2.0,multifunction=on \ > -device pcie-root-port,id=root.2,chassis=2,addr=0x2.1 \ > -device pcie-root-port,id=root.3,chassis=3,addr=0x2.2 \ > -device pcie-root-port,id=root.4,chassis=4,addr=0x2.3 \ > -device pcie-root-port,id=root.5,chassis=5,addr=0x2.4 \ > -device pcie-root-port,id=root.6,chassis=6,addr=0x2.5 \ > -device pcie-root-port,id=root.7,chassis=7,addr=0x2.6 \ > -device pcie-root-port,id=root.8,chassis=8,addr=0x2.7 \ > -device virtio-scsi-pci,id=scsi0,bus=root.3 \ > -blockdev > driver=file,filename=/home/kvm_autotest_root/images/win2016-64-virtio.qcow2, > node-name=my_file \ > -blockdev driver=qcow2,node-name=my,file=my_file \ > -device virtio-blk-pci,drive=my,id=virtio-blk0,bus=root.1,bootindex=0 \ > -blockdev > driver=file,filename=/home/kvm_autotest_root/images/data1.qcow2,node- > name=my_file1 \ > -blockdev driver=qcow2,node-name=mydata1,file=my_file1 \ > -device virtio-blk-pci,drive=mydata1,id=data1,bus=root.2,bootindex=2 \ > -blockdev > driver=file,filename=/home/kvm_autotest_root/images/data2.qcow2,node- > name=my_file2 \ > -blockdev driver=qcow2,node-name=mydata2,file=my_file2 \ > -device scsi-hd,drive=mydata2,id=data2,bus=scsi0.0,bootindex=3 \ > \ > -blockdev > node-name=file_cd1,driver=file,auto-read-only=on,discard=unmap,aio=threads, > filename=/home/kvm_autotest_root/iso/windows/virtio-win-1.9.15-0.el8.iso, > cache.direct=on,cache.no-flush=off \ > -blockdev > node-name=drive_cd1,driver=raw,read-only=on,cache.direct=on,cache.no- > flush=off,file=file_cd1 \ > -device > ide-cd,id=cd1,drive=drive_cd1,bootindex=1,write-cache=on,bus=ide.0,unit=0 \ > -vnc :5 \ > -vga qxl \ > -monitor stdio \ > -qmp tcp:0:5955,server,nowait \ > -usb -device usb-tablet \ > -boot menu=on \ > -device virtio-net-pci,netdev=nic1,id=vnet0,mac=54:43:00:1a:11:33,bus=root.6 > \ > -netdev tap,id=nic1,vhost=on \ > > 2.Configure a static IP address for the nic > nic name: Ethernet > static ip: netsh interface ip set address "Ethernet" static 192.168.10.10 > 255.255.225.0 192.168.10.1 > > 3.online data disks and format them > system detech E and F disks > > 4.shutdown guest > > 5.Install qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 and boot > guest again. > nic name: "Ethernet" change to "Ethernet 3" > The static ip address disappears and a new ip address is obtained with > dhcp.(So successfully reproduced this problem.) > data disks display offline in disk managerment > > It have same result on qemu-kvm-5.2.0-9.el8.imammedo202103081132.x86_64
(In reply to Igor Mammedov from comment #28) > (In reply to qing.wang from comment #24) > > Test failed with qemu-kvm-5.2.0-9.el8.imammedo202103081132.x86_64 and > > qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 > > Test steps: > > 1 install and boot vm under > > qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 > > > > /usr/libexec/qemu-kvm -name Win2016 \ > > -M q35,kernel-irqchip=split -m 8G \ > ^^^ > this has to be versioned machine type, > and the same machine type should be used after QEMU upgrade. > > Reason for failure is that, old PCI UIDs are kept only for machine types > older than 8.4 > and new UIDs are used for 8.4 machine type and newer (which includes default > q35). > > So when using default 'q35' machine type installing Windows on > qemu-kvm-4.2.0-47 > you are installing on > q35 RHEL-8.2.0 PC (Q35 + ICH9, 2009) (alias of > pc-q35-rhel8.2.0) > pc-q35-rhel8.2.0 RHEL-8.2.0 PC (Q35 + ICH9, 2009) > > and then when you update to fixed version > qemu-kvm-common-5.2.0-9.el8.imammedo202103081132.x86_64 > and still using 'q35', you are using > q35 RHEL-8.4.0 PC (Q35 + ICH9, 2009) (alias of > pc-q35-rhel8.4.0) > pc-q35-rhel8.4.0 RHEL-8.4.0 PC (Q35 + ICH9, 2009) > > which is incompatible with 'pc-q35-rhel8.2.0' > you need to use 'pc-q35-rhel8.2.0' machine type instead of 'q35' > > > -nodefaults \ > > -cpu Haswell-noTSX \ > > -smp 4,sockets=1,cores=4,threads=1 \ > > -device pcie-root-port,id=root.1,chassis=1,addr=0x2.0,multifunction=on \ > > -device pcie-root-port,id=root.2,chassis=2,addr=0x2.1 \ > > -device pcie-root-port,id=root.3,chassis=3,addr=0x2.2 \ > > -device pcie-root-port,id=root.4,chassis=4,addr=0x2.3 \ > > -device pcie-root-port,id=root.5,chassis=5,addr=0x2.4 \ > > -device pcie-root-port,id=root.6,chassis=6,addr=0x2.5 \ > > -device pcie-root-port,id=root.7,chassis=7,addr=0x2.6 \ > > -device pcie-root-port,id=root.8,chassis=8,addr=0x2.7 \ > > -device virtio-scsi-pci,id=scsi0,bus=root.3 \ > > -blockdev > > driver=file,filename=/home/kvm_autotest_root/images/win2016-64-virtio.qcow2, > > node-name=my_file \ > > -blockdev driver=qcow2,node-name=my,file=my_file \ > > -device virtio-blk-pci,drive=my,id=virtio-blk0,bus=root.1,bootindex=0 \ > > -blockdev > > driver=file,filename=/home/kvm_autotest_root/images/data1.qcow2,node- > > name=my_file1 \ > > -blockdev driver=qcow2,node-name=mydata1,file=my_file1 \ > > -device virtio-blk-pci,drive=mydata1,id=data1,bus=root.2,bootindex=2 \ > > -blockdev > > driver=file,filename=/home/kvm_autotest_root/images/data2.qcow2,node- > > name=my_file2 \ > > -blockdev driver=qcow2,node-name=mydata2,file=my_file2 \ > > -device scsi-hd,drive=mydata2,id=data2,bus=scsi0.0,bootindex=3 \ > > \ > > -blockdev > > node-name=file_cd1,driver=file,auto-read-only=on,discard=unmap,aio=threads, > > filename=/home/kvm_autotest_root/iso/windows/virtio-win-1.9.15-0.el8.iso, > > cache.direct=on,cache.no-flush=off \ > > -blockdev > > node-name=drive_cd1,driver=raw,read-only=on,cache.direct=on,cache.no- > > flush=off,file=file_cd1 \ > > -device > > ide-cd,id=cd1,drive=drive_cd1,bootindex=1,write-cache=on,bus=ide.0,unit=0 \ > > -vnc :5 \ > > -vga qxl \ > > -monitor stdio \ > > -qmp tcp:0:5955,server,nowait \ > > -usb -device usb-tablet \ > > -boot menu=on \ > > -device virtio-net-pci,netdev=nic1,id=vnet0,mac=54:43:00:1a:11:33,bus=root.6 > > \ > > -netdev tap,id=nic1,vhost=on \ > > > > 2.Configure a static IP address for the nic > > nic name: Ethernet > > static ip: netsh interface ip set address "Ethernet" static 192.168.10.10 > > 255.255.225.0 192.168.10.1 > > > > 3.online data disks and format them > > system detech E and F disks > > > > 4.shutdown guest > > > > 5.Install qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 and boot > > guest again. > > nic name: "Ethernet" change to "Ethernet 3" > > The static ip address disappears and a new ip address is obtained with > > dhcp.(So successfully reproduced this problem.) > > data disks display offline in disk managerment > > > > It have same result on qemu-kvm-5.2.0-9.el8.imammedo202103081132.x86_64 Passed test using machine type pc-q35-rhel8.2.0 on qemu-kvm-5.2.0-9.el8.imammedo202103081132.x86_64 The nic keep same static configuration and data disks are online same as qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64
Add test result with qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64 on Nested Hyper-V on KVM, result is passed. Start windows 2019 guest with pc-q35-rhel8.2.0, upgrade qemu-kvm-4.2.0-46.module+el8.4.0+10218+7dabd3c0.x86_64 to qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64, get the same interface and L2 can get ip successfully
(In reply to Yan Vugenfirer from comment #12) > Yes. Other PCI devices are affected as well. > For example, QXL (Spice) resolution setting will be lost as well. But > checking NIC name and settings is the most apparent way to verify the fix. > You can alternatively use "ipconfig" from the command line to check the > adapter name and IP settings. Based on test result, I don't see this impact to qxl-vga device. Does this bug really impact qxl-vga? My qemu cli: /usr/libexec/qemu-kvm \ -name guest=win10_20H2,debug-threads=on \ -machine pc-q35-rhel8.2.0,accel=kvm,usb=off,dump-guest-core=off \ ... -netdev tap,id=hostnet0 \ -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:2b:50:5a,bus=pci.1,addr=0x0 \ -device usb-tablet,id=input0,bus=usb.0,port=1 \ -vnc 0.0.0.0:0 \ -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 \ ... VM used, win10 20H2 x86 with qxl-vga driver spice-qxl-wddm-dod-0.21-2 On good qemu-kvm-4.2.0-29.module+el8.2.1+9917+2543143c.7.x86_64, set VM resolution to 1280x720 other than default 1024x768 and static ip to virtio-net-pci device(it displays as Eth2), reboot the VM to double confirm the settings are applied successfully.Then shutdown VM. Upgrade to buggy qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64, after VM bootup, I see static ip is lost and virtio-net-pci device displayed as Eth3. But VM resolution is kept at 1280x720. Upgrade to fixed qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64, after VM bootup, I see static ip is back and virtio-net-pci device displayed as Eth2. VM resolution is still kept at 1280x720. The behavior of resolution handling by windows looks similar as the behavior for vGPU. For example, when using nvidia GRID vGPU type GRID T4-2Q with windows 10 VM, set VM resolution to 1920x1080 other than default 2560x1600, VM resolution is kept at 1920x1080 during reboot. Replace the vGPU type to GRID T4-4Q, after first VM bootup, windows 10 VM will have a very short time lost the resolution but quickly recover to 1920x1080. This behavior also happens to intel gvt-g vGPU. BTW, I see other VGA devices are not affected as well, VGA devices I have tested: VGA, virtio-vga. They both use windows standard display driver.
Passed virtio-blk and virtio-scsi test on Red Hat Enterprise Linux release 8.4 Beta (Ootpa) 4.18.0-293.el8.x86_64 qemu-kvm-common-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64 Test steps： 1 install and boot vm under qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 /usr/libexec/qemu-kvm -name Win2016 \ -M q35,kernel-irqchip=split -m 8G \ -nodefaults \ -cpu Haswell-noTSX \ -smp 4,sockets=1,cores=4,threads=1 \ -device pcie-root-port,id=root.1,chassis=1,addr=0x2.0,multifunction=on \ -device pcie-root-port,id=root.2,chassis=2,addr=0x2.1 \ -device pcie-root-port,id=root.3,chassis=3,addr=0x2.2 \ -device pcie-root-port,id=root.4,chassis=4,addr=0x2.3 \ -device pcie-root-port,id=root.5,chassis=5,addr=0x2.4 \ -device pcie-root-port,id=root.6,chassis=6,addr=0x2.5 \ -device pcie-root-port,id=root.7,chassis=7,addr=0x2.6 \ -device pcie-root-port,id=root.8,chassis=8,addr=0x2.7 \ -device virtio-scsi-pci,id=scsi0,bus=root.3 \ -blockdev driver=file,filename=/home/kvm_autotest_root/images/win2016-64-virtio.qcow2,node-name=my_file \ -blockdev driver=qcow2,node-name=my,file=my_file \ -device virtio-blk-pci,drive=my,id=virtio-blk0,bus=root.1,bootindex=0 \ -blockdev driver=file,filename=/home/kvm_autotest_root/images/data1.qcow2,node-name=my_file1 \ -blockdev driver=qcow2,node-name=mydata1,file=my_file1 \ -device virtio-blk-pci,drive=mydata1,id=data1,bus=root.2,bootindex=2 \ -blockdev driver=file,filename=/home/kvm_autotest_root/images/data2.qcow2,node-name=my_file2 \ -blockdev driver=qcow2,node-name=mydata2,file=my_file2 \ -device scsi-hd,drive=mydata2,id=data2,bus=scsi0.0,bootindex=3 \ \ -blockdev node-name=file_cd1,driver=file,auto-read-only=on,discard=unmap,aio=threads,filename=/home/kvm_autotest_root/iso/windows/virtio-win-1.9.15-0.el8.iso,cache.direct=on,cache.no-flush=off \ -blockdev node-name=drive_cd1,driver=raw,read-only=on,cache.direct=on,cache.no-flush=off,file=file_cd1 \ -device ide-cd,id=cd1,drive=drive_cd1,bootindex=1,write-cache=on,bus=ide.0,unit=0 \ -vnc :5 \ -vga qxl \ -monitor stdio \ -qmp tcp:0:5955,server,nowait \ -usb -device usb-tablet \ -boot menu=on \ -device virtio-net-pci,netdev=nic1,id=vnet0,mac=54:43:00:1a:11:33,bus=root.6 \ -netdev tap,id=nic1,vhost=on \ 2.Configure a static IP address for the nic nic name: Ethernet static ip: netsh interface ip set address "Ethernet" static 192.168.10.10 255.255.225.0 192.168.10.1 3.online data disks and format them system get E and F disks 4.shutdown guest 5.Install qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 and boot guest again. nic name: "Ethernet" change to "Ethernet 3" The static ip address disappears and a new ip address is obtained with dhcp.(So successfully reproduced this problem.) data disks display offline in disk management，system loose E and F disks 6.Install qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775 and boot guest again. nic name back to previous and keep same staic ip as befor disks E and F get back.
(In reply to qing.wang from comment #35) > Passed virtio-blk and virtio-scsi test on > Red Hat Enterprise Linux release 8.4 Beta (Ootpa) > 4.18.0-293.el8.x86_64 > qemu-kvm-common-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64 > > Test steps： > > 1 install and boot vm under > qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 > > /usr/libexec/qemu-kvm -name Win2016 \ > -M q35,kernel-irqchip=split -m 8G \ > -nodefaults \ > -cpu Haswell-noTSX \ > -smp 4,sockets=1,cores=4,threads=1 \ > -device pcie-root-port,id=root.1,chassis=1,addr=0x2.0,multifunction=on \ > -device pcie-root-port,id=root.2,chassis=2,addr=0x2.1 \ > -device pcie-root-port,id=root.3,chassis=3,addr=0x2.2 \ > -device pcie-root-port,id=root.4,chassis=4,addr=0x2.3 \ > -device pcie-root-port,id=root.5,chassis=5,addr=0x2.4 \ > -device pcie-root-port,id=root.6,chassis=6,addr=0x2.5 \ > -device pcie-root-port,id=root.7,chassis=7,addr=0x2.6 \ > -device pcie-root-port,id=root.8,chassis=8,addr=0x2.7 \ > -device virtio-scsi-pci,id=scsi0,bus=root.3 \ > -blockdev > driver=file,filename=/home/kvm_autotest_root/images/win2016-64-virtio.qcow2, > node-name=my_file \ > -blockdev driver=qcow2,node-name=my,file=my_file \ > -device virtio-blk-pci,drive=my,id=virtio-blk0,bus=root.1,bootindex=0 \ > -blockdev > driver=file,filename=/home/kvm_autotest_root/images/data1.qcow2,node- > name=my_file1 \ > -blockdev driver=qcow2,node-name=mydata1,file=my_file1 \ > -device virtio-blk-pci,drive=mydata1,id=data1,bus=root.2,bootindex=2 \ > -blockdev > driver=file,filename=/home/kvm_autotest_root/images/data2.qcow2,node- > name=my_file2 \ > -blockdev driver=qcow2,node-name=mydata2,file=my_file2 \ > -device scsi-hd,drive=mydata2,id=data2,bus=scsi0.0,bootindex=3 \ > \ > -blockdev > node-name=file_cd1,driver=file,auto-read-only=on,discard=unmap,aio=threads, > filename=/home/kvm_autotest_root/iso/windows/virtio-win-1.9.15-0.el8.iso, > cache.direct=on,cache.no-flush=off \ > -blockdev > node-name=drive_cd1,driver=raw,read-only=on,cache.direct=on,cache.no- > flush=off,file=file_cd1 \ > -device > ide-cd,id=cd1,drive=drive_cd1,bootindex=1,write-cache=on,bus=ide.0,unit=0 \ > -vnc :5 \ > -vga qxl \ > -monitor stdio \ > -qmp tcp:0:5955,server,nowait \ > -usb -device usb-tablet \ > -boot menu=on \ > -device virtio-net-pci,netdev=nic1,id=vnet0,mac=54:43:00:1a:11:33,bus=root.6 > \ > -netdev tap,id=nic1,vhost=on \ > > 2.Configure a static IP address for the nic > nic name: Ethernet > static ip: netsh interface ip set address "Ethernet" static 192.168.10.10 > 255.255.225.0 192.168.10.1 > > 3.online data disks and format them > system get E and F disks > > 4.shutdown guest > > 5.Install qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 and boot > guest again. > nic name: "Ethernet" change to "Ethernet 3" > The static ip address disappears and a new ip address is obtained with > dhcp.(So successfully reproduced this problem.) > data disks display offline in disk management，system loose E and F disks > > 6.Install qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775 and boot guest > again. > nic name back to previous and keep same staic ip as befor > disks E and F get back. Pass test for win10,win2016 and win2019
==Test Steps Test Version: kernel-4.18.0-297.el8.x86_64 qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 (upgrade qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 ) virtio-win-1.9.15-0.el8.noarch 1. Boot win2016 guest on qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 /usr/libexec/qemu-kvm -name Win2016 \ -M pc-q35-rhel8.2.0,kernel-irqchip=split -m 8G \ -nodefaults \ -cpu Opteron_G5 \ -smp 4,sockets=1,cores=4,threads=1 \ -device pcie-root-port,id=root.1,chassis=1,addr=0x2.0,multifunction=on \ -device pcie-root-port,id=root.2,chassis=2,addr=0x2.1 \ -device pcie-root-port,id=root.3,chassis=3,addr=0x2.2 \ -device pcie-root-port,id=root.4,chassis=4,addr=0x2.3 \ -device pcie-root-port,id=root.5,chassis=5,addr=0x2.4 \ -device pcie-root-port,id=root.6,chassis=6,addr=0x2.5 \ -device pcie-root-port,id=root.7,chassis=7,addr=0x2.6 \ -device pcie-root-port,id=root.8,chassis=8,addr=0x2.7 \ -blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/images/win2016.qcow2,node-name=my_file \ -blockdev driver=qcow2,node-name=my,file=my_file \ -device virtio-blk-pci,drive=my,id=virtio-blk0,bus=root.1 \ -drive id=drive_cd1,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/home/images/en_windows_server_2016_updated_feb_2018_x64_dvd_11636692.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=/usr/share/virtio-win/virtio-win-1.9.15.iso \ -device ide-cd,id=winutils,drive=drive_winutils,bus=ide.1,unit=0 \ -vnc :0 \ -vga qxl \ -monitor stdio \ -usb -device usb-tablet \ -boot menu=on \ -device virtio-net-pci,netdev=nic1,id=vnet0,mac=54:43:00:1a:11:33,bus=root.2 \ -netdev tap,id=nic1,vhost=on \ 2.Configure a static IP address for the nic nic name: Ethernet static ip: netsh interface ip set address "Ethernet" static 192.168.10.10 255.255.225.0 192.168.10.1 3.shutdown guest 4.Install qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 and boot guest again. nic name: "Ethernet" change to "Ethernet 2" The static ip address disappears and a new ip address is obtained with dhcp. ==Successfully reproduced with qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 ==Verified with qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64 Test Version: kernel-4.18.0-297.el8.x86_64 qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 (upgrade qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64) virtio-win-1.9.15-0.el8.noarch 1. Boot win2016 guest on qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 /usr/libexec/qemu-kvm -name Win2016 \ -M pc-q35-rhel8.2.0,kernel-irqchip=split -m 8G \ -nodefaults \ -cpu Opteron_G5 \ -smp 4,sockets=1,cores=4,threads=1 \ -device pcie-root-port,id=root.1,chassis=1,addr=0x2.0,multifunction=on \ -device pcie-root-port,id=root.2,chassis=2,addr=0x2.1 \ -device pcie-root-port,id=root.3,chassis=3,addr=0x2.2 \ -device pcie-root-port,id=root.4,chassis=4,addr=0x2.3 \ -device pcie-root-port,id=root.5,chassis=5,addr=0x2.4 \ -device pcie-root-port,id=root.6,chassis=6,addr=0x2.5 \ -device pcie-root-port,id=root.7,chassis=7,addr=0x2.6 \ -device pcie-root-port,id=root.8,chassis=8,addr=0x2.7 \ -blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/images/win2016.qcow2,node-name=my_file \ -blockdev driver=qcow2,node-name=my,file=my_file \ -device virtio-blk-pci,drive=my,id=virtio-blk0,bus=root.1 \ -drive id=drive_cd1,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/home/images/en_windows_server_2016_updated_feb_2018_x64_dvd_11636692.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=/usr/share/virtio-win/virtio-win-1.9.15.iso \ -device ide-cd,id=winutils,drive=drive_winutils,bus=ide.1,unit=0 \ -vnc :0 \ -vga qxl \ -monitor stdio \ -usb -device usb-tablet \ -boot menu=on \ -device virtio-net-pci,netdev=nic1,id=vnet0,mac=54:43:00:1a:11:33,bus=root.2 \ -netdev tap,id=nic1,vhost=on \ 2.Configure a static IP address for the nic nic name: Ethernet static ip: netsh interface ip set address "Ethernet" static 192.168.10.10 255.255.225.0 192.168.10.1 3.shutdown guest 4.Install qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64 and boot guest again. nic name: Ethernet The static ip address still exits. 5.So this bug has been fixed very well on qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64. Additional info: Win10 guest test pass
Tested whether resolution setting is affected by this issue for ‘Virtio-Vga’ Test version: kernel-4.18.0-298.el8.x86_64 qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 (upgrade qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 ) virtio-win-1.9.16-2.el8.iso Tested under some situations so it will take some time to read. thanks: Scene 1: Just do upgrade qemu operation(what this bug do): Hit this issue that the resolution setting changed from 800x600 to 1024x768. Test steps: 1.Bootpu guest with following qemu-command-line: /usr/libexec/qemu-kvm -name Win2016 \ -M pc-q35-rhel8.2.0,kernel-irqchip=split -m 8G \ -nodefaults \ -cpu Opteron_G5 \ -smp 4,sockets=1,cores=4,threads=1 \ -device pcie-root-port,id=root.1,chassis=1,addr=0x2.0,multifunction=on \ -device pcie-root-port,id=root.2,chassis=2,addr=0x2.1 \ -device pcie-root-port,id=root.3,chassis=3,addr=0x2.2 \ -device pcie-root-port,id=root.4,chassis=4,addr=0x2.3 \ -device pcie-root-port,id=root.5,chassis=5,addr=0x2.4 \ -device pcie-root-port,id=root.6,chassis=6,addr=0x2.5 \ -device pcie-root-port,id=root.7,chassis=7,addr=0x2.6 \ -device pcie-root-port,id=root.8,chassis=8,addr=0x2.7 \ -blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/home/images/win2016.qcow2,node-name=my_file \ -blockdev driver=qcow2,node-name=my,file=my_file \ -device virtio-blk-pci,drive=my,id=virtio-blk0,bus=root.1 \ -drive id=drive_cd1,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/home/images/en_windows_server_2016_updated_feb_2018_x64_dvd_11636692.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=/usr/share/virtio-win/virtio-win-1.9.15.iso \ -device ide-cd,id=winutils,drive=drive_winutils,bus=ide.1,unit=0 \ -vnc :0 \ -vga qxl \ -monitor stdio \ -usb -device usb-tablet \ -boot menu=on \ -device virtio-net-pci,netdev=nic1,id=vnet0,mac=54:43:00:1a:11:33,bus=root.2 \ -netdev tap,id=nic1,vhost=on \ 2.Configure resolution to ‘800x600’; 3.shutdown guest and upgrade qemu from qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 to qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64; 4.Boot up guest and check the resolution was changed as 1024x768. ----> Hit this issue. 5.and I also did upgrade qemu to fixed version that is qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64, the resolution still was 1024x768. Didn’t change back to original setting ‘800x600’. -------> Fixed version still hit this issue. Scene 2: Do migration on both src/dest host are installed with qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 version. Test steps: 1.Boot up src guest with above qemu-command-line. 2.Configure resolution to ‘800x600’; 3.Boot up dest guest with above qemu-command-line plus “-incoming defer \‘ in the end. 4.Do migration and then check the resolution still was original setting ‘800x600’. -----> Didin’t hit the issue Scene 3: Do migration on src host with qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 and dest host with qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 Test steps: As above. The actual result is the resolution still didn’t change, just the setting as ‘800x600’ ----> Didn’t hit the issue Scene 4: Do migration on src host with qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 and dest host with fixed version qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64 Test steps: As above. The actual result is the resolution still didn’t change, just the setting as ‘800x600’ ----> Didn’t hit the issue
> 5.and I also did upgrade qemu to fixed version that is qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64, the resolution still was 1024x768. Didn’t change back to original setting ‘800x600’. -------> Fixed version still hit this issue. was disk image used in this test in a state after booting it on qemu-kvm-5.2.0-8? > migration you need to reboot/reset guest to pick up new ACPI tables, anyway I'd skip migration testing for this BZ (it doesn't add anything on top of normal boot)
(In reply to Igor Mammedov from comment #39) > > 5.and I also did upgrade qemu to fixed version that is qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64, the resolution still was 1024x768. Didn’t change back to original setting ‘800x600’. -------> Fixed version still hit this issue. > > was disk image used in this test in a state after booting it on > qemu-kvm-5.2.0-8? > yes, I didn't change the disk image during the whole process, so you mean I'd better to create a new disk for testing the fixed qemu version? > > migration > you need to reboot/reset guest to pick up new ACPI tables, anyway I'd skip > migration testing for this BZ (it doesn't add anything on top of normal boot) okay, I just wanna provide some info for driver impact. anyway, please let me know if demand more info or testing.
(In reply to dehanmeng from comment #38) > Tested whether resolution setting is affected by this issue for ‘Virtio-Vga’ > > Test version: > kernel-4.18.0-298.el8.x86_64 > qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 (upgrade > qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 ) > virtio-win-1.9.16-2.el8.iso > > Tested under some situations so it will take some time to read. thanks: > Scene 1: Just do upgrade qemu operation(what this bug do): > Hit this issue that the resolution setting changed from 800x600 to 1024x768. > Test steps: > 1.Bootpu guest with following qemu-command-line: > /usr/libexec/qemu-kvm -name Win2016 \ > -M pc-q35-rhel8.2.0,kernel-irqchip=split -m 8G \ > -nodefaults \ > -cpu Opteron_G5 \ > -smp 4,sockets=1,cores=4,threads=1 \ > -device pcie-root-port,id=root.1,chassis=1,addr=0x2.0,multifunction=on \ > -device pcie-root-port,id=root.2,chassis=2,addr=0x2.1 \ > -device pcie-root-port,id=root.3,chassis=3,addr=0x2.2 \ > -device pcie-root-port,id=root.4,chassis=4,addr=0x2.3 \ > -device pcie-root-port,id=root.5,chassis=5,addr=0x2.4 \ > -device pcie-root-port,id=root.6,chassis=6,addr=0x2.5 \ > -device pcie-root-port,id=root.7,chassis=7,addr=0x2.6 \ > -device pcie-root-port,id=root.8,chassis=8,addr=0x2.7 \ > -blockdev > driver=file,cache.direct=off,cache.no-flush=on,filename=/home/images/win2016. > qcow2,node-name=my_file \ > -blockdev driver=qcow2,node-name=my,file=my_file \ > -device virtio-blk-pci,drive=my,id=virtio-blk0,bus=root.1 \ > -drive > id=drive_cd1,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/ > home/images/en_windows_server_2016_updated_feb_2018_x64_dvd_11636692.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=/usr/share/virtio-win/virtio-win-1.9.15.iso \ > -device ide-cd,id=winutils,drive=drive_winutils,bus=ide.1,unit=0 \ > -vnc :0 \ -device virtio-vga,id=video0 \ > -monitor stdio \ > -usb -device usb-tablet \ > -boot menu=on \ > -device virtio-net-pci,netdev=nic1,id=vnet0,mac=54:43:00:1a:11:33,bus=root.2 > \ > -netdev tap,id=nic1,vhost=on \ > > 2.Configure resolution to ‘800x600’; > 3.shutdown guest and upgrade qemu from > qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 to > qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64; > 4.Boot up guest and check the resolution was changed as 1024x768. ----> > Hit this issue. > 5.and I also did upgrade qemu to fixed version that is > qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64, the resolution still > was 1024x768. Didn’t change back to original setting ‘800x600’. -------> > Fixed version still hit this issue. > > Scene 2: Do migration on both src/dest host are installed with > qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 version. > Test steps: > 1.Boot up src guest with above qemu-command-line. > 2.Configure resolution to ‘800x600’; > 3.Boot up dest guest with above qemu-command-line plus “-incoming defer \‘ > in the end. > 4.Do migration and then check the resolution still was original setting > ‘800x600’. -----> Didin’t hit the issue > > Scene 3: Do migration on src host with > qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 and dest host with > qemu-kvm-5.2.0-8.module+el8.4.0+10093+e085f1eb.x86_64 > Test steps: > As above. > The actual result is the resolution still didn’t change, just the setting > as ‘800x600’ ----> Didn’t hit the issue > > Scene 4: Do migration on src host with > qemu-kvm-4.2.0-47.module+el8.4.0+10269+f1e44e42.x86_64 and dest host with > fixed version qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64 > Test steps: > As above. > The actual result is the resolution still didn’t change, just the setting > as ‘800x600’ ----> Didn’t hit the issue
(In reply to dehanmeng from comment #40) > (In reply to Igor Mammedov from comment #39) > > > 5.and I also did upgrade qemu to fixed version that is qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64, the resolution still was 1024x768. Didn’t change back to original setting ‘800x600’. -------> Fixed version still hit this issue. > > > > was disk image used in this test in a state after booting it on > > qemu-kvm-5.2.0-8? > > > yes, I didn't change the disk image during the whole process, so you mean > I'd better to create a new disk for testing the fixed qemu version? at least boot it on qemu-kvm-4.2.0 first and make sure that resolution is as expected and then shutdown and boot on qemu-kvm-5.2.0-13 to verify. If issue is still present then I suggest to open BZ on respective virtio driver.
(In reply to Igor Mammedov from comment #42) > (In reply to dehanmeng from comment #40) > > (In reply to Igor Mammedov from comment #39) > > > > 5.and I also did upgrade qemu to fixed version that is qemu-kvm-5.2.0-13.module+el8.4.0+10369+fd280775.x86_64, the resolution still was 1024x768. Didn’t change back to original setting ‘800x600’. -------> Fixed version still hit this issue. > > > > > > was disk image used in this test in a state after booting it on > > > qemu-kvm-5.2.0-8? > > > > > yes, I didn't change the disk image during the whole process, so you mean > > I'd better to create a new disk for testing the fixed qemu version? > > at least boot it on qemu-kvm-4.2.0 first and make sure that resolution is as > expected > and then shutdown and boot on qemu-kvm-5.2.0-13 to verify. > If issue is still present then I suggest to open BZ on respective virtio > driver. Thanks for your suggestions, actually the issue still was there with the steps as you mentioned. let me discuss it with developer and I'll back to comment more. thanks again.
Based on comments 33~37. Change to "VERIFIED". Based on comment 42,if issue is still present,please open a new bug.
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 (virt:av bug fix and enhancement update), 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-2021:2098