No Network Adapter in fresh Windows Server after Upgrade to Proxmox 7

[jj22072020]

Hello, I switched to 6.0 unfortunately without success. The server does not recognize a network adapter

EDIT:
I just installed the English version and it now works without any problems.

i'll just leave it like that

 

[OsvaldoP]

Hy

Looks like the trick with q35 and v6.0 or 5.x does not work anymore with PVE 7.1.10

This is my current solution

System: Windows Server 2019 German
Machine: Default (i440fx) 6.1
Driver: VirtIO 0.1.217
Nic: virtIO

Disk Driver Virtio (2k19)
Disk SCSI
Installed by loading the driver via Windows Installation

After first Login
* Open Devicemanager
** Install Driver for "Ethernet-Controller"
***  Driver: D:\NetKVM\2k19
**** Installation hang with Code 56
** Kill Process "drvinst.exe"
** In Device Manager the Nic is now listet as "Unbekanntes Gerät"
** Install Driver for "Unbekanntes Gerät"
***  Driver: D:\NetKVM\2k19

Nic is now working

Question to Proxmox: Is the change "deault setting windows guest" from i440fx to q35 related to this bug?

Also interessting is that the RedHat Certificates from the driver is outdatet (26.1.2022) => I saw this in mmc -> certificate


kr
Roland

 

[OsvaldoP]

Also successfully testet with PVE 7.2.3 and virtio 0.1.215

 

[jonas.dongowski]

I installed Windows Server 2019 Standard (German edition) on PVE 7.2-3 inside of a i440fx-6.2 virtual machine and got a nic working.

During the Windows Server setup procedure there was no nic present.

After setup I mounted the virtio-win drivers (version 0.1.215) and installed virtio-win-gt-x64.msi to make sure I got most of the drivers.
I then shut down the vm to add a virtio nic to it and booted it up again.
The nic was present in the device manager but faulty (yellow icon, you know the drill).
Here another reboot was required. Took a little while longer but don't worry, it'll be fine.
I selected the nic in the device manager and updated the driver by manually setting it to "[my iso mount point]\NetKVM\2k19\amd64".
Windows tried to tell me it was already using the best driver for this device so I selected it again and "uninstalled the device".
After scanning for new hardware (magnifier on monitor icon inside the device manager's navbar) the nic showed up again without any problems.
From that point on even after unmounting the drivers iso and multiple reboots, the nic keeps working.

I also tried that whole process using version 0.1.217 of the virtio-win drivers but it didn't work. Not even virtio-win-gt-x64.msi ran without problems.

 

[dkbits]

So nobody how solves this win 2019 or 2022. It's really annoying to install all in english and switch then to german with the language pack. So unnecessary this work. Why nobody can fix this?

 

[t.lamprecht]

So nobody how solves this win 2019 or 2022

Windows is proprietary, nobody outside of Microsoft can look at the source for that reason, short of reverse engineering their binaries or hacking around, which may not even be legal and surely not a route we'll take.

Why nobody can fix this?

Ask microsoft why the messed up just by using a specific language..

 

[KMJ]

I run into the same: Windows 2016 RDS Server migrated from VMWare to Proxmox 7.2.5 / virtio-0.1.217. Tried nearly everything from this thread, incl. some other, reimported 120gb x-times, sitting for 8 hours without Nic now. Looks like i need to go back to VMWare with this one. Not good.........

 

[KMJ]

SOLVED:
- reimport disk
- ide hdu
- set to q35 6.0, no network card to see it comes up -> YES
- gerätemanager show absent devices -> delete old e1000
- uninstall vmware tools
- install virtio full 215
- shutdown
- add virtio network card
- boot and found network

pffffffffffffffffffffffffffffff

 

[reschm]

Had the same issue on a fresh Windows 10 Pro guest installation on a fresh installed Proxmox 7.2-3.
Finally switched to virtio network, deinstalled the interface in Windows (incl. drivers) and reinstalled the drivers with virtio-win-0.1.208 (https://fedorapeople.org/groups/vir...ownloads/archive-virtio/virtio-win-0.1.208-1/)

Now my Windows is connected to the network

 

[DasMoritz]

Hi,

yes, that works @reschm!
I've done the following steps:

1.) Install Windows 10
2.) Switch off the fresh installed VM
3.) Mount the virtio win 01.208.1 iso from the above called link
4.) Install the VirtIo drivers (I got an error the first time, I think because I've used the x86 Installer and not the x64 Installer)
5.) Restart, everything is fine.

 

[RolandK]

upstream bug reports at

