On Friday, 21.08.2015 at 15:46, Antti Kantee wrote: > On 20/08/15 00:36, Andrew Stuart wrote: > >>>thanks go to Andrew > > > >That’s nice of you to say I do appreciate it - it was many, many hours of > >fiddling > > I don't doubt that it was many many hours of fiddling. It's amazing how > perfectly they managed to recreate the device driver development experience > of hitting your head against a black box until either the box breaks or you > pass out. > > If you feel like fiddling quite a few hours more, ec2ivol support could > happen. It might involve contacting people and asking where in the pvgrub > kernel address 0x1310fc is (where the divide-by-zero happens). But of course > it's better to start that investigation by first repeating the problem. > Amazon hasn't made that too easy either, since at least I had to copypaste > some weird security policies to get ec2ivol to even manage to complete the > image upload. But YMMV (and I hope it does).
While drafting my reply to the "fixing rumprun/rumpbake" thread [1] I spent some time researching how we would go about running rumprun unikernels on the three major cloud hypervisors (Amazon EC2, Google Compute Engine and Microsoft Azure). All of them have the following high-level process in common: a) Create a full, partitioned and bootable machine image with the unikernel and possibly some data volumes. b) Upload this image to the relevant storage service and register it as a machine image. c) Launch an instance of the VM. Notably, none of these services are "unikernel-friendly" in that they don't provide any mechanism to pass arguments to the kernel, other than embedding them into the bootloader in the machine image. They do all provide a "metadata service" which lets you get an instance-specific blob of data, but only *after* your network is up, via a HTTP request to a static IP address. Further, all of these services currently hand out IP addresses to VMs using DHCPv4. As Antti writes, we can't possibly attempt to write an abstract tool which handles all three steps above, nor do I think there would be much value in such a tool. However, I think we should provide the following: 1) A "rumpbundle" tool to create machine images suitable for use on cloud hypervisors, i.e. step a) above. 2) Enough auto-configuration by "default" to allow at least the 80% case to "just work" transparently on these services *today*, and, by extension, also locally on Xen/KVM for development and testing. I'm going to postulate a straw man 80% case for discussion: - A unikernel running a network service - With at least one network interface - With zero or more data volumes attached (since files may be baked-in, once that functionality is settled) The above is actually quite easy to autoconfigure: - Find the network interface(s) and run DHCPv4 on them - Find all attached volumes and mount them. This could be done by convention: Inspect the filesystem label, mounting a volume labelled "data" at "/data". Additionally, we could download the instance-specific metadata blob during boot and merge(?) any configuration found there with what has already been packaged in the machine image. Thoughts? P.S. I don't think we should get too hung up on the fact that cloud hypervisors today are not "unikernel-friendly". After all, these services are designed to run classic "full OS" VMs. So, this would be a *minimal* start to get people running today, and hopefully better services will show up in the future.
