Design: Netplan support for VETH

Rationale

Veths are Virtual Ethernet interfaces that are commonly used to
connect bridges or network namespaces. They act like a link between
two networks, simply bypassing traffic from one veth peer to the other.

Veths work in peers, meaning that users will always create two of them.

This implementation allows users to create peers of veths, configure them with
IPs, routes and etc, change their MAC addresses and use them as member
interfaces for bridges and bonds for example. It doesn't support adding veths
to different network namespaces, although it could be done by an external tool.

Changes in the schema

As both peers are configurable with IPs and etc, they must be defined in
separate stanzas.

A new type of network called virtual-ethernets was created and one extra key called
peer was introduced.

network:
  version: 2
  renderer: networkd
  virtual-ethernets:
    veth0-peer1:
      peer: veth0-peer2
    veth0-peer2:
      peer: veth0-peer1

  bridges:
    br0:
      interfaces:
        - veth0-peer1
    br1:
      interfaces:
        - veth0-peer2

Even though veth only work in pairs, it's not mandatory to define the peer
stanza (the peer key is mandatory) when using NetworkManager as renderer. The peer interface is not required
because Network Manager requires the creation of two connections, one for each
peer. As our keyfile parser maps a keyfile to a YAML file (a 1:1 mapping), if
we forced the creation of both peers, we'd had problems with the
Netplan-NetworkManager integration.

systemd-networkd backend

Networkd requires a single .netdev file to create both veths.
So the configuration above will generate the .netdev file below:

[NetDev]
Name=veth0-peer1
Kind=veth

[Peer]
Name=veth0-peer2

If further configuration is required, one .network file per veth peer must be
created.

As only one .netdev is needed, we sort both peer names and use the first one.
If the peer stanza is not defined, it will not generate any files.

Network Manager backend

On Network Manager, one keyfile per peer is required. So, creating a veth pair
requires 2 connections.

veth-peer1.nmconnection:

[connection]
id=veth-peer1
uuid=64cec75d-1f76-4379-bd82-684bc77484b9
type=veth
interface-name=veth-peer1

[veth]
peer=veth-peer2

veth-peer2.nmconnection:

[connection]
id=veth-peer2
uuid=a5d3f350-15f7-4e21-a2d4-be549531fba3
type=veth
interface-name=veth-peer2

[veth]
peer=veth-peer1

Netplan Everywhere

One of the implications of these changes is that Network Manager will
create YAML files for virtual-ethernets automatically.

veth devices will be seen as unmanaged by Network Manager until the file
/var/run/NetworkManager/conf.d/10-globally-managed-devices.conf is
created by the generator and Network Manager is restarted. The implication
is that, veth pairs created with NM on a system that is not already
managed by NM will not come up online until the user either calls
netplan apply or restart NM.

Keyfile parser

The keyfile parser will create a 1:1 mapping between the keyfile
and the interface in the YAML file it generates. That's the main
reason why it's not mandatory to defined both peers at once.

That approach enable Netplan Everywhere to work out of the box
with virtual-ethernets.

Alternative solution

$NOTE$: this was the original approach implemented. But due to complications
with the integration with Network Manager, we used the approach described
above.

We could make it mandatory to define both peers at once. It makes sense
because virtual-ethernets only work in pairs.

When creating the veth interface from the keyfile, a stanza for the peer
is also created and linked to the veth. That basically means that a keyfile
for a veth interface will generate 2 interfaces in the YAML file, the
interface itself and its peer. The same will happen when the second veth
(the peer) is created in a second API call to Network Manager. In the end,
2 Netplan YAML files will be created. When the generator is called, it will
merge both files, creating the full veth configuration.

This approach will require some changes in the Network Manager integration with Netplan.
Currently, Network Manager assumes a single netdef is present in the
Netplan state, but now we will have 2 netdefs. Both netdefs must be part of
the same YAML file so, instead of writing the netdef to the file, we will
need to write the entire netplan state (which will contain 2 netdefs).

