Add networking options for vde_vmnet support

[jandubois]

Ref #81

[jandubois]

I think I've addressed all comments now.

I don't know how I can force QEMU to use eth0 for vde and eth1 for slirp; any suggestions?

[AkihiroSuda]

Thanks, but the slirp eth does not link up for me

suda@lima-default:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 22:34:71:8a:4e:62 brd ff:ff:ff:ff:ff:ff
    inet 192.168.105.3/24 brd 192.168.105.255 scope global dynamic enp0s1
       valid_lft 85382sec preferred_lft 85382sec
    inet6 fd69:599c:c913:ae3f:2034:71ff:fe8a:4e62/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2591992sec preferred_lft 604792sec
    inet6 fe80::2034:71ff:fe8a:4e62/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

Config: the default template but network.vde.url = "/var/run/vde.ctl"

[jandubois]

Thanks, but the slirp eth does not link up for me

I'll take a look; I've done all my testing with a modified Alpine image (just added an entry for eth1 to /etc/network/interfaces). Will try with default image.

[AkihiroSuda]

https://cloudinit.readthedocs.io/en/latest/topics/network-config.html#fallback-network-configuration

Cloud-init will attempt to determine which of any attached network devices is most likely to have a connection and then generate a network configuration to issue a DHCP request on that interface.

Looks like it only enables the first interface by default.

So we need to generate network config explicitly 😞

https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html#examples

[jandubois]

So we need to generate network config explicitly

Yes, that's what I've been thinking too. I will try if a simple config is going to work:

network:
  version: 2
  ethernets:
    id0:
      match:
        macaddress: '00:11:22:33:44:55'
      dhcp4: true
    id1:
      match:
        macaddress: '00:11:22:33:44:66'
      dhcp4: true

[jandubois]

@AkihiroSuda you said (on Slack): "vde will be eth0 and slirp will be eth1". Does it really matter?

If not then I would prefer to always use eth0 for slirp, so it has a predictable interface name. Otherwise it will be eth1 when you configure vde, but eth0 if you don't.

[AkihiroSuda]

If not then I would prefer to always use eth0 for slirp, so it has a predictable interface name. Otherwise it will be eth1 when you configure vde, but eth0 if you don't.

SGTM

[jandubois]

I've updated the PR to allow the specification of multiple interfaces (e.g. both a host and a bridged network).

For testing I defined 2 interfaces on the same vde_switch (which doesn't make much sense, but shows the feature):

network:
  vde:
  - url: "/var/run/vde.ctl"
  - url: "/var/run/vde.ctl"
    name: "yo0"

With the default template it produces (IPv6 lines removed for brevity):

$ lima ip addr
bash: line 1: cd: /Users/jan/suse/lima: No such file or directory
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 22:11:11:11:11:11 brd ff:ff:ff:ff:ff:ff
    altname enp0s1
    inet 192.168.5.15/24 brd 192.168.5.255 scope global dynamic eth0
       valid_lft 85741sec preferred_lft 85741sec
3: vde0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 22:0b:6d:67:d6:48 brd ff:ff:ff:ff:ff:ff
    altname enp0s2
    inet 192.168.105.11/24 brd 192.168.105.255 scope global dynamic vde0
       valid_lft 84877sec preferred_lft 84877sec
4: yo0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 22:59:7a:b1:ad:46 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 192.168.105.10/24 brd 192.168.105.255 scope global dynamic yo0
       valid_lft 84877sec preferred_lft 84877sec

This required some refactoring, as limayaml.FillDefault now needs the file path of the YAML file to calculate the default MAC addresses. I've also removed limayaml.Validate and renamed ValidateRaw to Validate. The places that used to call the original Validate function had already called FillDefaults anyways, so there was no need for it (unless I missed something).

[AkihiroSuda]

We should also put host UUID to avoid MAC collision when multiple Mac hosts with bridged mode are connected to the same physical network. (Can be another PR)

https://apple.stackexchange.com/questions/342042/how-can-i-query-the-hardware-uuid-of-a-mac-programmatically-from-a-command-line

I guess we can just use hostname instead, but UUID seems more stable than hostname.

We should probably also put user ID to the hasher.

[jandubois]

We should also put host UUID to avoid MAC collision when multiple Mac hosts with bridged mode are connected to the same physical network. (Can be another PR)

I've create #135 for this. Does it make sense to use VDE on Linux too?

We should probably also put user ID to the hasher.

Why would we need this; the full path to the lima.yaml file is already unique for each machine. If 2 users refer to the same config file, they will refer to the same instance. Also for regular operation the filename already includes the user name: /Users/$USER/.lima/$INSTANCE/lima.yaml.

[AkihiroSuda]

Thanks, merging and I'll open a follow-up PR to cover #135