Bug 1677870 - virt-builder - Ubuntu 18.04 - netplan config file uses the wrong interface
Summary: virt-builder - Ubuntu 18.04 - netplan config file uses the wrong interface
Keywords:
Status: NEW
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-16 14:17 UTC by Panagiotis Mavrogiorgos
Modified: 2021-07-18 09:25 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description Panagiotis Mavrogiorgos 2019-02-16 14:17:02 UTC
Description of problem:

Not sure if this is a bug or something that can be fixed by virt-builder, but I thought I should mention it anyway

Ubuntu 18.04 uses netplan for its network configuration. The configuration file can be found at `/etc/netplan/01-netcfg.yaml` and its original contents are:

```
root@test:~# cat /etc/netplan/01-netcfg.yaml 
network:
  version: 2
  renderer: networkd
  ethernets:
    ens2:
      dhcp4: true
```

The "problem" is that `ens2` is not the network interface that the VM is using. An least on my laptop, the correct interface is:

```
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
```

Replacing `ens2` with `enp1s0` and running `netplan apply` is enough to restore internet access.

This is not a biggie, and on production people are almost certainly setting up their networks, but the first time you try to use virt-builder you end up in a machine with no internet (so you can't e.g. ssh into the machine) and you need to figure out what is the problem.

How reproducible:

100%

Steps to Reproduce:

```
virt-builder \
  ubuntu-18.04 \
  --format qcow2 \
  --output test3.qcow2 \
  --hostname test3 \
  --size "6G" \
  --arch "x86_64" \
  --no-sync \
  --memsize "2000" \
  --smp "2" \
  --timezone "Europe/Athens" \
  --password-crypto "sha512" \
  --ssh-inject "root:file:$HOME/.ssh/id_rsa.pub" \
  --firstboot-command "dpkg-reconfigure openssh-server" \
  --run-command "rm /etc/machine-id" \
  --run-command "systemd-machine-id-setup"
```

Expected results:

It would be nice if virt-builder could check the name of the interface and use it on build time. Alternatively, a note on the `--notes` might be a good idea.

Comment 1 Panagiotis Mavrogiorgos 2019-02-18 21:49:06 UTC
For the record, the same is true on the debian 9 image too. More specifically, the image is configured to use the "ens2" interface while the VM actualy uses "enp1s0".

Comment 2 Richard W.M. Jones 2019-03-04 13:30:43 UTC
I guess this is a sysprep thing.  Does removing /etc/netplan/01-netcfg.yaml
cause the file to get recreated next boot with the right content?

The problem is it's fairly impossible to predict the right network name.

Comment 3 Panagiotis Mavrogiorgos 2019-03-04 14:35:20 UTC
I just checked this on ubuntu 18.04. /etc/netplan/01-netcfg.yaml does not get recreated on next boot.

Vagrant seems to have similar issues as well: https://github.com/vagrant-libvirt/vagrant-libvirt/issues/609
The thread also mentions some potential workarounds so you might want to check it. E.g.:

> This can all be worked around by passing `net.ifnames=0 biosdevname=0` on kernel commandline

Comment 4 Georg Sauthoff 2021-07-18 09:25:30 UTC
Incidentally, I'm running into the reverse issue with the ubuntu 20.04 virt-builder image:

The included /etc/netplan/01-netcfg.yaml uses enp1s0 while my VM guest has ens3 ...

So this looks like a better default would be to just wildcard-match the interface name, i.e. to replace the netplan/network during image template generation.

For example by using such a netplan config:

```
network:
  version: 2
  renderer: networkd
  ethernets:
    eth:
      match:
        name: en*
      dhcp4: yes
```

Or by skipping (or even removing netplan) and using networkd directly, i.e. by dropping something like this into /etc/systemd/network/:

```
[Match]
Name=e*

[Network]
DHCP=ipv4
```


Note You need to log in before you can comment on or make changes to this bug.