virtio NICs tend to fail after "shutdown & boot", as no problem for direct reboot.

[R0b1n]

Guys, I found that virtio NICs in a Windows 10 environment tend to fail after "shutdown & boot" as shown in the following illustration.
It looks like OS considers the network drivers are not compatible with the NICs.
But they will be in a good condition if the system just reboot directly.
After the failure, one has to restart (or disable and enable) the failed NICs in order to make them viable again.





Here is the configuration of the corresponding VM:

agent: 1 balloon: 4096 boot: order=scsi0 cores: 2 hotplug: disk,network,usb,memory,cpu machine: pc-i440fx-7.1 memory: 6144 meta: creation-qemu=7.1.0,ctime=1690907670 name: VM-SB-Win10 net0: virtio=B2:AD:D0:4F:F2:7D,bridge=vmbr0,firewall=1 net1: virtio=3E:10:04:6A:A0:6E,bridge=vmbr1,firewall=1 numa: 1 ostype: win10 parent: Freshman scsi0: local-zfs:vm-124-disk-0,discard=on,iothread=1,size=32G scsihw: virtio-scsi-single smbios1: uuid=3ea9ce52-f735-4201-8b2d-46e91f90065a sockets: 1 vcpus: 1 vmgenid: 19a8b827-4874-4f93-a084-8c42f498bb7f

I've tried multiple virtio versions, like version 173, version 225, and the latest stable version 229.
All of them were capable of repeating the same phenomenon.

Who has any idea about what's going on?

 

[Moayad]

Hello,

Does this happen only on one VM, or do all Windows VMs have the same issue?

Did you see anything in the event log in Windows VM to see if there is anything related to the issue?

 

[R0b1n]

Hello,

Does this happen only on one VM, or do all Windows VMs have the same issue?

Did you see anything in the event log in Windows VM to see if there is anything related to the issue?

Thank you for your reminder, Moayad.
I just noticed I have yet checked the windows boot log -- ntbtlog.txt.
Here I enabled the boot log recording.



I've got boot logs in opposite situations -- success & failure as the attachments.
In comparison, there really is not quite much difference between these two files, only to find the failed one has a dxgkrnl.sys not loaded.
But in fact, that's just a direct X graphic driver, having nothing to do with the problematic netkvm.sys, which is loaded successfully according to the boot log.
Actually it feels like the drivers can be correctly loaded, but it cannot be properly enabled.
I get stuck now.
If you have anything that needs me to try out, feel free to tell me.

 

[R0b1n]

Hello,

Does this happen only on one VM, or do all Windows VMs have the same issue?

Did you see anything in the event log in Windows VM to see if there is anything related to the issue?

FYI, this problem really happens in every windows VM.
I've tried many Windows 10 installations, though having not yet tested Windows 11.

 

[Moayad]

Thank you for the information!

Can you also check other Windows ISO image?

Did you enable the `Fast Startup` on the Windows VM?

 

[R0b1n]

Thank you for the information!

Can you also check other Windows ISO image?

Did you enable the `Fast Startup` on the Windows VM?

Yeah, Moayad.
It'd been turned on and seems cannot be turned down.


For Win10, I have tried two different ISO images indeed.

I will check Win11 as soon as possible after I finish my huge backlog

 

[R0b1n]

Thank you for the information!

Can you also check other Windows ISO image?

Did you enable the `Fast Startup` on the Windows VM?

Good news, Moayad.

I have done the test which involved about 10 times of shutdown & boot or direct reboot.

Win11 was doing well and had passed through all trials.

I reckon to migrate my windows VM environment from win10 to win11 in order to shun the aforementioned bug.

As an advice, the bug consistently exists on the win10 platform is still worthy of due attention.

 

[Moayad]

Can I ask you what exactly the ISO image of the Windows 10 you are using, it's a German ISO? From the output of the qm config I guess you are using Proxmox VE 7, can you please post the output of the pveversion -v

 

[R0b1n]

Can I ask you what exactly the ISO image of the Windows 10 you are using, it's a German ISO? From the output of the qm config I guess you are using Proxmox VE 7, can you please post the output of the pveversion -v

I have used several ISOs, most of which are "22H". The latest one is "22H2".
The edition is consistently "Professional".



I have not yet used a German ISO.
I understand why you ask this question.
I've checked the very thread that talked about a virtio bug dealing with a German ISO
I was always using "United States" ISO or "All languages in one" ISO.
The former was used in most situations.
All the ISOs were downloaded from the official website.

Sorry, I forgot to paste the Proxmox version info.
Any of my servers uses either PVE 7.2 or PVE 7.3.

root@c122:~# pveversion -v
proxmox-ve: 7.3-1 (running kernel: 5.15.74-1-pve)
pve-manager: 7.3-3 (running version: 7.3-3/c3928077)
pve-kernel-5.15: 7.2-14
pve-kernel-helper: 7.2-14
pve-kernel-5.15.74-1-pve: 5.15.74-1
ceph-fuse: 15.2.17-pve1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.2
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.2-5
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.2-8
libpve-guest-common-perl: 4.2-3
libpve-http-server-perl: 4.1-5
libpve-storage-perl: 7.2-12
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.0-3
lxcfs: 4.0.12-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.2.7-1
proxmox-backup-file-restore: 2.2.7-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.5.3
pve-cluster: 7.3-1
pve-container: 4.4-2
pve-docs: 7.3-1
pve-edk2-firmware: 3.20220526-1
pve-firewall: 4.2-7
pve-firmware: 3.5-6
pve-ha-manager: 3.5.1
pve-i18n: 2.8-1
pve-qemu-kvm: 7.1.0-4
pve-xtermjs: 4.16.0-1
qemu-server: 7.3-1
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+2
vncterm: 1.7-1
zfsutils-linux: 2.1.6-pve1