Probleme mit Redhat VirtIO-Netzwerk-Adapter nach Host-Update/Neustart in Windows 10

[mscd]

Hallo zusammen,

ich beobachte derzeit (aktuelle Updates Proxmox 6.3) folgendes Problem:

Nach einem Reboot des Proxmox VE Hosts (z.B. Kernel-Update) erhalten alle dort laufenden Windows 2016 Server "neue" Netzwerk-Interfaces, was zu dem Problem führt, dass die alten (mit statischen IP-Adressen konfigurierten) nicht mehr funktionieren und ich einmalig im Windows Gast das neue Interface "Redhat VirtIO NIC Nr. 2" dann neu konfigurieren muss.

Hat jemand einen Tipp woran das liegen kann? Die Konfiguration der VMs (bsp. Mac-Adressen, usw.) bleibt unverändert.

Schöne Grüße und Dank,
mscd

 

[tom]

Bitte die genaue version posten, sollte eigentlich nicht vorkommen:

> pveversion -v

und eine VM configurartion:

> qm config ID

 

[mscd]

root@pve-hp1:~# pveversion -v
proxmox-ve: 6.3-1 (running kernel: 5.4.106-1-pve)
pve-manager: 6.3-6 (running version: 6.3-6/2184247e)
pve-kernel-5.4: 6.3-8
pve-kernel-helper: 6.3-8
pve-kernel-5.4.106-1-pve: 5.4.106-1
pve-kernel-5.4.101-1-pve: 5.4.101-1
pve-kernel-5.4.78-2-pve: 5.4.78-2
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.1.2-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: residual config
ifupdown2: 3.0.0-1+pve3
libjs-extjs: 6.0.1-10
libknet1: 1.20-pve1
libproxmox-acme-perl: 1.0.8
libproxmox-backup-qemu0: 1.0.3-1
libpve-access-control: 6.1-3
libpve-apiclient-perl: 3.1-3
libpve-common-perl: 6.3-5
libpve-guest-common-perl: 3.1-5
libpve-http-server-perl: 3.1-1
libpve-storage-perl: 6.3-9
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.6-2
lxcfs: 4.0.6-pve1
novnc-pve: 1.1.0-1
proxmox-backup-client: 1.1.1-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.5-1
pve-cluster: 6.2-1
pve-container: 3.3-4
pve-docs: 6.3-1
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-3
pve-firmware: 3.2-2
pve-ha-manager: 3.1-1
pve-i18n: 2.3-1
pve-qemu-kvm: 5.2.0-5
pve-xtermjs: 4.7.0-3
qemu-server: 6.3-10
smartmontools: 7.2-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 2.0.4-pve1
root@pve-hp1:~#

und

root@pve-hp1:~# qm config 201
agent: 1
bios: ovmf
boot: order=scsi0
cores: 2
memory: 4096
name: DC1-Verwaltung
net0: virtio=32:55:FE:65:73:5B,bridge=vmbr0,tag=131
numa: 0
onboot: 1
ostype: win10
scsi0: hp1_r10_8tb-vms2:201/vm-201-disk-0.qcow2,size=100G
scsihw: virtio-scsi-pci
smbios1: uuid=523a22ef-e7d9-465d-b649-74f62c29bd5c
sockets: 1
startup: order=1
vmgenid: a0991a38-8670-4013-80b7-51481b78da6c
root@pve-hp1:~#

Danke!

 

[t.lamprecht]

Hi!

Kannst du bitte auch den Output von qm showcmd 201 --pretty posten?

Nach einem Reboot des Proxmox VE Hosts (z.B. Kernel-Update) erhalten alle dort laufenden Windows 2016 Server "neue" Netzwerk-Interfaces, was zu dem Problem führt, dass die alten (mit statischen IP-Adressen konfigurierten) nicht mehr funktionieren und ich einmalig im Windows Gast das neue Interface "Redhat VirtIO NIC Nr. 2" dann neu konfigurieren muss.

