[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Launchpad Bug Tracker]

This bug was fixed in the package nplan - 0.32~17.04.1

---
nplan (0.32~17.04.1) zesty; urgency=medium

  * Backport 0.32 to 17.04. (LP: #1713142)

nplan (0.32) bionic; urgency=medium

  * src/nm.c: better handle the UUID generation; the order of iterating
through interaces may affect things here. Also make sure the tests catch
a null UUID.

nplan (0.31) bionic; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * src/nm.c: generate a UUID for a connection only as needed; when we're
dealing with NM VLANs. (LP: #1712921)
  * debian/tests/autostart: Make the autostart test more verbose and avoid
failing right from the start when systemd-networkd is disabled.
(LP: #1699371)
  * tests/integration.py: bump the NetworkManager timeout for settling to
120 seconds, autopkgtest infrastructure tends to be a little slow for the
network device configuration to be applied and noticed by NM.
(LP: #1699371)

  [ Dimitri John Ledkov ]
  * Reload udevd to invalidate configuration cache of .rules/.link files
as generate step may have changed them. LP: #1669564

  [ Dan Streetman ]
  * Add another interface driver exception to netplan replug to prevent unbind
of the Xen VIF interfaces. (LP: #1729573)

nplan (0.30) artful; urgency=medium

  * Add an "optional" syntax node for now to all devices. This is unimplemented
for now, but intended to allow users to mark some devices as optional: to
make sure they do not delay boot when configured. (LP: #1664844)

nplan (0.29) artful; urgency=medium

  * Fix autopkgtests in a world where /run/NetworkManager/conf.d already
exists. nplan is enabled by default, so it might well have the directory
already created on the filesystem.

nplan (0.28) artful; urgency=medium

  * Revert 56cd3eec which disabled IPv6 Router Advertisements by default. It
broke default network config in LXD and was contrary to the defaults used
by the kernel. Reopens LP: 1655440. (LP: #1717404)
  * Add "accept-ra:" key for all device types; this will default to OFF but
allow users to disable processing Router Advertisements when required by
their network setup. (LP: #1655440)

nplan (0.27) artful; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * Fix crash in systemd generator if called by an user on the command-line
  * coverage: fix exclusions to properly not cover our "never reached defaults"

  [ Dimitri John Ledkov ]
  * tests/integration.py: In teardown, stop systemd-networkd.socket.
  * src/networkd.c: Set UseMTU=true by default, whenever DHCP is in use.
(LP: #1717471)
  * tests/integration.py: fix resolved detection.

nplan (0.26) artful; urgency=medium

  * Bonding:
- Add support for specifying a primary slave. (LP: #1709135)
  * Rebind:
- Fix brcmfmac harder. Treat any 'brcmfmac' driver as not supporting
  rebind. (LP: #1712224)
  * Autopkgtests:
- Add allow-stderr. Systemd now bleats about a the networkd socket still
  being around and enabled when we restart the service; but we don't need
  to care since we're /restarting/ the service to load the new config.
- Fix the autostart package to be more sensible: we don't really care if
  networkd autostarts or not, but we need to make sure that our generator
  will run at boot, so instead check the state, but only assert it once
  we've added a config file and before checking the state of our dummy
  device.
- Do a bit more to make sure "mix" tests which stack virtual devices are
  as reliable as possible; by setting saner defaults.

nplan (0.25) artful; urgency=medium

  * tests/generate.py: add a test to validate that correct blacklist entries
are added when creating virtual devices.
  * tests/integration.py: clean up after br0 in networkd's test_bridge_mac; as
the remaining interface and udev configuration can confuse NetworkManager
now that it seems to manage random devices it did not create again.
(LP: #1699371)
  * src/nm.c: set the MTU even though we also specify it in systemd-networkd
for consumption by udev. NetworkManager will try to set it and might
otherwise default to the wrong value.
  * src/networkd.c: Set IPv6AcceptRA=no anytime we don't do DHCPv6 (or by the
same config, SLAAC), and don't have static addresses set. This should fix
the cases where unconfigured devices still get an IPv6 address.
(LP: #1655440)
  * src/nm.c: Explicitly set IPv6 method=ignore when IPv6 is otherwise not
configured; this follows the same logic as setting IPv6AcceptRA=no in
networkd, with the exception that NM does not currently disable RAs. When
it does, an unconfigured device for IPv6 will truly be left with no config.

nplan (0.24) artful; urgency=medium

  * debian/control: set Priority to important to make sure we can get into
minimal.

 -- Mathieu Trudel-Lapierre   Thu, 16 Nov 2017
10:43:28 -0500

-- 
You received this bug notification because you are a 

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Launchpad Bug Tracker]

This bug was fixed in the package nplan - 0.32~16.04.3

---
nplan (0.32~16.04.3) xenial; urgency=medium

  * tests/integration.py: Really fix skipping test_routes_v6 for the NM
backend.

nplan (0.32~16.04.2) xenial; urgency=medium

  * tests/integration.py: Fix test_routes_v6 that I clobbered when I re-applied
the skip rules for 16.04 after merging in 0.32.

nplan (0.32~16.04.1) xenial; urgency=medium

  * Backport netplan 0.32 to 16.04. (LP: #1713142)
  * debian/control: Depend on systemd (>= 229-4ubuntu20) for the PrimarySlave
feature backported in that revision.
  * tests/integration.py: Skip tests that are still not yet supported in xenial

nplan (0.32) bionic; urgency=medium

  * src/nm.c: better handle the UUID generation; the order of iterating
through interaces may affect things here. Also make sure the tests catch
a null UUID.

nplan (0.31) bionic; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * src/nm.c: generate a UUID for a connection only as needed; when we're
dealing with NM VLANs. (LP: #1712921)
  * debian/tests/autostart: Make the autostart test more verbose and avoid
failing right from the start when systemd-networkd is disabled.
(LP: #1699371)
  * tests/integration.py: bump the NetworkManager timeout for settling to
120 seconds, autopkgtest infrastructure tends to be a little slow for the
network device configuration to be applied and noticed by NM.
(LP: #1699371)

  [ Dimitri John Ledkov ]
  * Reload udevd to invalidate configuration cache of .rules/.link files
as generate step may have changed them. LP: #1669564

  [ Dan Streetman ]
  * Add another interface driver exception to netplan replug to prevent unbind
of the Xen VIF interfaces. (LP: #1729573)

nplan (0.30) artful; urgency=medium

  * Add an "optional" syntax node for now to all devices. This is unimplemented
for now, but intended to allow users to mark some devices as optional: to
make sure they do not delay boot when configured. (LP: #1664844)

nplan (0.29) artful; urgency=medium

  * Fix autopkgtests in a world where /run/NetworkManager/conf.d already
exists. nplan is enabled by default, so it might well have the directory
already created on the filesystem.

nplan (0.28) artful; urgency=medium

  * Revert 56cd3eec which disabled IPv6 Router Advertisements by default. It
broke default network config in LXD and was contrary to the defaults used
by the kernel. Reopens LP: 1655440. (LP: #1717404)
  * Add "accept-ra:" key for all device types; this will default to OFF but
allow users to disable processing Router Advertisements when required by
their network setup. (LP: #1655440)

nplan (0.27) artful; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * Fix crash in systemd generator if called by an user on the command-line
  * coverage: fix exclusions to properly not cover our "never reached defaults"

  [ Dimitri John Ledkov ]
  * tests/integration.py: In teardown, stop systemd-networkd.socket.
  * src/networkd.c: Set UseMTU=true by default, whenever DHCP is in use.
(LP: #1717471)
  * tests/integration.py: fix resolved detection.

nplan (0.26) artful; urgency=medium

  * Bonding:
- Add support for specifying a primary slave. (LP: #1709135)
  * Rebind:
- Fix brcmfmac harder. Treat any 'brcmfmac' driver as not supporting
  rebind. (LP: #1712224)
  * Autopkgtests:
- Add allow-stderr. Systemd now bleats about a the networkd socket still
  being around and enabled when we restart the service; but we don't need
  to care since we're /restarting/ the service to load the new config.
- Fix the autostart package to be more sensible: we don't really care if
  networkd autostarts or not, but we need to make sure that our generator
  will run at boot, so instead check the state, but only assert it once
  we've added a config file and before checking the state of our dummy
  device.
- Do a bit more to make sure "mix" tests which stack virtual devices are
  as reliable as possible; by setting saner defaults.

nplan (0.25) artful; urgency=medium

  * tests/generate.py: add a test to validate that correct blacklist entries
are added when creating virtual devices.
  * tests/integration.py: clean up after br0 in networkd's test_bridge_mac; as
the remaining interface and udev configuration can confuse NetworkManager
now that it seems to manage random devices it did not create again.
(LP: #1699371)
  * src/nm.c: set the MTU even though we also specify it in systemd-networkd
for consumption by udev. NetworkManager will try to set it and might
otherwise default to the wrong value.
  * src/networkd.c: Set IPv6AcceptRA=no anytime we don't do DHCPv6 (or by the
same config, SLAAC), and don't have static addresses set. This should fix
the cases where unconfigured devices still get an IPv6 address.
(LP: #1655440)
  * src/nm.c: Explicitly set IPv6 method=ignore when IPv6 is 

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Mark Thomas]

I just tested this with a 20171220 daily build of 17.10 in us-east-1, in
a custom VPC, and it appears to be working fine.

-- 
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 Released
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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Launchpad Bug Tracker]

This bug was fixed in the package nplan - 0.32~17.10.1

---
nplan (0.32~17.10.1) artful; urgency=medium

  * Backport 0.32 to Ubuntu 17.10. (LP: #1713142)

nplan (0.32) bionic; urgency=medium

  * src/nm.c: better handle the UUID generation; the order of iterating
through interaces may affect things here. Also make sure the tests catch
a null UUID.

nplan (0.31) bionic; urgency=medium

  [ Mathieu Trudel-Lapierre ]
  * src/nm.c: generate a UUID for a connection only as needed; when we're
dealing with NM VLANs. (LP: #1712921)
  * debian/tests/autostart: Make the autostart test more verbose and avoid
failing right from the start when systemd-networkd is disabled.
(LP: #1699371)
  * tests/integration.py: bump the NetworkManager timeout for settling to
120 seconds, autopkgtest infrastructure tends to be a little slow for the
network device configuration to be applied and noticed by NM.
(LP: #1699371)

  [ Dimitri John Ledkov ]
  * Reload udevd to invalidate configuration cache of .rules/.link files
as generate step may have changed them. LP: #1669564

  [ Dan Streetman ]
  * Add another interface driver exception to netplan replug to prevent unbind
of the Xen VIF interfaces. (LP: #1729573)

 -- Mathieu Trudel-Lapierre   Thu, 23 Nov 2017
12:30:51 -0500

** Changed in: nplan (Ubuntu Artful)
   Status: Fix Committed => Fix Released

-- 
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 Released
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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Dan Streetman]

xenial:

ubuntu@ip-172-31-52-172:~$ lsb_release -r
Release:16.04
ubuntu@ip-172-31-52-172:~$ dpkg -l|grep nplan
ii  nplan0.23~16.04.1   
amd64YAML network configuration abstraction for various backends
ubuntu@ip-172-31-52-172:~$ ip l show eth1
3: eth1:  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:  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  nplan0.32~16.04.3   
amd64YAML network configuration abstraction for various backends
ubuntu@ip-172-31-52-172:~$ ip l show eth1
3: eth1:  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:  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 

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Dan Streetman]

artful:

ubuntu@ip-172-31-58-142:~$ lsb_release -r
Release:17.10
ubuntu@ip-172-31-58-142:~$ dpkg -l|grep nplan
ii  nplan  0.30 
amd64YAML network configuration abstraction for various 
backends
ubuntu@ip-172-31-58-142:~$ ip l show eth1
3: eth1:  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-58-142:~$ sudo netplan --debug apply
** (generate:7935): DEBUG: Processing input file 
//etc/netplan/10-ifupdown.yaml..
** (generate:7935): DEBUG: starting new processing pass
** (generate:7935): DEBUG: eth0: setting default backend to 1
** (generate:7935): DEBUG: Generating output files..
** (generate:7935): 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:replug eth1: unbinding vif-1 from /sys/bus/xen/drivers/vif
DEBUG:replug eth1: rebinding vif-1 to /sys/bus/xen/drivers/vif
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
ubuntu@ip-172-31-58-142:~$ ip l show eth1
4: eth1:  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-58-142:~$ lsb_release -r
Release:17.10
ubuntu@ip-172-31-58-142:~$ dpkg -l|grep nplan
ii  nplan  0.32~17.10.1 
amd64YAML network configuration abstraction for various 
backends
ubuntu@ip-172-31-58-142:~$ ip l show eth1
4: eth1:  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-58-142:~$ sudo netplan --debug apply
** (generate:1267): DEBUG: Processing input file 
//etc/netplan/10-ifupdown.yaml..
** (generate:1267): DEBUG: starting new processing pass
** (generate:1267): DEBUG: eth0: setting default backend to 1
** (generate:1267): DEBUG: Generating output files..
** (generate:1267): 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 eth0 operstate is up, not replugging
DEBUG:netplan triggering .link rules for eth0
DEBUG:device lo operstate is unknown, not replugging
DEBUG:netplan triggering .link rules for lo
DEBUG:replug eth1: xen:vif fails on rebinding, ignoring
DEBUG:netplan triggering .link rules for eth1
ubuntu@ip-172-31-58-142:~$ ip l show eth1
4: eth1:  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-artful
** Tags added: verification-done-artful

-- 
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 

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Łukasz Zemczak]

Hello Dan, or anyone else affected,

Accepted nplan into xenial-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/nplan/0.32~16.04.3 in
a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, details of your
testing will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Tags removed: verification-done-xenial
** Tags added: verification-needed-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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Łukasz Zemczak]

Hello Dan, or anyone else affected,

Accepted nplan into artful-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/nplan/0.32~17.10.1 in
a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-artful to verification-done-artful. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-artful. In either case, details of your
testing will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: nplan (Ubuntu Artful)
   Status: In Progress => Fix Committed

** Tags removed: verification-done
** Tags added: verification-needed verification-needed-artful

-- 
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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Dan Streetman]

Xenial:

ubuntu@ip-172-31-60-65:~$ dpkg -l | grep nplan
ii nplan 0.23~16.04.1 amd64 YAML network configuration abstraction for various 
backends
ubuntu@ip-172-31-60-65:~$ ip l show eth1
3: eth1:  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-60-65:~$ sudo netplan --debug apply
sudo: unable to resolve host ip-172-31-60-65
** (generate:2495): DEBUG: Processing input file 
//etc/netplan/10-ifupdown.yaml..
** (generate:2495): DEBUG: starting new processing pass
** (generate:2495): DEBUG: eth0: setting default backend to 1
** (generate:2495): DEBUG: Generating output files..
** (generate:2495): 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-60-65:~$ ip l show eth1
4: eth1:  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-60-65:~$ dpkg -l | grep nplan
ii nplan 0.32~16.04.2 amd64 YAML network configuration abstraction for various 
backends
ubuntu@ip-172-31-60-65:~$ ip l show eth1
3: eth1:  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-60-65:~$ sudo netplan --debug apply
sudo: unable to resolve host ip-172-31-60-65
** (generate:1980): DEBUG: Processing input file 
//etc/netplan/10-ifupdown.yaml..
** (generate:1980): DEBUG: starting new processing pass
** (generate:1980): DEBUG: eth0: setting default backend to 1
** (generate:1980): DEBUG: Generating output files..
** (generate:1980): 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-60-65:~$ ip l show eth1
3: eth1:  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:
  In Progress
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 

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Brian Murray]

Hello Dan, or anyone else affected,

Accepted nplan into xenial-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/nplan/0.32~16.04.2 in
a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, details of your
testing will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Tags removed: verification-failed-xenial
** Tags added: verification-needed verification-needed-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:
  In Progress
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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Dan Streetman]

** Changed in: nplan (Ubuntu Artful)
 Assignee: Dan Streetman (ddstreet) => Mathieu Trudel-Lapierre (cyphermox)

** Changed in: nplan (Ubuntu Zesty)
 Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox)

** Changed in: nplan (Ubuntu Xenial)
 Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox)

-- 
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:
  In Progress
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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Mathieu Trudel-Lapierre]

** Tags removed: verification-failed

-- 
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:
  In Progress
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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Dan Streetman]

xenial build 32~16.04.1 failed for all archs; looks like a typo in one
of the python test cases.

https://launchpad.net/ubuntu/+source/nplan/0.32~16.04.1

https://launchpadlibrarian.net/346856943/buildlog_ubuntu-xenial-
amd64.nplan_0.32~16.04.1_BUILDING.txt.gz

/usr/bin/pyflakes3 src/netplan  tests/generate.py tests/cli.py 
tests/integration.py
tests/integration.py:1030:46: invalid syntax
if (self.backend == "NetworkManager")
 ^
Makefile:24: recipe for target 'check' failed
make[1]: *** [check] Error 1
make[1]: Leaving directory '/<>'
dh_auto_test: make -j1 check returned exit code 2
debian/rules:4: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


** Tags removed: verification-needed-xenial verification-needed-zesty
** Tags added: verification-done-zesty verification-failed-xenial

** Tags removed: verification-needed
** Tags added: verification-failed

-- 
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:
  In Progress
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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Dan Streetman]

Zesty:

ubuntu@ip-172-31-53-199:~$ dpkg -l | grep nplan
ii  nplan  0.23~17.04.1 
 amd64YAML network configuration abstraction for various 
backends
ubuntu@ip-172-31-53-199:~$ ip l show eth1
4: eth1:  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-53-199:~$ sudo netplan --debug apply
** (generate:1349): DEBUG: Processing input file 
//etc/netplan/10-ifupdown.yaml..
** (generate:1349): DEBUG: starting new processing pass
** (generate:1349): DEBUG: eth0: setting default backend to 1
** (generate:1349): DEBUG: Generating output files..
** (generate:1349): 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 eth0 operstate is up, not replugging
DEBUG:netplan triggering .link rules for eth0
DEBUG:device lo operstate is unknown, not replugging
DEBUG:netplan triggering .link rules for lo
DEBUG:replug eth1: unbinding vif-2 from /sys/bus/xen/drivers/vif
DEBUG:replug eth1: rebinding vif-2 to /sys/bus/xen/drivers/vif
ubuntu@ip-172-31-53-199:~$ ip l show eth1
5: eth1:  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-53-199:~$ dpkg -l | grep nplan
ii  nplan  0.32~17.04.1 
 amd64YAML network configuration abstraction for various 
backends
ubuntu@ip-172-31-53-199:~$ ip l show eth1
3: eth1:  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-53-199:~$ sudo netplan --debug apply
** (generate:1282): DEBUG: Processing input file 
//etc/netplan/10-ifupdown.yaml..
** (generate:1282): DEBUG: starting new processing pass
** (generate:1282): DEBUG: eth0: setting default backend to 1
** (generate:1282): DEBUG: Generating output files..
** (generate:1282): 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:replug eth1: xen:vif fails on rebinding, ignoring
DEBUG:netplan triggering .link rules for eth1
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
ubuntu@ip-172-31-53-199:~$ ip l show eth1
3: eth1:  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

-- 
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:
  In Progress
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 

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Łukasz Zemczak]

Hello Dan, or anyone else affected,

Accepted nplan into xenial-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/nplan/0.32~16.04.1 in
a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-xenial to verification-done-xenial. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-xenial. In either case, details of your
testing will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: nplan (Ubuntu Xenial)
   Status: New => Fix Committed

** Tags added: verification-needed-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:
  In Progress
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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Łukasz Zemczak]

Hello Dan, or anyone else affected,

Accepted nplan into zesty-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/nplan/0.32~17.04.1 in
a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-zesty to verification-done-zesty. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-zesty. In either case, details of your testing
will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: nplan (Ubuntu Zesty)
   Status: New => Fix Committed

** Tags added: verification-needed verification-needed-zesty

-- 
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:
  New
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:
  In Progress
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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Launchpad Bug Tracker]

This bug was fixed in the package nplan - 0.32

---
nplan (0.32) bionic; urgency=medium

  * src/nm.c: better handle the UUID generation; the order of iterating
through interaces may affect things here. Also make sure the tests catch
a null UUID.

 -- Mathieu Trudel-Lapierre   Tue, 14 Nov 2017
08:53:51 -0500

** Changed in: nplan (Ubuntu Bionic)
   Status: In Progress => Fix Released

-- 
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:
  New
Status in linux source package in Zesty:
  Won't Fix
Status in nplan source package in Zesty:
  New
Status in linux source package in Artful:
  Won't Fix
Status in nplan source package in Artful:
  In Progress
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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Dan Streetman]

** Changed in: linux (Ubuntu)
 Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: linux (Ubuntu Artful)
 Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: linux (Ubuntu Bionic)
 Assignee: Dan Streetman (ddstreet) => (unassigned)

** Changed in: linux (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: linux (Ubuntu Zesty)
   Status: New => Won't Fix

** Changed in: linux (Ubuntu)
   Importance: High => Wishlist

** Changed in: linux (Ubuntu Artful)
   Importance: High => Wishlist

** Changed in: linux (Ubuntu Bionic)
   Importance: High => Wishlist

** Changed in: linux (Ubuntu Bionic)
   Importance: Wishlist => Undecided

** Changed in: linux (Ubuntu Artful)
   Importance: Wishlist => Undecided

** Changed in: linux (Ubuntu)
   Importance: Wishlist => Undecided

** Changed in: linux (Ubuntu)
   Status: In Progress => Won't Fix

-- 
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:
  In Progress
Status in linux source package in Xenial:
  Won't Fix
Status in nplan source package in Xenial:
  New
Status in linux source package in Zesty:
  Won't Fix
Status in nplan source package in Zesty:
  New
Status in linux source package in Artful:
  Won't Fix
Status in nplan source package in Artful:
  In Progress
Status in linux source package in Bionic:
  Won't Fix
Status in nplan source package in Bionic:
  In Progress

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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Mathieu Trudel-Lapierre]

** Also affects: linux (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: nplan (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: nplan (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
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:
  In Progress
Status in nplan package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  New
Status in nplan source package in Xenial:
  New
Status in linux source package in Zesty:
  New
Status in nplan source package in Zesty:
  New
Status in linux source package in Artful:
  Won't Fix
Status in nplan source package in Artful:
  In Progress
Status in linux source package in Bionic:
  Won't Fix
Status in nplan source package in Bionic:
  In Progress

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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Launchpad Bug Tracker]

** Merge proposal linked:
   https://code.launchpad.net/~ddstreet/netplan/+git/netplan/+merge/333198

-- 
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:
  In Progress
Status in nplan package in Ubuntu:
  In Progress
Status in linux source package in Artful:
  Won't Fix
Status in nplan source package in Artful:
  In Progress
Status in linux source package in Bionic:
  Won't Fix
Status in nplan source package in Bionic:
  In Progress

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

[Kernel-packages] [Bug 1729573] Re: netplan breaks Xen VIF driver

[Dan Streetman]

switching this bug over to netplan, as there are already several nic
drivers blacklisted from the "replugging" in netplan, due to them not
supporting (or breaking) unbinding/rebinding.

** Also affects: nplan (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu Artful)
   Status: In Progress => Won't Fix

** Changed in: linux (Ubuntu Bionic)
   Status: In Progress => Won't Fix

** Changed in: nplan (Ubuntu Artful)
   Importance: Undecided => High

** Changed in: nplan (Ubuntu Bionic)
   Importance: Undecided => High

** Changed in: nplan (Ubuntu Artful)
   Status: New => In Progress

** Changed in: nplan (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: nplan (Ubuntu Bionic)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

** Changed in: nplan (Ubuntu Artful)
 Assignee: (unassigned) => Dan Streetman (ddstreet)

-- 
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:
  In Progress
Status in nplan package in Ubuntu:
  In Progress
Status in linux source package in Artful:
  Won't Fix
Status in nplan source package in Artful:
  In Progress
Status in linux source package in Bionic:
  Won't Fix
Status in nplan source package in Bionic:
  In Progress

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