After some changes to the Network Manager's integration patch,
that's the results:

Adding the first veth interface:

nmcli con add \
  con-name veth-nm-peer1 \
  type veth \
  peer veth-nm-peer2 \
  connection.interface-name veth-nm-peer1

This will create the file
/etc/netplan/90-NM-d4afd034-9634-4a67-a3ee-0c52154eefa3.yaml with the
following content:

network:
  version: 2
  virtual-ethernets:
    veth-nm-peer1:
      renderer: NetworkManager
      dhcp4: true
      dhcp6: true
      peer: "veth-nm-peer2"
      networkmanager:
        uuid: "d4afd034-9634-4a67-a3ee-0c52154eefa3"
        name: "veth-nm-peer1"
        passthrough:
          ipv6.addr-gen-mode: "default"
          ipv6.ip6-privacy: "-1"
          proxy._: ""
    veth-nm-peer2:
      renderer: NetworkManager
      peer: "veth-nm-peer1"

Now, adding the veth peer with the following command:

nmcli con add \
  con-name veth-nm-peer2 \
  type veth \
  peer veth-nm-peer1 \
  connection.interface-name veth-nm-peer2

This will create the file
/etc/netplan/90-NM-505fc532-a910-4346-8bd8-19e849b696e6.yaml with the
following content:

network:
  version: 2
  virtual-ethernets:
    veth-nm-peer2:
      renderer: NetworkManager
      dhcp4: true
      dhcp6: true
      peer: "veth-nm-peer1"
      networkmanager:
        uuid: "505fc532-a910-4346-8bd8-19e849b696e6"
        name: "veth-nm-peer2"
        passthrough:
          ipv6.addr-gen-mode: "default"
          ipv6.ip6-privacy: "-1"
          proxy._: ""
    veth-nm-peer1:
      renderer: NetworkManager
      peer: "veth-nm-peer2"

Network Manager now has both connections:

NAME           UUID                                  TYPE  DEVICE
veth-nm-peer1  d4afd034-9634-4a67-a3ee-0c52154eefa3  veth  --
veth-nm-peer2  505fc532-a910-4346-8bd8-19e849b696e6  veth  --

netplan get will then produce the following result:

network:
  version: 2
  virtual-ethernets:
    veth-nm-peer2:
      renderer: NetworkManager
      dhcp4: true
      dhcp6: true
      peer: "veth-nm-peer1"
      networkmanager:
        uuid: "505fc532-a910-4346-8bd8-19e849b696e6"
        name: "veth-nm-peer2"
        passthrough:
          ipv6.addr-gen-mode: "default"
          ipv6.ip6-privacy: "-1"
          proxy._: ""
    veth-nm-peer1:
      renderer: NetworkManager
      dhcp4: true
      dhcp6: true
      peer: "veth-nm-peer2"
      networkmanager:
        uuid: "d4afd034-9634-4a67-a3ee-0c52154eefa3"
        name: "veth-nm-peer1"
        passthrough:
          ipv6.addr-gen-mode: "default"
          ipv6.ip6-privacy: "-1"
          proxy._: ""

Deleting connections

Netplan's netplan_delete_connection() will try to remove one of the peers
from the Netplan's state. As a veth peer cannot exist without the other,
netplan_delete_connection() will need to remove both connections when
any one of them is deleted.

The problem with this approach is that, after deleting one of the veths,
both of them will disappear from the YAML files but one connection will be kept
in the Network Manager's state.

So, deleting an interface, would require the deletion of both of them. If
we delete a single interface, Netplan will fail to parse the one that's left.
If we delete both of them from netplan, after running nmcli con del, one would
still be in the Network Manager's state so it would be out of sync with netplan.

Checklist

• Runs make check successfully.
• Retains 100% code coverage (make check-coverage).
• New/changed keys in YAML format are documented.
• (Optional) Adds example YAML for new feature.
• (Optional) Closes an open bug in Launchpad.