Hat jemand einen Tipp woran das liegen kann? Die Konfiguration der VMs (bsp. Mac-Adressen, usw.) bleibt unverändert.

Grundsätzlich gab es da genau so ein Problem mit QEMU 5.2, da die Version die Vergabe von ACPI IDs so geändert hat das diese nun standardkonform ist. Das Problem wurde aber eigentlich gelöst bevor die 5.2 QEMU Version nach Enterprise geschoben wurde. Windows VMs werden jetzt immer auf eine "QEMU machine version" gepinnt, entweder auf die aktuelle bei neuen VMs oder auf 5.1 bei bestehenden VMs, zur Kompatibilität.

 

[mscd]

no efidisk configured! Using temporary efivars disk.
/usr/bin/kvm \
-id 201 \
-name DC1-Verwaltung \
-no-shutdown \
-chardev 'socket,id=qmp,path=/var/run/qemu-server/201.qmp,server,nowait' \
-mon 'chardev=qmp,mode=control' \
-chardev 'socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5' \
-mon 'chardev=qmp-event,mode=control' \
-pidfile /var/run/qemu-server/201.pid \
-daemonize \
-smbios 'type=1,uuid=523a22ef-e7d9-465d-b649-74f62c29bd5c' \
-drive 'if=pflash,unit=0,format=raw,readonly,file=/usr/share/pve-edk2-firmware//OVMF_CODE.fd' \
-drive 'if=pflash,unit=1,format=raw,id=drive-efidisk0,size=131072,file=/tmp/201-ovmf.fd' \
-smp '2,sockets=1,cores=2,maxcpus=2' \
-nodefaults \
-boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' \
-vnc unix:/var/run/qemu-server/201.vnc,password \
-no-hpet \
-cpu 'kvm64,enforce,hv_ipi,hv_relaxed,hv_reset,hv_runtime,hv_spinlocks=0x1fff,hv_stimer,hv_synic,hv_time,hv_vapic,hv_vpindex,+kvm_pv_eoi,+kvm_pv_unhalt,+lahf_lm,+sep' \
-m 4096 \
-device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' \
-device 'pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f' \
-device 'vmgenid,guid=a0991a38-8670-4013-80b7-51481b78da6c' \
-device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' \
-device 'usb-tablet,id=tablet,bus=uhci.0,port=1' \
-device 'VGA,id=vga,bus=pci.0,addr=0x2' \
-chardev 'socket,path=/var/run/qemu-server/201.qga,server,nowait,id=qga0' \
-device 'virtio-serial,id=qga0,bus=pci.0,addr=0x8' \
-device 'virtserialport,chardev=qga0,name=org.qemu.guest_agent.0' \
-device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' \
-iscsi 'initiator-name=iqn.1993-08.org.debian:01:91685c575c74' \
-device 'virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5' \
-drive 'file=/var/vms2/images/201/vm-201-disk-0.qcow2,if=none,id=drive-scsi0,format=qcow2,cache=none,aio=native,detect-zeroes=on' \
-device 'scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100' \
-netdev 'type=tap,id=net0,ifname=tap201i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' \
-device 'virtio-net-pci,mac=32:55:FE:65:73:5B,netdev=net0,bus=pci.0,addr=0x12,id=net0' \
-rtc 'driftfix=slew,base=localtime' \
-machine 'type=pc-i440fx-5.1+pve0' \
-global 'kvm-pit.lost_tick_policy=discard'

 

[t.lamprecht]

-machine 'type=pc-i440fx-5.1+pve0'

Die VM wird richtig auf 5.1 gepinnt.

Du sagst das passiert dir öfters beim Reboot für Kernel Updates? Also gibt es das Phänomen schon länger?

 

[mscd]

Ja ... liegt bei dem Host seit ca. 4 Wochen vor ... bei einem anderen Test-Host habe ich das Problem nicht (auch mit Windows VMs).