#810247 Hyper-V network adapters are mapped to a different interface (ethN) on every boot

Package:
udev
Source:
systemd
Description:
/dev/ and hotplug management daemon
Submitter:
Fernando Soto
Date:
2026-10-16 06:11:03 UTC
Severity:
normal
Tags:
#810247#5
Date:
2016-01-07 15:59:51 UTC
From:
To:
On a Hyper-V VM with more than one network adapter, the NIC devices are being mapped to different ethN on every boot.
If you are using dhcp reservation or static IPs, you will likely lose connectivity to the VM.

Expected behavior is that the NICs are always detected in the same order and consistently mapped to the same interface.
The udev persistent rules could be a workaround, but they are created for virtual environment.

To reproduce:
Add more than one NIC to the Hyper-V VM (I can consistently reproduce with 3 NICs - I have tried only with synthetic NICs, not legacy).
Reboot the server and check that the interface MACs are switched - apparently in a random order.

The issue reproduced on both Hyper-V 2008 R2 and Hyper-V 2012 R2.
The issue was not observed on Debian Wheezy (kernel 3.2).
 After upgrading to kernel 4.2 from jessie-backports, the issue is also not reproducible.

Kernel:
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02) x86_64 GNU/Linux

Libc6
root@debian:~# dpkg -s libc6 | grep Version
Version: 2.19-18+deb8u1

Example of one boot:
=========================================================
eth0 - vmbus_0_16 - MAC 00:15:5d:0a:e2:ad
eth1 - vmbus_0_15 - MAC 00:15:5d:0a:e2:ac
eth2 - vmbus_0_14 - MAC 00:15:5d:0a:e2:ab

From syslog:
Jan  7 09:32:00 debian kernel: [    0.975823] hv_netvsc vmbus_0_16: Send section size: 6144, Section count:170
Jan  7 09:32:00 debian kernel: [    0.976904] hv_netvsc vmbus_0_16: Device MAC 00:15:5d:0a:e2:ad link state down
Jan  7 09:32:00 debian kernel: [    1.178541] hv_netvsc vmbus_0_15: Send section size: 6144, Section count:170
Jan  7 09:32:00 debian kernel: [    1.178913] hv_netvsc vmbus_0_15: Device MAC 00:15:5d:0a:e2:ac link state down
Jan  7 09:32:00 debian kernel: [    1.497795] hv_netvsc vmbus_0_14: Send section size: 6144, Section count:170
Jan  7 09:32:00 debian kernel: [    1.498031] hv_netvsc vmbus_0_14: Device MAC 00:15:5d:0a:e2:ab link state up

Output of 'ip a':
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:15:5d:0a:e2:ad brd ff:ff:ff:ff:ff:ff
    inet 172.16.10.118/24 brd 172.16.10.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fe0a:e2ad/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:15:5d:0a:e2:ac brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:15:5d:0a:e2:ab brd ff:ff:ff:ff:ff:ff
=========================================================

Then next boot:
=========================================================
eth0 - vmbus_0_16 - MAC 00:15:5d:0a:e2:ab
eth1 - vmbus_0_15 - MAC 00:15:5d:0a:e2:ad
eth2 - vmbus_0_14 - MAC 00:15:5d:0a:e2:ac

From syslog:
Jan  7 09:40:36 debian kernel: [    1.637628] hv_netvsc vmbus_0_14: Send section size: 6144, Section count:170
Jan  7 09:40:36 debian kernel: [    1.637855] hv_netvsc vmbus_0_14: Device MAC 00:15:5d:0a:e2:ab link state up
Jan  7 09:40:36 debian kernel: [    2.037576] hv_netvsc vmbus_0_16: Send section size: 6144, Section count:170
Jan  7 09:40:36 debian kernel: [    2.037869] hv_netvsc vmbus_0_16: Device MAC 00:15:5d:0a:e2:ad link state up
Jan  7 09:40:36 debian kernel: [    2.349817] hv_netvsc vmbus_0_15: Send section size: 6144, Section count:170
Jan  7 09:40:36 debian kernel: [    2.350153] hv_netvsc vmbus_0_15: Device MAC 00:15:5d:0a:e2:ac link state up

Output of 'ip a':
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:15:5d:0a:e2:ab brd ff:ff:ff:ff:ff:ff
    inet 172.16.10.118/24 brd 172.16.10.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fe0a:e2ab/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:15:5d:0a:e2:ad brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:15:5d:0a:e2:ac brd ff:ff:ff:ff:ff:ff
=========================================================


After upgrading to linux-image-4.2.0-0.bpo.1-amd64 (kernel 4.2.6-3~bpo8+2), the issue is no longer reproducible.

