KVM Windows VMs and losing network connectivity

I have encountered this problem for a long time, and I can’t remember which PVE version it started from. This phenomenon still exists after upgrading to the latest 7.1. I remember that replacing E1000 with VirtIO network card did not solve it. I wonder if the latest stable 208 driver is now It can solve this problem perfectly. The strange thing is that only WINDOWS VMs will be affected by this.
 
I switched to the latest virtio drivers and have been fine since.

also turns out a lot of the "drops" were actually IO related issues with the spinning disks. The underlaying storage would "hang" which would cause SMB services to drop. Look at the logs in Windows to validate this. Since moved to SSD for almost everything and CephFS for large volume storage (Windows can mount cephfs now)
 
We also encounter the problem since a few months, perhaps since upgrade to 7.0, perhaps before. But until a few days, it was just random and just annoying, we had some windows interfaces that were going down, and just disable it and re-enable was sufficient for some days.

But we now encounter a much noxious problem on a VM since a few days, the interface goes down and when we re-enable it, the interface comes down again within a few seconds. So the VM is unusable.

The VM is 2012 R2, the interface is Intel E11000, we tried with VirtIO, it is the same thing. What is weird, is that we have another E1000 interface inside this VM on the same bridge vmbr0, but in a different VLAN, also E1000, and this one does not go down. The firs interface is just used to connect to the VM remotely and launch a management interface for some microswitchs. The second has a lot of trafic because it scans in a different VLAN about 800 microswitchs continuously.

I also tried to disable in the driver 'allow pc to shutdown this device to save power', but it is the same.

I just verified when I launch a continuous ping on the first interface (ping -t), the interface does not go down, and I am able to use the VM normally. So it is a first fix...
It seems then that the interface goes down in a few seconds when it is not used...

We are in PVE 7.2, last version), on a Dell cluster with three nodes and Ceph storage.

The detailed version is here, and the VM configuration file :

Code:
# pveversion -v
proxmox-ve: 7.2-1 (running kernel: 5.15.35-1-pve)
pve-manager: 7.2-3 (running version: 7.2-3/c743d6c1)
pve-kernel-5.15: 7.2-3
pve-kernel-helper: 7.2-3
pve-kernel-5.13: 7.1-9
pve-kernel-5.15.35-1-pve: 5.15.35-2
pve-kernel-5.15.30-1-pve: 5.15.30-1
pve-kernel-5.13.19-6-pve: 5.13.19-15
pve-kernel-5.11.22-7-pve: 5.11.22-12
ceph: 15.2.16-pve1
ceph-fuse: 15.2.16-pve1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: 0.8.36+pve1
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve2
libproxmox-acme-perl: 1.4.2
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.1-8
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.1-6
libpve-guest-common-perl: 4.1-2
libpve-http-server-perl: 4.1-1
libpve-storage-perl: 7.2-2
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.12-1
lxcfs: 4.0.12-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.1.8-1
proxmox-backup-file-restore: 2.1.8-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.4-10
pve-cluster: 7.2-1
pve-container: 4.2-1
pve-docs: 7.2-2
pve-edk2-firmware: 3.20210831-2
pve-firewall: 4.2-5
pve-firmware: 3.4-2
pve-ha-manager: 3.3-4
pve-i18n: 2.7-1
pve-qemu-kvm: 6.2.0-5
pve-xtermjs: 4.16.0-1
qemu-server: 7.2-2
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.7.1~bpo11+1
vncterm: 1.7-1
zfsutils-linux: 2.1.4-pve1

Code:
agent: 1
bootdisk: ide0
cores: 2
ide0: Ceph_vm:vm-102-disk-1,size=100G
ide2: none,media=cdrom
memory: 6144
name: server
net0: e1000=62:09:7A:9F:xx:xx,bridge=vmbr0
net1: e1000=96:B2:D8:62:yy:yy,bridge=vmbr0,tag=xxxx
numa: 0
ostype: win8
scsihw: virtio-scsi-pci
smbios1: uuid=f3c47469-a1ed-4c83-9675-7a5a7dc94dad
sockets: 2
 
Last edited:
We also encounter the problem since a few months, perhaps since upgrade to 7.0, perhaps before. But until a few days, it was just random and just annoying, we had some windows interfaces that were going down, and just disable it and re-enable was sufficient for some days.

