Can't disable DHCP network config on xenial

[Will Bryant]

Using uvtool, I am trying to bring up a xenial VM with a bridge to my LAN, and a static network address which I inject using write-files and some bootcmd & runcmd steps (details below).

Following the instructions in /etc/network/interfaces.d/50-cloud-init.cfg, I have written "network: {config: disabled}" to /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg in a bootcmd step.

For a trusty VM, this works:

ubuntu@test-nwtn2:~$ ip address list
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:e1:8b:c3 brd ff:ff:ff:ff:ff:ff
    inet 10.42.20.4/16 brd 10.42.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fee1:8bc3/64 scope link
       valid_lft forever preferred_lft forever

But for a xenial VM, I find that the VM has two IP addresses: my statically assigned one and another which turns out to have come from DHCP (checked using DHCP logs).

ubuntu@test-nwtn2:~$ ip address list
...
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:1d:e9:17 brd ff:ff:ff:ff:ff:ff
    inet 10.42.0.60/16 brd 10.42.255.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet 10.42.20.4/16 brd 10.42.255.255 scope global secondary ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe1d:e917/64 scope link
       valid_lft forever preferred_lft forever

My host is running 16.04:

will@host-nwtn25:~$ uname -a
Linux host-nwtn25 4.4.0-42-generic #62-Ubuntu SMP Fri Oct 7 23:11:45 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
will@host-nwtn25:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial
will@host-nwtn25:~$ dpkg -l|grep cloud
ii cloud-image-utils 0.27-0ubuntu24 all cloud image management utilities
ii ubuntu-cloudimage-keyring 2013.11.11 all GnuPG keys of the Ubuntu Cloud Image builder
will@host-nwtn25:~$ dpkg -l|grep uvt
ii uvtool-libvirt 0~bzr99-0ubuntu1 all Library and tools for using Ubuntu Cloud Images with libvirt

My command is:

sudo uvt-kvm create test-nwtn2 release=xenial arch=amd64 --bridge br0 --cpu 2 --memory 2048 --disk 16384 --user-data cloud-config.yml --log-console-output

And cloud-config.yml has:

#cloud-config
...
bootcmd:
  - "echo 'network: {config: disabled}' >/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg"
write_files:
  - path: /etc/network/interfaces
    content: |
      auto lo
      iface lo inet loopback

      auto ens3
      iface ens3 inet static
      address 10.42.20.4
      network 10.42.0.0
      broadcast 10.42.255.255
      netmask 255.255.0.0
      gateway 10.42.0.1
      dns-nameservers 10.42.0.1
runcmd:
  - ifdown -a && ifup -a

I've also tried removing /etc/network/interfaces.d/50-cloud-init.cfg in my bootcmd step, which didn't seem to change anything.

(For trusty, the write_files talked about eth0 instead of ens3.)

[Will Bryant (willbryant)]

Looks to me like the network: config: disabled bit should just go in the original cloud-config file, so that is a bit of a red herring.

But DHCP is still happening. It might be being done by networking.service - it seems that cloud-init mostly runs after networking has started up.

There is a cloud-init local step before networking has come up, but it doesn't seem to run bootcmd then?

[Scott Moser (smoser)]

cloud-init doesn't currently support providing networking configuration in user-data.
It does though allow providing network-config through the 'NoCloud' datasource (which uvtool uses).

So we could extend uvtool to add a '--network-config' parameter like it's user-data that would then put the provided 'network-config' into the 'seed'.

The content of network-config is the format described at
 http://curtin.readthedocs.io/en/latest/topics/networking.html

I'm going to open a uvtool task for this bug.

This woudl be nice function to have.

Sorry for the slow reply.

[Robie Basak (racb)]

Sounds good. Should it be a generic option for the user to supply a full --network-config, or a shortcut option of --no-dhcp or something that supplies the single common network-config request, or something even more generic that allows overriding of the entire seed?

[Scott Moser (smoser)]

I was prompted by a question in IRC to look at this a bit. The changes to
uvtool would not be difficult to add a '--network-config' flag. The only
thing non-trivial would be to provide a way for the user's input network
config to reference the mac addresses of the nics that would be attached
to the virtual machine. As those addresses are not typically known before
'create'.

In lieu of changes to uvtool, the following meta-data can be provided to
uvt-kvm create --meta-data to accomplish the desired result.
  https://paste.ubuntu.com/26464399/

$ cat my-meta-data.yaml
instance-id: abcdefg
network-interfaces: |
    auto ens3
    iface ens3 inet static
        address 192.168.122.60
        netmask 255.255.255.0
        gateway 192.168.122.1

$ uvt-kvm create --meta-data=my-meta-data.yaml mytest1 release=xenial
...
$ ssh ubuntu@192.168.122.60

The above uses 'network-interfaces' mechanism in cloud-init's NoCloud
Datasource for providing networking configuration.
The format of 'network-interfaces' (ENI) is interafaces(5),
as normally found in /etc/network/interfaces.

ENI is not a great format for describing networking configuration.
Preferred would be to provide input in 'network-config' format version
1 or 2 as described in cloud-init documentation. But without modification
to uvtool we are currently not able to do that.

Some caveats:
  * you have to "guess" the network adapter name. That is most likely
    to be 'ens3' in uvtools' case, so its not that bad. But if
    you have some images that use predictable (systemd) names and
    some that do not you may have to provide 'eth0' in others.
  * Something has to come up with the ip address to provide to the
    guest before starting it.
  * as mentioned above, network config format 1 or 2 are prefereable.

[Scott Moser (smoser)]

I'm going to remove the cloud-init task above. This is really a feature request for uvt-kvm to support providing network configuration in a separate 'network-config' file on the nocloud iso formatted disk that it attaches.