| 2015-10-23 15:50:38 |
Mike McCracken |
bug |
|
|
added bug |
| 2015-10-23 15:51:46 |
Adam Stokes |
bug |
|
|
added subscriber Adam Stokes |
| 2015-10-23 15:51:58 |
Adam Stokes |
tags |
|
cloud-installer |
|
| 2015-10-23 15:52:40 |
Launchpad Janitor |
lxc (Ubuntu): status |
New |
Confirmed |
|
| 2015-10-23 16:08:59 |
Jon Grimm |
bug |
|
|
added subscriber Jon Grimm |
| 2015-10-23 16:09:10 |
Adam Stokes |
lxc (Ubuntu): importance |
Undecided |
Critical |
|
| 2015-10-23 16:24:09 |
Serge Hallyn |
attachment added |
|
lxcnet.debdiff https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/+attachment/4503325/+files/lxcnet.debdiff |
|
| 2015-10-23 16:27:55 |
Adam Stokes |
description |
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. This conflicts with the network that eth0 gets attached to when the image is brought up in a container, because it gets attached to the host's lxcbr0, which is using 10.0.3.x.
This affects LXC, and should affect LXD but doesn't currently. (see #2)
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host:
sudo lxc-create -t ubuntu-cloud -n wily
sudo lxc-start -n wily
sudo lxc-attach -n wily
# inside container, test connectivity, eg:
apt-get update |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. This conflicts with the network that eth0 gets attached to when the image is brought up in a container, because it gets attached to the host's lxcbr0, which is using 10.0.3.x.
This affects LXC, and should affect LXD but doesn't currently. (see #2)
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host:
[Test Case]
sudo lxc-create -t ubuntu-cloud -n wily
sudo lxc-start -n wily
sudo lxc-attach -n wily
# inside container, test connectivity, eg:
apt-get update
[Regression Potentional]
Currently none as networking didn't work initially. |
|
| 2015-10-23 16:28:04 |
Adam Stokes |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2015-10-23 16:28:09 |
Adam Stokes |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2015-10-23 16:38:06 |
Adam Stokes |
description |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. This conflicts with the network that eth0 gets attached to when the image is brought up in a container, because it gets attached to the host's lxcbr0, which is using 10.0.3.x.
This affects LXC, and should affect LXD but doesn't currently. (see #2)
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host:
[Test Case]
sudo lxc-create -t ubuntu-cloud -n wily
sudo lxc-start -n wily
sudo lxc-attach -n wily
# inside container, test connectivity, eg:
apt-get update
[Regression Potentional]
Currently none as networking didn't work initially. |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. This conflicts with the network that eth0 gets attached to when the image is brought up in a container, because it gets attached to the host's lxcbr0, which is using 10.0.3.x.
This affects LXC, and should affect LXD but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release.
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host:
[Test Case]
sudo lxc-create -t ubuntu-cloud -n wily
sudo lxc-start -n wily
sudo lxc-attach -n wily
# inside container, test connectivity, eg:
apt-get update
[Regression Potentional]
Currently none as networking didn't work initially. |
|
| 2015-10-23 19:18:04 |
Jay Vosburgh |
bug |
|
|
added subscriber Jay Vosburgh |
| 2015-10-23 20:45:15 |
Serge Hallyn |
attachment added |
|
lxcnet4.debdiff https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/+attachment/4503531/+files/lxcnet4.debdiff |
|
| 2015-10-23 21:27:45 |
Scott Moser |
description |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. This conflicts with the network that eth0 gets attached to when the image is brought up in a container, because it gets attached to the host's lxcbr0, which is using 10.0.3.x.
This affects LXC, and should affect LXD but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release.
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host:
[Test Case]
sudo lxc-create -t ubuntu-cloud -n wily
sudo lxc-start -n wily
sudo lxc-attach -n wily
# inside container, test connectivity, eg:
apt-get update
[Regression Potentional]
Currently none as networking didn't work initially. |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. This conflicts with the network that eth0 gets attached to when the image is brought up in a container, because it gets attached to the host's lxcbr0, which is using 10.0.3.x.
This affects LXC, and should affect LXD but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release.
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host:
[Test Case]
1.) Verify expectation for each image
- -disk1.img cloud image, check for file
- -root.tar.xz image (used by lxd) and check for file
- -root.tar.gz image (used by lxc)
For each of those images, verify:
a.) A cloud image should not have /etc/default/lxc-net
b.) lxd should be installed (dpkg-query --show | grep lxd)
2.) Start instance from updated image and start instance in lxc inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily
# wait until lxc-ls --fancy shows 'running'
lxc-attach -n bugcheck wget http://ubuntu.com
3.) Start instance from updated image and start instance in lxd inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxd import-images ubuntu wily
lxc launch ubuntu
# wait some amount
lxc attach bugcheck wget http://ubuntu.com
[Regression Potentional]
Currently none as networking didn't work initially. |
|
| 2015-10-23 21:28:58 |
Scott Moser |
description |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. This conflicts with the network that eth0 gets attached to when the image is brought up in a container, because it gets attached to the host's lxcbr0, which is using 10.0.3.x.
This affects LXC, and should affect LXD but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release.
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host:
[Test Case]
1.) Verify expectation for each image
- -disk1.img cloud image, check for file
- -root.tar.xz image (used by lxd) and check for file
- -root.tar.gz image (used by lxc)
For each of those images, verify:
a.) A cloud image should not have /etc/default/lxc-net
b.) lxd should be installed (dpkg-query --show | grep lxd)
2.) Start instance from updated image and start instance in lxc inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily
# wait until lxc-ls --fancy shows 'running'
lxc-attach -n bugcheck wget http://ubuntu.com
3.) Start instance from updated image and start instance in lxd inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxd import-images ubuntu wily
lxc launch ubuntu
# wait some amount
lxc attach bugcheck wget http://ubuntu.com
[Regression Potentional]
Currently none as networking didn't work initially. |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. This conflicts with the network that eth0 gets attached to when the image is brought up in a container, because it gets attached to the host's lxcbr0, which is using 10.0.3.x.
This affects LXC, and should affect LXD but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release.
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host:
[Test Case]
1.) Verify expectation for each image
- -disk1.img cloud image, check for file
- -root.tar.xz image (used by lxd) and check for file
- -root.tar.gz image (used by lxc)
For each of those images, verify:
a.) A cloud image should not have /etc/default/lxc-net
b.) lxd should be installed (dpkg-query --show | grep lxd)
2.) Start instance from updated image and start instance in lxc inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily
# wait until lxc-ls --fancy shows 'running'
lxc-attach -n bugcheck wget http://ubuntu.com
3.) Start instance from updated image and start instance in lxd inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxd import-images ubuntu wily
lxc launch ubuntu
# wait some amount
lxc attach bugcheck wget http://ubuntu.com
[Regression Potentional]
The highest chance for fallout is a change in the /16 network that is chosen conflicting with some existing service.
[Other Info]
Default apt install of lxc has always picked some 10.0.X.0/16 network to use for its lxcbr0 bridge. That network (often 10.0.3.0/16) would then be unreachable from the host. The same behavior occurs with libvirt-bin and many other such services.
We are moving that logic to happen the first time that 'lxc-net' service starts.
This means first boot for a cloud instance rather than cloud-image build time. |
|
| 2015-10-23 21:32:06 |
Scott Moser |
description |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. This conflicts with the network that eth0 gets attached to when the image is brought up in a container, because it gets attached to the host's lxcbr0, which is using 10.0.3.x.
This affects LXC, and should affect LXD but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release.
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host:
[Test Case]
1.) Verify expectation for each image
- -disk1.img cloud image, check for file
- -root.tar.xz image (used by lxd) and check for file
- -root.tar.gz image (used by lxc)
For each of those images, verify:
a.) A cloud image should not have /etc/default/lxc-net
b.) lxd should be installed (dpkg-query --show | grep lxd)
2.) Start instance from updated image and start instance in lxc inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily
# wait until lxc-ls --fancy shows 'running'
lxc-attach -n bugcheck wget http://ubuntu.com
3.) Start instance from updated image and start instance in lxd inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxd import-images ubuntu wily
lxc launch ubuntu
# wait some amount
lxc attach bugcheck wget http://ubuntu.com
[Regression Potentional]
The highest chance for fallout is a change in the /16 network that is chosen conflicting with some existing service.
[Other Info]
Default apt install of lxc has always picked some 10.0.X.0/16 network to use for its lxcbr0 bridge. That network (often 10.0.3.0/16) would then be unreachable from the host. The same behavior occurs with libvirt-bin and many other such services.
We are moving that logic to happen the first time that 'lxc-net' service starts.
This means first boot for a cloud instance rather than cloud-image build time. |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. This conflicts with the network that eth0 gets attached to when the image is brought up in a container, because it gets attached to the host's lxcbr0, which is using 10.0.3.x.
This affects LXC, and should affect LXD but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release.
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host:
[Test Case]
1.) Verify expectation for each image
- -disk1.img cloud image, check for file
- -root.tar.xz image (used by lxd) and check for file
- -root.tar.gz image (used by lxc)
For each of those images, verify:
a.) A cloud image should not have /etc/default/lxc-net
b.) lxd should be installed (dpkg-query --show | grep lxd)
2.) Start instance from updated image and start instance in lxc inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily
# wait until lxc-ls --fancy shows 'running'
lxc-attach -n bugcheck wget http://ubuntu.com
3.) Start instance from updated image and start instance in lxd inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxd import-images ubuntu wily
lxc launch ubuntu
# wait some amount
lxc attach bugcheck wget http://ubuntu.com
[Regression Potentional]
The highest chance for fallout is a change in the /16 network that is chosen conflicting with some existing service.
[Other Info]
Default apt install of lxc has always picked some 10.0.X.0/16 network to use for its lxcbr0 bridge. That network (often 10.0.3.0/16) would then be unreachable from the host. The same behavior occurs with libvirt-bin and many other such services.
We are moving that logic to happen the first time that 'lxc-net' service starts.
This means first boot for a cloud instance rather than cloud-image build time.
[Work around]
To patch / fix an existing cloud image to make lxc and lxd guests start simply change the config of /etc/default/lxc-net to have something other than 10.0.3.0.
sudo sed -i '/^LXC.*10[.]0[.][0-9][.]/s/10.0.[0-9]./10.0.4./g' /etc/default/lxc-net &&
sudo service lxc-net stop &&
sudo service lxc-net start |
|
| 2015-10-23 21:44:33 |
Scott Moser |
summary |
lxc postinst script checks available interfaces, can choose |
pre-installed lxc in cloud image produces broken lxc (and later lxd) containers |
|
| 2015-10-23 21:47:57 |
Scott Moser |
description |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image. This conflicts with the network that eth0 gets attached to when the image is brought up in a container, because it gets attached to the host's lxcbr0, which is using 10.0.3.x.
This affects LXC, and should affect LXD but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release.
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host:
[Test Case]
1.) Verify expectation for each image
- -disk1.img cloud image, check for file
- -root.tar.xz image (used by lxd) and check for file
- -root.tar.gz image (used by lxc)
For each of those images, verify:
a.) A cloud image should not have /etc/default/lxc-net
b.) lxd should be installed (dpkg-query --show | grep lxd)
2.) Start instance from updated image and start instance in lxc inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily
# wait until lxc-ls --fancy shows 'running'
lxc-attach -n bugcheck wget http://ubuntu.com
3.) Start instance from updated image and start instance in lxd inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxd import-images ubuntu wily
lxc launch ubuntu
# wait some amount
lxc attach bugcheck wget http://ubuntu.com
[Regression Potentional]
The highest chance for fallout is a change in the /16 network that is chosen conflicting with some existing service.
[Other Info]
Default apt install of lxc has always picked some 10.0.X.0/16 network to use for its lxcbr0 bridge. That network (often 10.0.3.0/16) would then be unreachable from the host. The same behavior occurs with libvirt-bin and many other such services.
We are moving that logic to happen the first time that 'lxc-net' service starts.
This means first boot for a cloud instance rather than cloud-image build time.
[Work around]
To patch / fix an existing cloud image to make lxc and lxd guests start simply change the config of /etc/default/lxc-net to have something other than 10.0.3.0.
sudo sed -i '/^LXC.*10[.]0[.][0-9][.]/s/10.0.[0-9]./10.0.4./g' /etc/default/lxc-net &&
sudo service lxc-net stop &&
sudo service lxc-net start |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image.
When a container is started, it will dhcp on eth0 and get 10.0.3.X as expected. The problem comes when the lxc-net service that is already installed in that container starts and configures *its* lxcbr0 with 10.0.3.X. The networking inside the container is broken at that point.
This affects LXC containers, and should affect LXD containers but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release (bug 1509390).
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host.
[Test Case]
1.) Verify expectation for each image
- -disk1.img cloud image, check for file
- -root.tar.xz image (used by lxd) and check for file
- -root.tar.gz image (used by lxc)
For each of those images, verify:
a.) A cloud image should not have /etc/default/lxc-net
b.) lxd should be installed (dpkg-query --show | grep lxd)
2.) Start instance from updated image and start instance in lxc inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily
# wait until lxc-ls --fancy shows 'running'
lxc-attach -n bugcheck wget http://ubuntu.com
3.) Start instance from updated image and start instance in lxd inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxd import-images ubuntu wily
lxc launch ubuntu
# wait some amount
lxc attach bugcheck wget http://ubuntu.com
[Regression Potentional]
The highest chance for fallout is a change in the /16 network that is chosen conflicting with some existing service.
[Other Info]
Default apt install of lxc has always picked some 10.0.X.0/16 network to use for its lxcbr0 bridge. That network (often 10.0.3.0/16) would then be unreachable from the host. The same behavior occurs with libvirt-bin and many other such services.
We are moving that logic to happen the first time that 'lxc-net' service starts.
This means first boot for a cloud instance rather than cloud-image build time.
[Work around]
To patch / fix an existing cloud image to make lxc and lxd guests start simply change the config of /etc/default/lxc-net to have something other than 10.0.3.0.
sudo sed -i '/^LXC.*10[.]0[.][0-9][.]/s/10.0.[0-9]./10.0.4./g' /etc/default/lxc-net &&
sudo service lxc-net stop &&
sudo service lxc-net start |
|
| 2015-10-23 21:48:33 |
Serge Hallyn |
attachment added |
|
lxcnet6.debdiff https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/+attachment/4503549/+files/lxcnet6.debdiff |
|
| 2015-10-23 22:28:48 |
Mario Splivalo |
bug |
|
|
added subscriber Mario Splivalo |
| 2015-10-23 22:40:03 |
Serge Hallyn |
attachment added |
|
lxcnet8.debdiff https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/+attachment/4503564/+files/lxcnet8.debdiff |
|
| 2015-10-23 23:28:07 |
Dustin Kirkland |
lxc (Ubuntu): assignee |
|
Stéphane Graber (stgraber) |
|
| 2015-10-24 00:32:44 |
Serge Hallyn |
attachment added |
|
lxcnet9.debdiff https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/+attachment/4503630/+files/lxcnet9.debdiff |
|
| 2015-10-24 02:04:08 |
Serge Hallyn |
attachment added |
|
And one more to fix in vms https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/+attachment/4503681/+files/lxcneta.debdiff |
|
| 2015-10-24 03:58:17 |
Stéphane Graber |
bug |
|
|
added subscriber SRU Verification |
| 2015-10-24 03:58:22 |
Stéphane Graber |
tags |
cloud-installer |
cloud-installer verification-needed |
|
| 2015-10-25 01:19:32 |
Serge Hallyn |
attachment added |
|
lxcnet-sysd.debdiff https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1509414/+attachment/4504366/+files/lxcnet-sysd.debdiff |
|
| 2015-10-25 07:33:03 |
mahmoh |
bug |
|
|
added subscriber M.Morana |
| 2015-10-25 13:45:52 |
Cheryl Jennings |
bug |
|
|
added subscriber Cheryl Jennings |
| 2015-10-25 13:55:46 |
Robert C Jennings |
bug |
|
|
added subscriber Robert C Jennings |
| 2015-10-26 13:44:59 |
Scott Moser |
description |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image.
When a container is started, it will dhcp on eth0 and get 10.0.3.X as expected. The problem comes when the lxc-net service that is already installed in that container starts and configures *its* lxcbr0 with 10.0.3.X. The networking inside the container is broken at that point.
This affects LXC containers, and should affect LXD containers but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release (bug 1509390).
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host.
[Test Case]
1.) Verify expectation for each image
- -disk1.img cloud image, check for file
- -root.tar.xz image (used by lxd) and check for file
- -root.tar.gz image (used by lxc)
For each of those images, verify:
a.) A cloud image should not have /etc/default/lxc-net
b.) lxd should be installed (dpkg-query --show | grep lxd)
2.) Start instance from updated image and start instance in lxc inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily
# wait until lxc-ls --fancy shows 'running'
lxc-attach -n bugcheck wget http://ubuntu.com
3.) Start instance from updated image and start instance in lxd inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxd import-images ubuntu wily
lxc launch ubuntu
# wait some amount
lxc attach bugcheck wget http://ubuntu.com
[Regression Potentional]
The highest chance for fallout is a change in the /16 network that is chosen conflicting with some existing service.
[Other Info]
Default apt install of lxc has always picked some 10.0.X.0/16 network to use for its lxcbr0 bridge. That network (often 10.0.3.0/16) would then be unreachable from the host. The same behavior occurs with libvirt-bin and many other such services.
We are moving that logic to happen the first time that 'lxc-net' service starts.
This means first boot for a cloud instance rather than cloud-image build time.
[Work around]
To patch / fix an existing cloud image to make lxc and lxd guests start simply change the config of /etc/default/lxc-net to have something other than 10.0.3.0.
sudo sed -i '/^LXC.*10[.]0[.][0-9][.]/s/10.0.[0-9]./10.0.4./g' /etc/default/lxc-net &&
sudo service lxc-net stop &&
sudo service lxc-net start |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image.
When a container is started, it will dhcp on eth0 and get 10.0.3.X as expected. The problem comes when the lxc-net service that is already installed in that container starts and configures *its* lxcbr0 with 10.0.3.X. The networking inside the container is broken at that point.
This affects LXC containers, and should affect LXD containers but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release (bug 1509390).
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host.
[Test Case]
1.) Verify expectation for each image
- -disk1.img cloud image, check for file
- -root.tar.xz image (used by lxd) and check for file
- -root.tar.gz image (used by lxc)
For each of those images, verify:
a.) A cloud image should not have /etc/default/lxc-net
b.) lxd should be installed (dpkg-query --show | grep lxd)
2.) Start instance from updated image and start instance in lxc inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily
# wait until lxc-ls --fancy shows 'running'
lxc-attach -n bugcheck wget http://ubuntu.com
3.) Start instance from updated image and start instance in lxd inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxd import-images ubuntu wily
lxc launch ubuntu
# wait some amount
lxc attach bugcheck wget http://ubuntu.com
[Regression Potentional]
The highest chance for fallout is a change in the /24 network that is chosen conflicting with some existing service.
[Other Info]
Default apt install of lxc has always picked some 10.0.X.0/24 network to use for its lxcbr0 bridge. That network (often 10.0.3.0/24) would then be unreachable from the host. The same behavior occurs with libvirt-bin and many other such services.
We are moving that logic to happen the first time that 'lxc-net' service starts.
This means first boot for a cloud instance rather than cloud-image build time.
[Work around]
To patch / fix an existing cloud image to make lxc and lxd guests start simply change the config of /etc/default/lxc-net to have something other than 10.0.3.0.
sudo sed -i '/^LXC.*10[.]0[.][0-9][.]/s/10.0.[0-9]./10.0.4./g' /etc/default/lxc-net &&
sudo service lxc-net stop &&
sudo service lxc-net start |
|
| 2015-10-26 14:09:33 |
Scott Moser |
tags |
cloud-installer verification-needed |
cloud-installer verification-done |
|
| 2015-10-26 14:11:00 |
Scott Moser |
description |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image.
When a container is started, it will dhcp on eth0 and get 10.0.3.X as expected. The problem comes when the lxc-net service that is already installed in that container starts and configures *its* lxcbr0 with 10.0.3.X. The networking inside the container is broken at that point.
This affects LXC containers, and should affect LXD containers but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release (bug 1509390).
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host.
[Test Case]
1.) Verify expectation for each image
- -disk1.img cloud image, check for file
- -root.tar.xz image (used by lxd) and check for file
- -root.tar.gz image (used by lxc)
For each of those images, verify:
a.) A cloud image should not have /etc/default/lxc-net
b.) lxd should be installed (dpkg-query --show | grep lxd)
2.) Start instance from updated image and start instance in lxc inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily
# wait until lxc-ls --fancy shows 'running'
lxc-attach -n bugcheck wget http://ubuntu.com
3.) Start instance from updated image and start instance in lxd inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxd import-images ubuntu wily
lxc launch ubuntu
# wait some amount
lxc attach bugcheck wget http://ubuntu.com
[Regression Potentional]
The highest chance for fallout is a change in the /24 network that is chosen conflicting with some existing service.
[Other Info]
Default apt install of lxc has always picked some 10.0.X.0/24 network to use for its lxcbr0 bridge. That network (often 10.0.3.0/24) would then be unreachable from the host. The same behavior occurs with libvirt-bin and many other such services.
We are moving that logic to happen the first time that 'lxc-net' service starts.
This means first boot for a cloud instance rather than cloud-image build time.
[Work around]
To patch / fix an existing cloud image to make lxc and lxd guests start simply change the config of /etc/default/lxc-net to have something other than 10.0.3.0.
sudo sed -i '/^LXC.*10[.]0[.][0-9][.]/s/10.0.[0-9]./10.0.4./g' /etc/default/lxc-net &&
sudo service lxc-net stop &&
sudo service lxc-net start |
[Problem]
The released wily image preinstalls lxc, which breaks the assumption that lxc's preinst packaging script makes:
It inspects the network to try to pick a 10.0.N.0 network that isn't being used, with N starting at 3, so this appears to have picked 10.0.3.0 when it was installed on whatever system was generating the image.
When a container is started, it will dhcp on eth0 and get 10.0.3.X as expected. The problem comes when the lxc-net service that is already installed in that container starts and configures *its* lxcbr0 with 10.0.3.X. The networking inside the container is broken at that point.
This affects LXC containers, and should affect LXD containers but doesn't currently, as the metadata used for lxd images is still pointing to a beta2 release (bug 1509390).
The easiest way to reproduce this is to use the ubuntu-cloud lxc template on a wily host.
[Test Case]
1.) Verify expectation for each image
- -disk1.img cloud image, check for file
- -root.tar.xz image (used by lxd) and check for file
- -root.tar.gz image (used by lxc)
For each of those images, verify:
a.) A cloud image should not have /etc/default/lxc-net
b.) lxd should be installed (dpkg-query --show | grep lxd)
2.) Start instance from updated image and start instance in lxc inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxc-create -t ubuntu-cloud -n bugcheck -- --release=wily --stream=daily
# wait until lxc-ls --fancy shows 'running'
lxc-attach -n bugcheck wget http://ubuntu.com
3.) Start instance from updated image and start instance in lxd inside
launch instance on openstack or kvm or other
verify lxcbr0 bridge exists
lxd import-images ubuntu wily
lxc launch ubuntu
# wait some amount
lxc attach bugcheck wget http://ubuntu.com
[Regression Potentional]
The highest chance for fallout is a change in the /24 network that is chosen conflicting with some existing service.
[Other Info]
Default apt install of lxc has always picked some 10.0.X.0/24 network to use for its lxcbr0 bridge. That network (often 10.0.3.0/24) would then be unreachable from the host. The same behavior occurs with libvirt-bin and many other such services.
We are moving that logic to happen the first time that 'lxc-net' service starts.
This means first boot for a cloud instance rather than cloud-image build time.
[Work around]
To patch / fix an existing cloud image to make lxc and lxd guests start simply change the config of /etc/default/lxc-net to have something other than 10.0.3.0.
sudo sed -i '/^LXC.*10[.]0[.][0-9][.]/s/10.0.[0-9]./10.0.4./g' /etc/default/lxc-net &&
sudo service lxc-net stop &&
sudo service lxc-net start
=== End SRU Report ===
Related bugs:
* bug 1510108: pre-installed lxc in cloud-image means loss of access to some 10.0.X.0/24 |
|
| 2015-10-26 15:01:50 |
Launchpad Janitor |
lxc (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2015-10-26 15:01:56 |
Stéphane Graber |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
