xenial:
ubuntu@ip-172-31-52-172:~$ lsb_release -r
Release: 16.04
ubuntu@ip-172-31-52-172:~$ dpkg -l|grep nplan
ii nplan 0.23~16.04.1
amd64 YAML network configuration abstraction for various backends
ubuntu@ip-172-31-52-172:~$ ip l show eth1
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 12:f6:8a:ee:fc:96 brd ff:ff:ff:ff:ff:ff
ubuntu@ip-172-31-52-172:~$ sudo netplan --debug apply
** (generate:3891): DEBUG: Processing input file
//etc/netplan/10-ifupdown.yaml..
** (generate:3891): DEBUG: starting new processing pass
** (generate:3891): DEBUG: eth0: setting default backend to 1
** (generate:3891): DEBUG: Generating output files..
** (generate:3891): DEBUG: NetworkManager: definition eth0 is not for us
(backend 1)
DEBUG:netplan generated networkd configuration exists, restarting networkd
DEBUG:no netplan generated NM configuration exists
DEBUG:device lo operstate is unknown, not replugging
DEBUG:netplan triggering .link rules for lo
DEBUG:device eth0 operstate is up, not replugging
DEBUG:netplan triggering .link rules for eth0
DEBUG:replug eth1: unbinding vif-1 from /sys/bus/xen/drivers/vif
DEBUG:replug eth1: rebinding vif-1 to /sys/bus/xen/drivers/vif
ubuntu@ip-172-31-52-172:~$ ip l show eth1
4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
ubuntu@ip-172-31-52-172:~$ lsb_release -r
Release: 16.04
ubuntu@ip-172-31-52-172:~$ dpkg -l|grep nplan
ii nplan 0.32~16.04.3
amd64 YAML network configuration abstraction for various backends
ubuntu@ip-172-31-52-172:~$ ip l show eth1
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 12:f6:8a:ee:fc:96 brd ff:ff:ff:ff:ff:ff
ubuntu@ip-172-31-52-172:~$ sudo netplan --debug apply
sudo: unable to resolve host ip-172-31-52-172
** (generate:1317): DEBUG: Processing input file
//etc/netplan/10-ifupdown.yaml..
** (generate:1317): DEBUG: starting new processing pass
** (generate:1317): DEBUG: eth0: setting default backend to 1
** (generate:1317): DEBUG: Generating output files..
** (generate:1317): DEBUG: NetworkManager: definition eth0 is not for us
(backend 1)
DEBUG:netplan generated networkd configuration exists, restarting networkd
DEBUG:no netplan generated NM configuration exists
DEBUG:device lo operstate is unknown, not replugging
DEBUG:netplan triggering .link rules for lo
DEBUG:device eth0 operstate is up, not replugging
DEBUG:netplan triggering .link rules for eth0
DEBUG:replug eth1: xen:vif fails on rebinding, ignoring
DEBUG:netplan triggering .link rules for eth1
ubuntu@ip-172-31-52-172:~$ ip l show eth1
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 12:f6:8a:ee:fc:96 brd ff:ff:ff:ff:ff:ff
** Tags removed: verification-needed verification-needed-xenial
** Tags added: verification-done verification-done-xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1729573
Title:
netplan breaks Xen VIF driver
Status in linux package in Ubuntu:
Won't Fix
Status in nplan package in Ubuntu:
Fix Released
Status in linux source package in Xenial:
Won't Fix
Status in nplan source package in Xenial:
Fix Committed
Status in linux source package in Zesty:
Won't Fix
Status in nplan source package in Zesty:
Fix Committed
Status in linux source package in Artful:
Won't Fix
Status in nplan source package in Artful:
Fix Committed
Status in linux source package in Bionic:
Won't Fix
Status in nplan source package in Bionic:
Fix Released
Bug description:
[Impact]
Some network interfaces on a Xen guest are broken by new behavior
introduced by netplan. On a Xen guest instance, when netplan is run
to 'apply' its configuration, under certain circumstances netplan will
try to "reset" the interface by unbinding and then re-binding the
interface driver from the interface, by using the sysfs "bind" and
"unbind" functions of the driver. Normally, this results in the
interface being released and then fully re-initialized by the driver.
However the Xen VIF driver breaks when this is done. The internal Xen
backend state of the interface remains in 'closed' state after the
driver re-connects to the interface, and attempts to open and use the
interface result in a kernel Oops in the Xen VIF driver.
To users, it appears that the interface is unusable because it has an
all 0 mac address; but if the mac is manually set and the interface
brought up the driver Oopses as mentioned above.
This problem makes booting painful because of very long timeouts
waiting for all network interfaces to start, and affected Xen VIF
interfaces will of course never complete startup.
[Fix]
No fix yet. Upstream kernel does not appear fixed.
[Test Case]
Create a guest instance under a Xen hypervisor (e.g. an AWS instance)
that has Ubuntu Artful 17.10 installed. Use only a single interface
at first when creating it. Then once it is ready, attach a second
network interface to the instance. From inside the instance,
configure the new interface in netplan (i.e. add a /etc/netplan/
config for it). Make sure the new interface is down (netplan does not
appear to unbind/bind interfaces that are up), and then run:
$ sudo netplan apply
or for debug,
$ sudo netplan --debug apply
this will unbind and re-bind the second interface, which will then
have all-0 mac, and will be unusable, as described above.
[Regression Potential]
Changes to the Xen VIF driver can result in unusable network
interfaces, or problems while using Xen VIF interfaces.
[Other Info]
Problem appears to exist upstream also.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1729573/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