https://github.com/virtio-win/kvm-guest-drivers-windows/issues/750

and

https://gitlab.com/qemu-project/qemu/-/issues/774

please somebody report that error to microsoft.

if more people complain, maybe the problem will get resolved. qemu people say it's a microsoft problem. i'm not really sure...but things won't move forward if microsoft will not get involved.

 

[RolandK]

the problem seems to be resolved with latest qemu 7.2 from pvetest repo. maybe somebody who has system with pvetest repo enabled can test with win 20xx and confirm ?

 

[andy77]

We can confirm that the QEMU Version 7.2.0-5 fixed the network problem in Windows 2016 and 2022.

@tom Can you tell me when we can expect QEMU 7.2.0-5 to be in pve-enterprise repo?

 

[t.lamprecht]

FYI: QEMU 7.2 has been made available on no-subscription just as of now.

While we understand that all of you can't wait until this unpleasant behavior is finally solved, it's still a major new release of a core package, and such we'd like to give it much broader visibility for a few weeks before we'll move it to enterprise.

Please note that if you already tested your workload on the new version in some test bed, and found no regression for your HW and use case, you can always enable the no-subscription repository (e.g., through the Web UI) temporarily and then pull in only the new QEMU 7.2 update by issuing:

apt update
apt install pve-qemu-kvm

Remember to disable the no-subscription repository afterwards again.

 

[tomoe]

FYI: QEMU 7.2 has been made available on no-subscription just as of now.

While we understand that all of you can't wait until this unpleasant behavior is finally solved, it's still a major new release of a core package, and such we'd like to give it much broader visibility for a few weeks before we'll move it to enterprise.

Please note that if you already tested your workload on the new version in some test bed, and found no regression for your HW and use case, you can always enable the no-subscription repository (e.g., through the Web UI) temporarily and then pull in only the new QEMU 7.2 update by issuing:

apt update
apt install pve-qemu-kvm

Remember to disable the no-subscription repository afterwards again.

@t.lamprecht thanks for your advice.
For me, this behavior isn't fixed with QEMU 7.2.
I have tried all the mentioned versions from this thread, but can't find a suitable way for me.
What other ideas are there?

My current setup is my initial setup. Several VMs (Geman-ISO-Win10/SRV2k19) with i440fx-6.1 and VirtIO.
The curious thing is that I get a DHCP address that I can ping externally, but not internally. As soon as I set it to static, nothing works. The problem occurs since a reboot of my VMs.

Best regards
Torben

 

[RolandK]

@t.lamprecht thanks for your advice.
For me, this behavior isn't fixed with QEMU 7.2.
I have tried all the mentioned versions from this thread, but can't find a suitable way for me.
What other ideas are there?

My current setup is my initial setup. Several VMs (Geman-ISO-Win10/SRV2k19) with i440fx-6.1 and VirtIO.
The curious thing is that I get a DHCP address that I can ping externally, but not internally. As soon as I set it to static, nothing works. The problem occurs since a reboot of my VMs.

Best regards
Torben

did the VMs have that problem before qemu 7.2 ?

iirc, the problem gets inherited if it happened before qemu 7.2

so you may need to entirely remove networking and re-add after qemu 7.2. (not sure, though)

 

[tomoe]

did the VMs have that problem before qemu 7.2 ?

iirc, the problem gets inherited if it happened before qemu 7.2

so you may need to entirely remove networking and re-add after qemu 7.2. (not sure, though)

I guess not, but I'm not sure.
What do you mean exactly with

so you may need to entirely remove networking and re-add after qemu 7.2.

I deleted every single network device from each vm and re-added. I uninstalled all drivers and tried different versions.
I have no more ideas...
BR

 

[_gabriel]

known bug with German version before QEMU 7.2 is there is not network device at all in the control panel / ncpa.cpl,
I'm not sure your problem is related.
Have you tried with the regular E1000 ?
Have you tried with an us/english version ?

edit: correction : driver in device manager can be properly installed, but ncpa.cpl has no devices.

 

[tomoe]

known bug with German version before QEMU 7.2 is there is not network device at all in the control panel / ncpa.cpl,
device manager can't use the virtio driver.
I'm not sure your problem is related.
Have you tried with the regular E1000 ?
Have you tried with an us/english version ?

My problem seems to be in context with this issue.
I am only using German ISOs.
Using E1000 doesn't bring any improvements.

I haven't tried with us version at this moment because it might be a workaround but not a solution.

Is here anybody who can help?

BR

 

[_gabriel]

you must try with us version to confirm.