The order is always maintained:
Jan  7 10:31:48 debian kernel: [    0.984851] hv_netvsc vmbus_14: Send section size: 6144, Section count:2560
Jan  7 10:31:48 debian kernel: [    0.986469] hv_netvsc vmbus_14: Device MAC 00:15:5d:0a:e2:ab link state up
Jan  7 10:31:48 debian kernel: [    1.129932] hv_netvsc vmbus_15: Send section size: 6144, Section count:2560
Jan  7 10:31:48 debian kernel: [    1.130500] hv_netvsc vmbus_15: Device MAC 00:15:5d:0a:e2:ac link state up
Jan  7 10:31:48 debian kernel: [    1.274065] hv_netvsc vmbus_16: Send section size: 6144, Section count:2560
Jan  7 10:31:48 debian kernel: [    1.274790] hv_netvsc vmbus_16: Device MAC 00:15:5d:0a:e2:ad link state up
#810247#10
Date:
2016-01-07 17:57:05 UTC
From:
To:
Control: reassign -1 udev

The kernel cannot guarantee to enumerate devices in fixed order.
[...]

That is where I think this should be handled.

Ben.
#810247#19
Date:
2016-01-08 15:22:43 UTC
From:
To:
Fixing this in udev will cause issues like reported in #431190.
The persistent-net udev rules are not created in virtual environments to avoid issues with cloning/migrating VMs.

I was also unable to reproduce the issue on a VMware ESX server VM, despite the fact that no net udev rules are created.
And why it happens with Hyper-V only in kernel 3.16, not 3.2 or 4.2?
#810247#24
Date:
2016-01-09 15:44:56 UTC
From:
To:
Fernando Soto [2016-01-08 15:22 +0000]:

This was true with the old persistent names in Jessie and before, but
not true any more with current testing and unstable versions. See
/usr/share/doc/udev/README.Debian.gz.

Maybe the current ifnames system cannot figure out an appropriate name
for Hyper-V interfaces? Can you please send "udevadm info --export-db"
(as an attachment) from this system?

Thanks,

Martin
#810247#31
Date:
2016-01-09 17:20:26 UTC
From:
To:
Hi Martin,

Udevadm output is attached.

Thank you,
Fernando
#810247#36
Date:
2018-03-24 21:25:25 UTC
From:
To:
P:
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/VMBUS:01/vmbus_0_16/net/eth0
E:
DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/VMBUS:01/vmbus_0_16/net/eth0
E: ID_NET_DRIVER=hv_netvsc
E: ID_NET_NAME_MAC=enx00155d0ae2ad
E: ID_OUI_FROM_DATABASE=Microsoft Corporation
E: ID_PATH=acpi-VMBUS:01
E: ID_PATH_TAG=acpi-VMBUS_01
E: IFINDEX=2
E: INTERFACE=eth0
E: MATCHDEVID=0x0
E: MATCHIFTYPE=1
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
E: TAGS=:systemd:
E: USEC_INITIALIZED=39002

Looks like this is the case.
I notice that there is

Author: Hannes Reinecke <hare@suse.de>
Date:   Fri Nov 23 14:12:39 2012 +0100

    udev: path_id - handle Hyper-V devices

    Hyper-V has an abstract bus, which gets renumbered on guest
    startup. So instead of the bus numbers we should be using
    the device GUIDs, which can be retrieved from the 'device_id'
    sysfs attribute.


That doesn't seem to handle network interfaces though.

That said, this doesn't look like a Debian specific problem. So it's
probably best if you raise this upstream at
https://github.com/systemd/systemd
#810247#41
Date:
2018-04-04 14:33:02 UTC
From:
To:
Thanks Michael.
I have reported it upstream:
https://github.com/systemd/systemd/issues/8652

Fernando

-----Original Message-----
P:
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/VMBUS:01/vmbus_0_16/net/eth0
E:
DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:07/VMBUS:01/vmbus_0_16/net/eth0
E: ID_NET_DRIVER=hv_netvsc
E: ID_NET_NAME_MAC=enx00155d0ae2ad
E: ID_OUI_FROM_DATABASE=Microsoft Corporation
E: ID_PATH=acpi-VMBUS:01
E: ID_PATH_TAG=acpi-VMBUS_01
E: IFINDEX=2
E: INTERFACE=eth0
E: MATCHDEVID=0x0
E: MATCHIFTYPE=1
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
E: TAGS=:systemd:
E: USEC_INITIALIZED=39002

Looks like this is the case.
I notice that there is

Author: Hannes Reinecke <hare@suse.de>
Date:   Fri Nov 23 14:12:39 2012 +0100

    udev: path_id - handle Hyper-V devices

    Hyper-V has an abstract bus, which gets renumbered on guest
    startup. So instead of the bus numbers we should be using
    the device GUIDs, which can be retrieved from the 'device_id'
    sysfs attribute.


That doesn't seem to handle network interfaces though.

That said, this doesn't look like a Debian specific problem. So it's probably best if you raise this upstream at https://github.com/systemd/systemd
#810247#48
Date:
2026-10-16 05:49:12 UTC
From:
To:
Based on what I see in #810247 one option is to use `ifupdown`'s
interface renaming/mapping functionality.  Those can be used to assign a
name based on MAC address.  This is pretty similar to udev's stable
naming functionality.

I imagine most tools which offer similar functionality can rename based
on MAC address.

I do note Xen's virtual network interface driver manages to keep network
interface name stable.