But we now encounter a much noxious problem on a VM since a few days, the interface goes down and when we re-enable it, the interface comes down again within a few seconds. So the VM is unusable.

The VM is 2012 R2, the interface is Intel E11000, we tried with VirtIO, it is the same thing. What is weird, is that we have another E1000 interface inside this VM on the same bridge vmbr0, but in a different VLAN, also E1000, and this one does not go down. The firs interface is just used to connect to the VM remotely and launch a management interface for some microswitchs. The second has a lot of trafic because it scans in a different VLAN about 800 microswitchs continuously.

I also tried to disable in the driver 'allow pc to shutdown this device to save power', but it is the same.

I just verified when I launch a continuous ping on the first interface (ping -t), the interface does not go down, and I am able to use the VM normally. So it is a first fix...
It seems then that the interface goes down in a few seconds when it is not used...

We are in PVE 7.2, last version), on a Dell cluster with three nodes and Ceph storage.

The detailed version is here, and the VM configuration file :

Code:
# pveversion -v
proxmox-ve: 7.2-1 (running kernel: 5.15.35-1-pve)
pve-manager: 7.2-3 (running version: 7.2-3/c743d6c1)
pve-kernel-5.15: 7.2-3
pve-kernel-helper: 7.2-3
pve-kernel-5.13: 7.1-9
pve-kernel-5.15.35-1-pve: 5.15.35-2
pve-kernel-5.15.30-1-pve: 5.15.30-1
pve-kernel-5.13.19-6-pve: 5.13.19-15
pve-kernel-5.11.22-7-pve: 5.11.22-12
ceph: 15.2.16-pve1
ceph-fuse: 15.2.16-pve1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: 0.8.36+pve1
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve2
libproxmox-acme-perl: 1.4.2
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.1-8
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.1-6
libpve-guest-common-perl: 4.1-2
libpve-http-server-perl: 4.1-1
libpve-storage-perl: 7.2-2
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.12-1
lxcfs: 4.0.12-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.1.8-1
proxmox-backup-file-restore: 2.1.8-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.4-10
pve-cluster: 7.2-1
pve-container: 4.2-1
pve-docs: 7.2-2
pve-edk2-firmware: 3.20210831-2
pve-firewall: 4.2-5
pve-firmware: 3.4-2
pve-ha-manager: 3.3-4
pve-i18n: 2.7-1
pve-qemu-kvm: 6.2.0-5
pve-xtermjs: 4.16.0-1
qemu-server: 7.2-2
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.7.1~bpo11+1
vncterm: 1.7-1
zfsutils-linux: 2.1.4-pve1

Code:
agent: 1
bootdisk: ide0
cores: 2
ide0: Ceph_vm:vm-102-disk-1,size=100G
ide2: none,media=cdrom
memory: 6144
name: server
net0: e1000=62:09:7A:9F:xx:xx,bridge=vmbr0
net1: e1000=96:B2:D8:62:yy:yy,bridge=vmbr0,tag=xxxx
numa: 0
ostype: win8
scsihw: virtio-scsi-pci
smbios1: uuid=f3c47469-a1ed-4c83-9675-7a5a7dc94dad
sockets: 2

Hi

Since upgrading my proxmox to v7 I have found the Realtek NIC to be more reliable for Windows Server RAS services.

Regards
 
Hi IanCH,

I tried Realtek (rtl9139), but it is a 100 Mb (Fast Ethernet) interface only, so It was why I turned to VirtIO. Following your answer, I tried again rtl9139, and the interface also went down after a few seconds. I also tried to add a VLAN on this interface, there was none, but it failed to acquire an IP, as it is the defaukt VLAN on the trunk.

Regards
 
Last edited:
In fact, this problem was due, for me, to a loop in the network, with a network cable connected from one switch to another with the aim to manage remotely the first switch. But it did not work. It was a little switch which has no OOB interface.
In the log, the were messages like this :
vmbr0: received packet on eth0 with own address as source address (addr:aa:bb:cc:dd:ee:ff, vlan:0)

So a loop in the network. Once I disconnected the faulty cable, the messages disappeared, and windows VM no more loose network connections.
What is strange, is that it did not seem to affect linux VM.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!