kvm-guest-drivers-windows
kvm-guest-drivers-windows copied to clipboard
virtio-win
No network adapter in Windows 2016/2019/10 VM on Proxmox 7 using network drivers from virtio iso 0.1.215
Describe the bug If a new virtio network adapter (or a new VM with such a networkadapter) is created on the host OS Proxmox Virtualization Environment 7 and the guest OS is either Windows Server 2016, 2019 or Windows 10 and the Windows ISO used is a german version (not sure if it affects all non english languages) and the network driver comes from the virtio 0.1.215 ISO no network adapter is created in the guest OS. The device in device manager is stuck in 'Windows is still setting up the class configuration for this device. (Code 56)'. As long as the device is in this state drivers cannot be removed or replaced and no network adapter is created.
There is a long thread on the german Proxmox forum describing the issue, it seems to be affecting everyone using the described components with german versions of Windows.
According to other users there are several ways to fix the issue:
- Install Windows from english ISO (wasn't an option)
- Install english language pack in german Windows (wasn't an option)
- Wait for code 56 state to disappear from network adapter, delete driver, reinstall driver (can't verify as code 56 wouldn't disappear for me even after 10 minutes)
- Remove driver from 0.1.215, install driver from 0.1.185 (worked for me)
To Reproduce Steps to reproduce the behaviour:
- Create VM on Proxmox 7 for Windows 2016/2019/10 with VirtIO or Intel network adapter
- Install Windows 2016/2019 or Windows 10 from german ISO
- Install virtio network drivers from 0.1.215 ISO
Reportedly it never happens on Proxmox 6 and it doesn't restrospectively affect network adapters created before the host was upgraded to Proxmox 7, it just affects adapters created on Proxmox 7.
Expected behavior The network device to not be in code 56 state and a network adapter to appear
Host:
- Disto: Proxmox 7.1-7
- Kernel version: 5.13.19-2-pve
- QEMU version: pve-qemu-kvm_6.1.0
VM:
- Windows version: Windows Server 2019 DE
- Which driver has a problem: netkvm
- Driver version: 100.90.104.21500
Looks like duplicated issue: https://github.com/virtio-win/kvm-guest-drivers-windows/issues/745
Hi @weubach , Do I understand correctly that the previous versions of Proxmox work and 215 driver don't have any issues?
Hi @YanVugenfirer, @weubach
I tested clean QEMU and can't reproduce this issue.
My env:
- QEMU version: v5.2.0, v6.1.0 (both from upstream)
- Windows Server 2019 German version
- Driver version: 100.90.104.21500 (virtio-win-0.1.215.iso)
I had these effects also in non-Proxmox environments using CentOS 8 Stream within the last three till four months. For me, it was not a virtio issue as I assumed first (Error 56 on driver install) as these effects are the same when using an emulated Intel e1000. However, the problem went away with the last round of updates within the last two weeks.
I also had this effect using GNOME Boxes on Fedora 35 (my laptop).
@weubach
Can you post setupapi.dev.log files ( https://docs.microsoft.com/en-us/windows-hardware/drivers/install/setupapi-logging--windows-vista-and-later- ) for drivers version 0.1.215 and 0.1.185 ?
Hi @andreashaerter,
Do you have any non-Proxmox environments where you can reproduce this issue now?
If yes, please post the OS distributive, OS version, kernel version, QEMU version, and virtio-win drivers version.
@kostyanf14 I ended up here by accident / having notifications for virtio. Sorry for the non-sufficient data. Will try to collect as musch as possible.
But at least a starting point: <type arch='x86_64' machine='pc-q35-rhel7.6.0'>hvm</type> on the CentOS 8 Stream systems everything works fine now have the following versions:
# dnf list qemu-kvm libvirt virt-install virtio-win
Last metadata expiration check: 1:05:37 ago on Thu Mar 24 16:04:37 2022.
Installed Packages
libvirt.x86_64 8.0.0-2.module_el8.6.0+1087+b42c8331 @appstream
qemu-kvm.x86_64 15:6.2.0-5.module_el8.6.0+1087+b42c8331 @appstream
virt-install.noarch 3.2.0-3.el8 @appstream
virtio-win.noarch 1.9.24-2.el8_5 @appstream
# cat /etc/redhat-release
CentOS Stream release 8
# uname -r
4.18.0-365.el8.x86_64
With these current updates, the problem is not reproducible for me anymore. Machine type was always <type arch='x86_64' machine='pc-q35-rhel7.6.0'>hvm</type>.
Going to search for affected version now.
Affected on my Laptop:
- Windows 10 Pro (
Win10_21H2_German_x64.iso, SHA1e0492d3e3f1f3f499e4fc2e62765bb03cadf4bf6, SHA-25653b160d0b34aec937d9f23da2a0e66b4786ee07df8d34ee716c9ca8a968523ab) - with
<type arch="x86_64" machine="pc-q35-6.1">hvm</type> - Bridged or usermode networking
- with e1000 or virtio NIC
I created the VM roughly two weeks ago. However, even with the current updates, the problem did not went away (like it did on CentOS 8 stream, cf. comment above.. .cannot reproduce it there anymore). Currently installed versions:
$ dnf list qemu-kvm libvirt virt-install virtio-win
Installed Packages
qemu-kvm.x86_64 2:6.1.0-14.fc35 @updates
virtio-win.noarch 0.1.215-2 @virtio-win-stable
Available Packages
libvirt.x86_64 7.6.0-5.fc35 updates
virt-install.noarch 3.2.0-4.fc35 fedora
$ uname -a
Linux fedora 5.16.16-200.fc35.x86_64 #1 SMP PREEMPT Sat Mar 19 13:52:41 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/redhat-release
Fedora release 35 (Thirty Five)
I just created a fresh VM install and the problem still occurs on the new VM like it does on the already existing one:
Additional note: the thread mentioned by @weubach probably is https://forum.proxmox.com/threads/no-network-adapter-in-fresh-windows-server-after-upgrade-to-proxmox-7.92094/
Hi @weubach , Do I understand correctly that the previous versions of Proxmox work and 215 driver don't have any issues?
@YanVugenfirer @kostyanf14 Hi. I've just tested it on the same VM again by removing and deleting the 18500 driver, shutdown, removing the device, adding a new device and installing the driver again. While installing the 18500 driver again the driver install dialogue ran into a timeout. When I repeated the install process it was successful. Removed and deleted the 18500 driver again, shutdown, removed the device, added a new device and installed the 21500 driver. Ran into a timeout. Tried again, this time the new driver was installed successfully too. Never got code 56.
I'm sorry if I made someone investigate for nothing, I'll set up fresh Proxmox 6 & 7 servers as soon as I find a bit of spare time and try to reproduce everything again with different driver versions, install methods (wizard/manual) and english/german Windows media. When I first encountered the issue I didn't have much time to dig deep.
Hi @andreashaerter,
I installed clean Fedora 35 and I can't reproduce this bug, but I run QEMU directly without Libvirt. So, possible that some other flag generates this issue.
Can you please post full Libvirt XML and I will try to use absolutely the same setup?
Sure. The following is the affected testbox was created with GNOME Boxes on Fedora 35, the ISO came from Microsoft, cf. https://www.microsoft.com/de-de/software-download/windows10ISO (just download the German one):
$ dnf list qemu-kvm libvirt virt-install virtio-win
Installed Packages
qemu-kvm.x86_64 2:6.1.0-14.fc35 @updates
virtio-win.noarch 0.1.215-2 @virtio-win-stable
Available Packages
libvirt.x86_64 7.6.0-5.fc35 updates
virt-install.noarch 3.2.0-4.fc35 fedora
$ uname -a
Linux fedora 5.16.16-200.fc35.x86_64 #1 SMP PREEMPT Sat Mar 19 13:52:41 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/redhat-release
Fedora release 35 (Thirty Five)
The XML is as follows:
<domain type="kvm">
<name>win10-2</name>
<uuid>77dd2a83-f171-41e8-895c-ed54e562a57c</uuid>
<title>Microsoft Windows 10 2</title>
<metadata>
<boxes:gnome-boxes xmlns:boxes="https://wiki.gnome.org/Apps/Boxes">
<os-state>installed</os-state>
<media-id>http://microsoft.com/win/10:9</media-id>
<media>/home/user/Downloads/Win10_21H2_German_x64.iso</media>
</boxes:gnome-boxes>
<libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
<libosinfo:os id="http://microsoft.com/win/10"/>
</libosinfo:libosinfo>
</metadata>
<memory unit="KiB">2097152</memory>
<currentMemory unit="KiB">2097152</currentMemory>
<vcpu placement="static">4</vcpu>
<os>
<type arch="x86_64" machine="pc-q35-6.1">hvm</type>
<boot dev="hd"/>
<bootmenu enable="no"/>
</os>
<features>
<acpi/>
<apic/>
</features>
<cpu mode="host-passthrough" check="none" migratable="on">
<topology sockets="1" dies="1" cores="4" threads="1"/>
</cpu>
<clock offset="localtime">
<timer name="rtc" tickpolicy="catchup"/>
<timer name="pit" tickpolicy="delay"/>
<timer name="hpet" present="no"/>
</clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<pm>
<suspend-to-mem enabled="no"/>
<suspend-to-disk enabled="no"/>
</pm>
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<disk type="file" device="disk">
<driver name="qemu" type="qcow2" cache="writeback" discard="unmap"/>
<source file="/home/user/.local/share/gnome-boxes/images/win10-2"/>
<target dev="vda" bus="virtio"/>
<address type="pci" domain="0x0000" bus="0x03" slot="0x00" function="0x0"/>
</disk>
<disk type="file" device="cdrom">
<driver name="qemu" type="raw"/>
<target dev="hdc" bus="sata"/>
<readonly/>
<address type="drive" controller="0" bus="0" target="0" unit="2"/>
</disk>
<controller type="usb" index="0" model="qemu-xhci" ports="15">
<address type="pci" domain="0x0000" bus="0x02" slot="0x00" function="0x0"/>
</controller>
<controller type="sata" index="0">
<address type="pci" domain="0x0000" bus="0x00" slot="0x1f" function="0x2"/>
</controller>
<controller type="pci" index="0" model="pcie-root"/>
<controller type="virtio-serial" index="0">
<address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/>
</controller>
<controller type="ccid" index="0">
<address type="usb" bus="0" port="1"/>
</controller>
<controller type="pci" index="1" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="1" port="0x10"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0" multifunction="on"/>
</controller>
<controller type="pci" index="2" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="2" port="0x11"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x1"/>
</controller>
<controller type="pci" index="3" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="3" port="0x12"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x2"/>
</controller>
<controller type="pci" index="4" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="4" port="0x13"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x3"/>
</controller>
<controller type="pci" index="5" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="5" port="0x14"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x4"/>
</controller>
<controller type="pci" index="6" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="6" port="0x15"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x5"/>
</controller>
<interface type="bridge">
<mac address="52:54:00:4c:d3:c4"/>
<source bridge="virbr0"/>
<model type="virtio"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
<smartcard mode="passthrough" type="spicevmc">
<address type="ccid" controller="0" slot="0"/>
</smartcard>
<serial type="pty">
<target type="isa-serial" port="0">
<model name="isa-serial"/>
</target>
</serial>
<console type="pty">
<target type="serial" port="0"/>
</console>
<channel type="spiceport">
<source channel="org.spice-space.webdav.0"/>
<target type="virtio" name="org.spice-space.webdav.0"/>
<address type="virtio-serial" controller="0" bus="0" port="1"/>
</channel>
<channel type="spicevmc">
<target type="virtio" name="com.redhat.spice.0"/>
<address type="virtio-serial" controller="0" bus="0" port="2"/>
</channel>
<input type="tablet" bus="usb">
<address type="usb" bus="0" port="2"/>
</input>
<input type="mouse" bus="ps2"/>
<input type="keyboard" bus="ps2"/>
<graphics type="spice">
<listen type="none"/>
<image compression="off"/>
<gl enable="no"/>
</graphics>
<sound model="ich9">
<address type="pci" domain="0x0000" bus="0x00" slot="0x1b" function="0x0"/>
</sound>
<audio id="1" type="spice"/>
<video>
<model type="qxl" ram="65536" vram="65536" vgamem="16384" heads="1" primary="yes">
<acceleration accel3d="no"/>
</model>
<address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
</video>
<redirdev bus="usb" type="spicevmc">
<address type="usb" bus="0" port="3"/>
</redirdev>
<redirdev bus="usb" type="spicevmc">
<address type="usb" bus="0" port="4"/>
</redirdev>
<redirdev bus="usb" type="spicevmc">
<address type="usb" bus="0" port="5"/>
</redirdev>
<redirdev bus="usb" type="spicevmc">
<address type="usb" bus="0" port="6"/>
</redirdev>
<memballoon model="virtio">
<address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
</memballoon>
</devices>
</domain>
The XML of the VM on CentOS 8 Stream which made problems but works now (no XML changes, just package updates) after reinstalling Windows (I just stripped the VM name for privacy reasons)
<domain type='kvm' id='7'>
<name><stripped machine name</name>
<uuid>8c519857-511d-4b04-8f21-7c202238f94e</uuid>
<description>Windows Server Standard 2019 64 bit</description>
<metadata>
<libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
<libosinfo:os id="http://microsoft.com/win/2k19"/>
</libosinfo:libosinfo>
</metadata>
<memory unit='KiB'>8388608</memory>
<currentMemory unit='KiB'>8388608</currentMemory>
<vcpu placement='static'>4</vcpu>
<resource>
<partition>/machine</partition>
</resource>
<os>
<type arch='x86_64' machine='pc-q35-rhel7.6.0'>hvm</type>
<bootmenu enable='yes'/>
</os>
<features>
<acpi/>
<apic/>
<hyperv mode='custom'>
<relaxed state='on'/>
<vapic state='on'/>
<spinlocks state='on' retries='8191'/>
<synic state='on'/>
<stimer state='on'/>
</hyperv>
<vmport state='off'/>
</features>
<cpu mode='custom' match='exact' check='full'>
<model fallback='forbid'>Cascadelake-Server</model>
<vendor>Intel</vendor>
<topology sockets='1' dies='1' cores='4' threads='1'/>
<feature policy='require' name='ss'/>
<feature policy='require' name='vmx'/>
<feature policy='require' name='pdcm'/>
<feature policy='require' name='hypervisor'/>
<feature policy='require' name='tsc_adjust'/>
<feature policy='require' name='umip'/>
<feature policy='require' name='pku'/>
<feature policy='require' name='md-clear'/>
<feature policy='require' name='stibp'/>
<feature policy='require' name='arch-capabilities'/>
<feature policy='require' name='xsaves'/>
<feature policy='require' name='ibpb'/>
<feature policy='require' name='ibrs'/>
<feature policy='require' name='amd-stibp'/>
<feature policy='require' name='amd-ssbd'/>
<feature policy='require' name='rdctl-no'/>
<feature policy='require' name='ibrs-all'/>
<feature policy='require' name='skip-l1dfl-vmentry'/>
<feature policy='require' name='mds-no'/>
<feature policy='require' name='pschange-mc-no'/>
<feature policy='require' name='tsx-ctrl'/>
<feature policy='disable' name='hle'/>
<feature policy='disable' name='rtm'/>
</cpu>
<clock offset='localtime'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='no'/>
<timer name='hypervclock' present='yes'/>
</clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<pm>
<suspend-to-mem enabled='no'/>
<suspend-to-disk enabled='no'/>
</pm>
<devices>
<emulator>/usr/libexec/qemu-kvm</emulator>
<disk type='file' device='cdrom'>
<driver name='qemu'/>
<target dev='sda' bus='sata'/>
<readonly/>
<alias name='sata0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none' io='native'/>
<source dev='/dev/vg01/<stripped machine name>-system' index='1'/>
<backingStore/>
<target dev='vda' bus='virtio'/>
<boot order='1'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</disk>
<controller type='usb' index='0' model='qemu-xhci' ports='15'>
<alias name='usb'/>
<address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
</controller>
<controller type='sata' index='0'>
<alias name='ide'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
</controller>
<controller type='pci' index='0' model='pcie-root'>
<alias name='pcie.0'/>
</controller>
<controller type='pci' index='1' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='1' port='0x10'/>
<alias name='pci.1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
</controller>
<controller type='pci' index='2' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='2' port='0x11'/>
<alias name='pci.2'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
</controller>
<controller type='pci' index='3' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='3' port='0x12'/>
<alias name='pci.3'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
</controller>
<controller type='pci' index='4' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='4' port='0x13'/>
<alias name='pci.4'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
</controller>
<controller type='pci' index='5' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='5' port='0x14'/>
<alias name='pci.5'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
</controller>
<controller type='pci' index='6' model='pcie-root-port'>
<model name='pcie-root-port'/>
<target chassis='6' port='0x15'/>
<alias name='pci.6'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
</controller>
<controller type='virtio-serial' index='0'>
<alias name='virtio-serial0'/>
<address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
</controller>
<interface type='direct'>
<mac address='52:54:00:f3:d6:d4'/>
<source dev='team0-vlan2020' mode='bridge'/>
<target dev='macvtap6'/>
<model type='virtio'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
</interface>
<serial type='pty'>
<source path='/dev/pts/6'/>
<target type='isa-serial' port='0'>
<model name='isa-serial'/>
</target>
<alias name='serial0'/>
</serial>
<console type='pty' tty='/dev/pts/6'>
<source path='/dev/pts/6'/>
<target type='serial' port='0'/>
<alias name='serial0'/>
</console>
<channel type='spicevmc'>
<target type='virtio' name='com.redhat.spice.0' state='disconnected'/>
<alias name='channel0'/>
<address type='virtio-serial' controller='0' bus='0' port='1'/>
</channel>
<input type='tablet' bus='usb'>
<alias name='input0'/>
<address type='usb' bus='0' port='1'/>
</input>
<input type='mouse' bus='ps2'>
<alias name='input1'/>
</input>
<input type='keyboard' bus='ps2'>
<alias name='input2'/>
</input>
<graphics type='spice' port='5906' autoport='yes' listen='127.0.0.1'>
<listen type='address' address='127.0.0.1'/>
<image compression='off'/>
</graphics>
<sound model='ich9'>
<alias name='sound0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
</sound>
<audio id='1' type='spice'/>
<video>
<model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/>
<alias name='video0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
</video>
<redirdev bus='usb' type='spicevmc'>
<alias name='redir0'/>
<address type='usb' bus='0' port='2'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
<alias name='redir1'/>
<address type='usb' bus='0' port='3'/>
</redirdev>
<memballoon model='virtio'>
<alias name='balloon0'/>
<address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
</memballoon>
</devices>
<seclabel type='dynamic' model='selinux' relabel='yes'>
<label>system_u:system_r:svirt_t:s0:c878,c987</label>
<imagelabel>system_u:object_r:svirt_image_t:s0:c878,c987</imagelabel>
</seclabel>
<seclabel type='dynamic' model='dac' relabel='yes'>
<label>+107:+107</label>
<imagelabel>+107:+107</imagelabel>
</seclabel>
</domain>
Hi @andreashaerter,
Thanks very much. Libvirt XML helped. I reproduced the issue. Will investigate and update this thread.
Hi @andreashaerter, @weubach,
Please look at my comment in other issue https://github.com/virtio-win/kvm-guest-drivers-windows/issues/745#issuecomment-1083121917
the problem of "Windows is still setting up the class configuration for this device. (Code 56)'." also exists with e1000 and rtl8139 driver type.
also see https://forum.manjaro.org/t/network-adapter-error-56-with-windows-10-as-guest-under-qemu-kvm/88892 , as a confirmation of this:
"When using Windows 10 in a virtual machine, the network adapter does not work." "I think it is a categorical problem, since using a USB ethernet adapter and using USB passthrought to directly “connect” it to the virtual machine leads to the same problem. So it seems that no matter what network adapter (virtual or physical) I give the virtual machine, it always has this “code 56” issue"
here is one more report that it general and not virtio specific problem: https://forum.proxmox.com/threads/no-network-adapter-in-fresh-windows-server-after-upgrade-to-proxmox-7.92094/post-460395
"Small update, related issue on Github: https://github.com/virtio-win/kvm-guest-drivers-windows/issues/750 - I posted an affected non-Proxmox environment there (Github user andreashaerter). As I get the same effect with e1000, i still guess it is not a virtio problem."
There is a long thread on the german Proxmox forum describing the issue, it seems to be affecting everyone using the described components with german versions of Windows.
yes, probably this one: https://forum.proxmox.com/threads/no-network-adapter-in-fresh-windows-server-after-upgrade-to-proxmox-7.92094/
@devZer0 I suggest to open support ticket. It looks like a general issue with German Windows and NICs.
https://answers.microsoft.com/en-us/windows/forum/all/network-adapters-not-working-code-56/381f4ed4-ab40-4b10-8606-f5231384bc88
@YanVugenfirer i just contacted our microsoft distributor for that (as microsoft does not like our input) and also opened a bugreport upstream, asking for help: https://gitlab.com/qemu-project/qemu/-/issues/774
just wondering why nobody already did report it to microsoft
This issue is not related to QEMU. There are reports online for physical NICs as well
yes, but the problem is triggered within qemu environment and some hardware change is causing it.
to narrow down the problem it would be helpful if we knew what exact hardware change in qemu is triggering this problem.
it's more helpful to do fingerpointing to the exact problem instead of fingerpointing in an "it's not us - it's them" style at organisation level.
Microsoft won't let me report a bug and my distributor tells that Win10 is a "On-Premise Product" and that only gets support via paid service and they would charge 370 Euro/hour for that. 😂🙈
I was recommended to report the issue via Feedback Hub from within Win10, which i did.
This it the link to it: https://aka.ms/AAil0lm
Apparently you need Win10 to have access to that link, it won't open in browser but needs the Feedback Hub App.
@YanVugenfirer , can you point us to real-world-machine/nic bugreport references , proving that this is a general issue?
i'm not really sure if this is alone a microsoft problem/issue. all reports i find are related to installation issues when there is hyper-v installed or some vpn software
@devZer0 While there is (or was) VPN SW in the link @kostyanf14 found, the error code is with the miniport driver as well: https://github.com/virtio-win/kvm-guest-drivers-windows/issues/750#issuecomment-1293161971
i have news for this
on proxmox 6.4 with qemu 5.2.0 , adding e1000 virtio network adapter to a win10 VM of machine type pc-i440fx-5.2 actually WORKS, i.e. i installed win10 without network adapter, rebooted and then added network adapter (via hot plug, driver immidiately attaches and initializes sucessfully. same for e1000 and also for virtio, when guest-additions have been installed before. NO error code 56/ hang at initialization)
after rolling back to the snapshot made after win10 installation (without any nic attached) and copying this virtual machine (qcow2 + vmid.conf) to a proxmox 7.0 system with qemu 6.0.0 , the problem appears (error code 56). i did not change vm machine type pc-i44fx-5.2 to something different.
so , this is NOT a windows problem alone, as windows shows different behaviour on different qemu versions, without changing anything with the virtual hardware.
apparently pc-i440fx-5.2 on qemu 5.2 does NOT behave the same as on qemu 6.0
the problem must have been introduced between qemu 5.2 and 6.0 then.
think we need to git-bisect to get into the details...
Hello, I have a workaround for this problem without installing a language pack or using a english DVD. These screenshots are from a imported Windows Server 2016 Datacenter Edition after importing it from vSphere:
Mount virtio-win iso 0.1.225:
Start the installer:
Uncheck Network:
Rightklick Ethernet-Controller:
Wait some Minutes until it fails: (~4)
Rightklick Unbekanntes Gerät:
Tada:
