Hi,
the recent introduction of the "new-style" network interface configuration
on rumprun is a major usability setback.
Compare the old-style and new-style ways of getting a network interface
running on Xen:
rumprun xen -n inet,dhcp ...
rumprun xen -I if0,xenif -W if0,inet,dhcp
With the old-style syntax, it was minimal and obvious: Give me a virtual
network interface, and please run IPv4 and DHCP on it.
The new-style syntax has sacrificed "usability" for "flexibility": I now
have to invent an "iftag", and I also have to remember what the
"ifbasename" of the virtual interace is on this particular platform. The
latter I *always* get wrong and is an implementation detail I shouldn't
have to care about for a unikernel running on a cloud hypervisor.
Granted, the new syntax makes it possible (fsvo possible) to configure kvm
and qemu network interfaces. An example of such a configuration:
rumprun kvm -I 'qnet0,vioif,-net tap,ifname=tap0' -W qnet0,inet,dhcp
Unfortunately, the above syntax is equally obscure and does not make any
attempt to abstract away the qemu backend configuration which appears to
depend on your particular qemu version and distribution setup.
What I'd like to get to, in terms of usability, is that a rumprun unikernel
running on a cloud hypervisor (Xen, KVM (fsvo), AWS) should "just work" for
the 80% case without needing to pass special configuration of any kind.
A straw-man proposal for how this might work:
Unikernel side:
1) rumpconfig would be modified so that if no (network) configuration is
passed, all network interfaces found will be brought up.
2) DHCPv4 and IPv6 SLAAC will be performed on all interfaces.
Rumprun side:
I'm less sure about what to do here. For Xen, the old-style syntax works
because the xl toolstack has sensible defaults for backend network
configuration (vif.default.* in /etc/xen/xl.conf). With autoconfiguration
enabled in rumpconfig we could resurrect the old syntax, simplified even
further to just "-n auto[,backendopts]".
For AWS, this is currently out of scope (i.e. configured out-of-band using
AWS tools).
For KVM, well, it's a mess. AFAICT there is no comparable default backend
configuration for a KVM network setup and there is no standard way to
enumerate interfaces (i.e. no straightforward concept of "first
interface") if you are using any non-virtio drivers.
Perhaps the right approach is to support *only* the simplified form of
network configuration via "rumprun -n" (i.e. Xen PV and KVM with virtio
interfaces *only*) and for everything else rather than attempting to do it
via command line options require that the user supply a full JSON
configuration?
Thoughts? I realise my solution is very incomplete, but the problem I'm
addressing is real.
Martin
