Re: [MirageOS-devel] Unikernels on clouds? Just a mirage....

[Mindy <mindy@xxxxxxxxxxxxxxxxxxx>]

On 11/14/2016 06:17 AM, Andrew Stuart wrote:

> Sorry about the jokey subject line.
>
> This is both an FYI and a request - the request to MirageOS is at the bottom of 
> this wall of text.
[snip]
> ###### SO, what does that all mean?
>
>
> Well, my goal is to be able to boot HVM unikernels directly on the clouds, 
> without containers.
>
> Despite the challenges posed by the various approaches to networking, the 
> solutions are actually pretty simple.
>
> To make a unikernel run, here is what that unikernel would need to implement:
>
> ** HVM unikernel on AWS - unikernel must implement DHCP
AFAIK, MirageOS does the right thing here.  I'll have occasion to make 
sure this still works in MirageOS 3 shortly.
> ** HVM unikernel on GCE - unikernel must implement DHCP with option 121
I recently broke this, but it's fixed now.  (See 
https://github.com/mirage/mirage/issues/674 for more information. We 
don't get the route information via option 121 but rather via option 3, 
which is also provided; this seems to work.)
> ** HVM unikernel on Digital Ocean - unikernel must accept a network interfaces 
> file containing static IP address configuration
> ** HVM unikernel on Rackspace - boo Rackspace - no help for developers!
> ** HVM unikernel on Softlayer I don’t think this will happen any time soon, but out of 
> interest it’s static IP addressing injected at boot time
>
> In fact it would be ideal to be able to pass an /etc/network/interfaces file in 
> to a unikernel specifying either dhcp or static IP address configuration. This 
> could be a standard approach regardless of which cloud.
>
> Ideally this would be passed in to the unikernel at boot time in an initramfs 
> file, which would look like the initrd line in the example grub.cfg here, i.e. 
> rootfs.cpio.gz
>
> serial --speed=115200 --word=8 --parity=no --stop=1
> terminal_input --append  serial
> terminal_output --append serial
> set timeout=1
> GRUB_TIMEOUT=1
> menuentry ‘mirage' {
> linux /boot/mirageunikernel root=/dev/ram0 console=ttyS0,115200
> initrd /boot/rootfs.cpio.gz
> }
We've recently made some changes to how network stacks and ipv4 are 
configured in MirageOS that should make it easier to inject information 
from arbitrary sources, including from something that looks like a 
filesystem (although we'd need a parser for /etc/network/interfaces in 
order to do anything useful with the information).  I'm not sure how 
initramfs passing itself would work, although ISTR this perhaps being 
done in Xen via the iso9660 library sometime in the distant past?
Thanks very much for this writeup, Andrew!  Knowing that this is a 
blocker for several deployment environments gives me some perspective 
that I was missing with your last mail.
Thanks,
Mindy

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel