[Bug 1793555] [NEW] networkd tears down bridge ip address when the last device is pulled out from the bridge
Public bug reported: In Ubuntu 18.04.1 LTS (systemd 237) pulling out the last device out of the bridge removes the bridge ip address. given the following config: # cat /etc/systemd/network/vmbr0.netdev [NetDev] Name=vmbr0 Kind=bridge [Bridge] HelloTimeSec=0 ForwardDelaySec=0 STP=no # cat /etc/systemd/network/vmbr0.network [Match] Name=vmbr0 [Network] Address=10.10.0.1/16 ConfigureWithoutCarrier=yes DHCP=no IPForward=yes IPv6AcceptRA=no LinkLocalAddressing=no networkd would bring up vmbr0 with 10.10.0.1/16 on system boot despite it not having any devices, allowing services to bind to 10.10.0.1. However, if you add a device and then remove it (e.g. by starting and then stopping a virtual machine connected to the bridge), networkd would tear down the interface: 3: vmbr0: mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 16:19:4c:7f:e8:c4 brd ff:ff:ff:ff:ff:ff thus making any service listening on 10.10.0.1 inaccessible. previously on Xenial the bridge would stay intact. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1793555 Title: networkd tears down bridge ip address when the last device is pulled out from the bridge To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1793555/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1793555] Re: networkd tears down bridge ip address when the last device is pulled out from the bridge
Seems to be related to https://github.com/systemd/systemd/pull/7403 which isn't merged still. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1793555 Title: networkd tears down bridge ip address when the last device is pulled out from the bridge To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1793555/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1660385] Re: Alert user of Ec2 Datasource on lookalike cloud
This is a pretty big issue for those of us not running inside any cloud environment, but still relying on non-intrusive ways to provision VMs. I know that NoCloud is the expected datasource for that, but Ec2 was always a hassle-free option. It is trivial to spin up a Ec2-compatible metadata server, and then the only thing you need is to boot a vanilla ubuntu image with no strings attached, it will find ec2 metadata and will just work. Compare this to NoCloud: - pass a kernel command line option, which requires to boot qemu with custom kernel outside of ubuntu guest image and is troublesome or - add config files into the guest's /var/lib/cloud/seed/nocloud, which requires mounting the image on the host and tinkering with it (and as soon as it's mounted, there's little reason to use cloud-init at all, TBH) or - add a virtual cd image with cloud metadata, which requires provisioning those images and some (at times) non-trivial bookkeeping, e.g. when you migrate a vm to a different host (two machines are still a NoCloud). If you are going this route, I would highly suggest you to consider an option where NoCloud can be pointed at network server via, e.g. dmi strings, that are trivially configurable from qemu / libvirt. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1660385 Title: Alert user of Ec2 Datasource on lookalike cloud To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1660385/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
