If it's fast creation/destruction of VMs you want, for scale-out or other purposes, there's always ZeroVM. https://news.ycombinator.com/item?id=3746222
Truly elastic clouds with Zerg: OS-less Erlang on Xen
11–20 of 59 posts
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#12"Over capacity" "The demo is limited to 16 concurrent instances and 2 libvirt connections. Due to these limitations we were unable to spawn a new instance to service your request. Please try again later." Um.
I got the same message (02:35 PDT). This must be a joke, given the title. However http://erlangonxen.org works fine.
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#13It sounds like they exchanged one container, an OS managed process, for another one.
This. If you consider KVM, where an OS container is a regular process, then you can see there'd be no point in doing this for KVM since you might as well just run a Linux process. It's only "interesting" for Xen because the Xen hypervisor has a strangely architected and relatively heavyweight "process".
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#14" 0.6 sec ago is when we received your request. Within this time we managed to create a new Xen instance, boot it, and run the application that rendered the page you are viewing. By the time you are done reading this, the instance will be gone. " for a basic page like that is a bit slow...
Presumably the idea is that you run a pool of them, so you're not spawning a new instance each time?
I got the impression that you _are_ expected to spawn a new instance each time.
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#15It sounds like they exchanged one container, an OS managed process, for another one.
The idea behind this systems is that there is no operating system any longer.
The programming language runtime is mapped to execute directly on top of the hypervisor.
There are already such systems for Erlang, OCaml, Haskell and Java runtimes.
If the programming language has a good library, there is no need for an operating system, the hardware access can be taken care by the hypervisor.
This leads to safer and faster servers running on virtual machines.
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#16" 0.6 sec ago is when we received your request. Within this time we managed to create a new Xen instance, boot it, and run the application that rendered the page you are viewing. By the time you are done reading this, the instance will be gone. " for a basic page like that is a bit slow...
Thanks for pointing it out, I gave me an excuse to look at the numbers:
I took 4.6 seconds when I loaded it. In the breakdown ~4.3s of that was nginx dicking around (probably spending much of its time telling people it can't spawn an instance right now.) The lightweight nature of the page is obviously exposing the nginx overhead, which is turning out to be a bottleneck. Based on all that: with more complex pages, a more realistic limit on instances and similar resource utilization, I would expect it to be down right snappy.
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#17Earlier quoted context omitted.
Presumably the idea is that you run a pool of them, so you're not spawning a new instance each time?
I got the impression that you _are_ expected to spawn a new instance each time.
I think so too. But simple pages in this configuration just measure nginx performance (check the breakdown)—that's a good sign for the rest of the process.
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#18It sounds like they exchanged one container, an OS managed process, for another one.
This. If you consider KVM, where an OS container is a regular process, then you can see there'd be no point in doing this for KVM since you might as well just run a Linux process. It's only "interesting" for Xen because the Xen hypervisor has a strangely architected and relatively heavyweight "process".
Agreed, if you are in control of the host OS then you might as well just run some unprivileged processes in some lightweight containers (LXC, or just user/network namespaces + chroot).
There are two situations where running applications directly on the hypervisor might be beneficial though:
- If you have to run multiple untrusted (and possibly malicious) tasks on same host. In this case virtualization provides better isolation/security than just containers or processes (which would be vulnerable to kernel exploits, or other ways of gaining root inside a container allows to take control of the host)
- If the hypervisor is fixed and you can't touch it (i.e. Amazon EC2). In this case running applications directly on the hypervisor might eliminate some of the virtualization overhead.
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#19" 0.6 sec ago is when we received your request. Within this time we managed to create a new Xen instance, boot it, and run the application that rendered the page you are viewing. By the time you are done reading this, the instance will be gone. " for a basic page like that is a bit slow...
True, but the Erlang VM is not really written for fast startup. Module loading is serial and not parallel. The key here is that you can scale up in 0.6 seconds, which is awfully much faster than most other solutions, where scaling takes minutes.
Re: Truly elastic clouds with Zerg: OS-less Erlang on Xen
#20Earlier quoted context omitted.
This. If you consider KVM, where an OS container is a regular process, then you can see there'd be no point in doing this for KVM since you might as well just run a Linux process. It's only "interesting" for Xen because the Xen hypervisor has a strangely architected and relatively heavyweight "process".
Agreed, if you are in control of the host OS then you might as well just run some unprivileged processes in some lightweight containers (LXC, or just user/network namespaces + chroot). There are two situations where running applications directly on the hypervisor might be beneficial though: - If you have to run multiple untrusted (and possibly malicious) tasks on same host. In this case virtualization provides better…
For the first case, I'd rather use something like Google Native Client.
The attack surface of a VM is rather large, particularly when you consider the dozens of emulated devices and instructions. For example, there was a notable hole in SCSI emulation recently discovered which let any guest overwrite any part of a host's disk (by sending some obscure SCSI commands which weren't being filtered by the virtualized device properly).