Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A unikernel experiment: A VM for every URL

skjegstad.com

Post reply on HN
Print view View original

21–30 of 34 posts

Re: A unikernel experiment: A VM for every URL

#21

Post by avsm »

rdtsc wrote: post #12

Already exists for Erlang. Here is a demo: http://erlangonxen.org/ Site is running on such a VM as well, press escape for a console to see stats. Here is an example output from running their demo: --- 300 sec : is how long it takes to launch a Linux instance to availability on Amazon EC2. 50 sec : is the time between power on and the lock screen for an Android phone. 0.4 sec : ago is when we received your request. Wi…

Note that both of the setups are quite different in how they boot unikernels. The EoX Zerg demo boots one unikernel per connection by having an HTTP proxy in the frontend spin up the VM.

Magnus' version builds a static set of unikernels whose total resource usage is known ahead of time, and boots them based on DNS lookups as necessary. Because there is a race between a DNS response, the first TCP SYN from the client, and the VM booting up to receive it, there is a helper unikernel called "Synjitsu" which terminates TCP connections and replays them to the MirageOS unikernel as soon as it boots up. This is very easy due to the OCaml TCP/IP stack in Synjitsu sharing its state via serialising it into an s-expression. More gory details in http://anil.recoil.org/papers/2015-nsdi-jitsu.pdf

Now, imagine a version of Synjitsu that did this handover with TLS connections rather than just TCP. The recipient unikernel wouldn't ever even have to know the private key, just the ephemeral session key...

Re: A unikernel experiment: A VM for every URL

#22

Post by avsm »

jacques_chester wrote: post #19
avsm wrote: post #16

Earlier quoted context omitted.

> I think the obstacle is that most folk are not prepared to give up their languages s/languages/frameworks, and I agree. One step at a time -- this work is a foundational block that we're building on, not the ultimate solution.

Hm. Got me thinking about how to fit unikernels into the CF architecture, which is largely taking containers (Garden or Docker, take your pick) as the unit of currency at the low level. It looks like the place to make the change would be in Diego in the Executor[0][1] component, which currently implements behaviour in terms of containers (using Linux-Garden as the container system). So long as you can conceptually fi…

Thanks, this are all really helpful pointers! It's particularly useful to find Lattice, which seems to be a simpler entry point than a full CF setup.

Re: A unikernel experiment: A VM for every URL

#23

Post by thomaskauth »

NhanH wrote: post #10

I've always thought that something really cool could be done with unikernel for SaaS: you let each of your customer have a VM on their own, spinning the unikernel up when the requests came in, and let it process any request come in, after a while, if the specific user stop requesting then you kill the VM. There seems to be a lot of benefits from that: single user authentication, horizontally scaling is simple ("verti…

I did something similar during my PhD. Maybe you want to have a look: http://se.inf.tu-dresden.de/pubs/papers/knauth2014dreamserve...

It was published at SYSTOR last year (2014).

Re: A unikernel experiment: A VM for every URL

#24

Post by jacques_chester »

avsm wrote: post #22
jacques_chester wrote: post #19

Earlier quoted context omitted.

Hm. Got me thinking about how to fit unikernels into the CF architecture, which is largely taking containers (Garden or Docker, take your pick) as the unit of currency at the low level. It looks like the place to make the change would be in Diego in the Executor[0][1] component, which currently implements behaviour in terms of containers (using Linux-Garden as the container system). So long as you can conceptually fi…

Thanks, this are all really helpful pointers! It's particularly useful to find Lattice, which seems to be a simpler entry point than a full CF setup.

The shiny website was new to me. I wonder if we've officially announced it yet?

In any case, we started the Lattice effort last year to make it easier for people to play with Diego without having to stand up a whole Cloud Foundry installation.

My only Lattice-related claim to fame is not knowing what is was: https://github.com/pivotal-cf-experimental/lattice-app/issue...

