I agree with Mato that there is too much complex configuration, and over 90% of use cases are covered by convention over configuration ie dhcp+slaac on all network interfaces and I like the idea of using volume labels for mount points. This is I think the best short term solution to get people started.
The cases where you don't want this (eg a network switch or your dhcp server) I don't think the current json configuration is that useful as the device will need to manage more configuration than that and will want to be able to manage and update its own configuration with its own code. Open Containers are defining a standard json config, but it is more aimed at the tool doing the launching than the unikernel itself, although some data will need to be passed to the runtime. The launchers for xl and qemu/kvm should be standalone tools. Right now these are needed and a bit complicated, but longer term unikernels will define their own interfaces, eg there is no need for qemu, and qemuless kvm is becoming a thing again (eg Intel's Clear Containers) and clearly we want to use something like that longer term. You can also make the whole developer experience locally much nicer - eg you could potentially use binfmt-misc to make unikernel binaries appear to be standard executables so you dont have the whole cross compile experience (as with frankenlibc now but virtualised). Overall I think a few simple things that work and are easy to use should be the aim. eg KVM on a laptop, and an automated install of Xen on bare metal with everything ready to go (eg one click on a service provider that allows automated bare metal installs). Mostly EC2 seems too complex and the machines are mostly too large anyway, although a Xen pv on HVM image should be possible. Justin