Re: A unikernel experiment: A VM for every URL

#25

Post by mwcampbell »

I suppose work like this is demonstrating that, contrary to what e.g. the creators of Docker say, a virtual machine image is not too heavyweight to be our industry's equivalent of a shipping container. What is too heavyweight is a VM image of a conventional operating system distribution with all of the baggage that it brings.

Would these fine-grained unikernels also run well on KVM, VMware ESXi, Hyper-V, or bhyve (FreeBSD's new VMM)? Or is Xen uniquely suited to this kind of thing?

Re: A unikernel experiment: A VM for every URL

#26

Post by rdtsc »

avsm wrote: post #21
rdtsc wrote: post #12

Already exists for Erlang. Here is a demo: http://erlangonxen.org/ Site is running on such a VM as well, press escape for a console to see stats. Here is an example output from running their demo: --- 300 sec : is how long it takes to launch a Linux instance to availability on Amazon EC2. 50 sec : is the time between power on and the lock screen for an Android phone. 0.4 sec : ago is when we received your request. Wi…

Note that both of the setups are quite different in how they boot unikernels. The EoX Zerg demo boots one unikernel per connection by having an HTTP proxy in the frontend spin up the VM. Magnus' version builds a static set of unikernels whose total resource usage is known ahead of time, and boots them based on DNS lookups as necessary. Because there is a race between a DNS response, the first TCP SYN from the client,…

That is just a demo to show startup times. Presumably (just by looking at it from a high level) a proxy instance for handling initial connection + a pre-allocated, or maybe booted but paused, set of worker images would work in either architecture.

Re: A unikernel experiment: A VM for every URL

#27

Post by amirmc »

mwcampbell wrote: post #25

I suppose work like this is demonstrating that, contrary to what e.g. the creators of Docker say, a virtual machine image is not too heavyweight to be our industry's equivalent of a shipping container. What is too heavyweight is a VM image of a conventional operating system distribution with all of the baggage that it brings. Would these fine-grained unikernels also run well on KVM, VMware ESXi, Hyper-V, or bhyve (Fr…

> "What is too heavyweight is a VM image of a conventional operating system distribution with all of the baggage that it brings."

Indeed. I didn't realise that Docker/Container folks had ever said VMs were too heavyweight. Is this linked anywhere?

> "Would these fine-grained unikernels also run well on KVM, VMware ESXi, Hyper-V, or bhyve (FreeBSD's new VMM)?"

We've been asked this before and for KVM at least, it just boils down to someone suitably motivated to write the boot and VirtIO code [1, 2]. If anyone's interested in this, we'd love to hear about it [3]!

[1] http://lists.xenproject.org/archives/html/mirageos-devel/201...

[2] http://lists.xenproject.org/archives/html/mirageos-devel/201...

[3] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageo...

Re: A unikernel experiment: A VM for every URL

#28

Post by mwcampbell »

amirmc wrote: post #27
mwcampbell wrote: post #25

I suppose work like this is demonstrating that, contrary to what e.g. the creators of Docker say, a virtual machine image is not too heavyweight to be our industry's equivalent of a shipping container. What is too heavyweight is a VM image of a conventional operating system distribution with all of the baggage that it brings. Would these fine-grained unikernels also run well on KVM, VMware ESXi, Hyper-V, or bhyve (Fr…

> "What is too heavyweight is a VM image of a conventional operating system distribution with all of the baggage that it brings." Indeed. I didn't realise that Docker/Container folks had ever said VMs were too heavyweight. Is this linked anywhere? > "Would these fine-grained unikernels also run well on KVM, VMware ESXi, Hyper-V, or bhyve (FreeBSD's new VMM)?" We've been asked this before and for KVM at least, it just…

> Indeed. I didn't realise that Docker/Container folks had ever said VMs were too heavyweight. Is this linked anywhere?

https://github.com/docker/docker#user-content-better-than-vm...

Post reply on HN