To save you some time, this is VMs + Unikernels.
Unikernels were my first thought. Thank you for the summary.
LightVM – A new virtualization solution based on Xen
41–50 of 59 posts
Re: LightVM – A new virtualization solution based on Xen
#42Earlier quoted context omitted.
That blog post is pretty crappy. See discussions here: https://news.ycombinator.com/item?id=10953766
The blog post has some flawed arguments, but still there is almost no observability/tracing tools for unikernels.
Try it with the LING Erlang-on-Xen unikernel and see for yourself if it's not debugabble.
Looks like they've got a solution for dubugging: https://twitter.com/erlang_on_xen/status/641628659657371648
Re: LightVM – A new virtualization solution based on Xen
#43Earlier quoted context omitted.
As long as debugging isn't fundamentally incompatible with a unikernel approach, it's just a matter of maturity. And it's pretty silly to criticize a new, prospective technology for immaturity.
> As long as debugging isn't fundamentally incompatible with a unikernel approach, it's just a matter of maturity. Well no, it's not "fundamentally" incompatible, it just doesn't seem very practical. And practicality matters IMHO. Maybe I'm missing something but it seems the debug mode of these systems would be very similar to how you debug a regular kernel. I.e. you have some GDB stub provided by your hypervisor. Th…
Try it with the LING Erlang-on-Xen unikernel and see for yourself if it's not debugabble.
Looks like they've got a solution for dubugging: https://twitter.com/erlang_on_xen/status/641628659657371648
Re: LightVM – A new virtualization solution based on Xen
#44Xen is very much inspired by exokernels (you could even make the argument that it is an exokernel), so it makes sense that someone would push it more in that direction. That being said, if you're going to go that way,it's to bad that there isn't more inspiration from the past 20 years of OS design. A capability based security/object management interface would nice. I also really like Akaros's VM threads model; IMO th…
Akaros looks pretty interesting- the M:N aspect is certainly where I think we need to go.
Re: LightVM – A new virtualization solution based on Xen
#45To save you some time, this is VMs + Unikernels.
Unikernels are mentioned in passing, but are not the cause of the speedup. The main point of the paper is instead the introduction of "LightVM, a complete re-design of the basic Xen control plane optimized to provide lightweight virtualization".
Re: LightVM – A new virtualization solution based on Xen
#46Super excited about this. Amazing progress. Kudos to authors.
Re: LightVM – A new virtualization solution based on Xen
#47Earlier quoted context omitted.
> As long as debugging isn't fundamentally incompatible with a unikernel approach, it's just a matter of maturity. Well no, it's not "fundamentally" incompatible, it just doesn't seem very practical. And practicality matters IMHO. Maybe I'm missing something but it seems the debug mode of these systems would be very similar to how you debug a regular kernel. I.e. you have some GDB stub provided by your hypervisor. Th…
Try it with the LING Erlang-on-Xen unikernel and see for yourself if it's not debugabble. Looks like they've got a solution for dubugging: https://twitter.com/erlang_on_xen/status/641628659657371648
Again, I'm not saying it can't be done. If Erlang+Xen=Debug then that's great.
But if we're comparing unikernel-VMs to containers, my guess is that most users are after the "take my $LANG binary and concatenate it with half a Linux kernel"-workflow. And for that general case, most standard tools are off the table.
Re: LightVM – A new virtualization solution based on Xen
#48Earlier quoted context omitted.
https://hypercontainer.io is also in this space. Doesn't boot as fast as docker, but faster than a normal VM.
Also Clear Containers from Intel - https://clearlinux.org/features/intel%C2%AE-clear-containers
Right, Clear Containers is a feature of both rkt and cri-o container runtimes. rkt has had that feature for a couple years, if I recall correctly.
Re: LightVM – A new virtualization solution based on Xen
#49Re: LightVM – A new virtualization solution based on Xen
#50Earlier quoted context omitted.
As long as debugging isn't fundamentally incompatible with a unikernel approach, it's just a matter of maturity. And it's pretty silly to criticize a new, prospective technology for immaturity.
> As long as debugging isn't fundamentally incompatible with a unikernel approach, it's just a matter of maturity. Well no, it's not "fundamentally" incompatible, it just doesn't seem very practical. And practicality matters IMHO. Maybe I'm missing something but it seems the debug mode of these systems would be very similar to how you debug a regular kernel. I.e. you have some GDB stub provided by your hypervisor. Th…
> Well no, it's not "fundamentally" incompatible, it just doesn't seem very practical. And practicality matters IMHO.
I don't think it's fundamentally impractical either, since a unikernel is simply the parts of the OS that you need compiled into the application binary. Maybe this means it is actually running an SSH server, but I think it will look more like a debug service running in the application (if only because unikernels likely wouldn't have processes or files or other concepts that are designed for a multi-tenant world).
> But it's not very practical.
I think this is the question--do the gains justify the costs. And considering the gains include a reduced attack surface, simpler orchestration, reduced resource allocation, etc. I think this is the case in the cloud market, which is only growing.
> Building a truly isolated container environment for Linux (something like Zones) would also give you isolation and provisioning speed, but you get to keep all your tooling.
You don't get to keep all of your tooling with containers anyway--unless you're rolling your own orchestration and container runtime, you're almost certainly using the tools provided by or building off of your container runtime. This is especially true if your service runs on dozens or hundreds of hosts--you're probably not just SSHing onto prod servers to do your debugging with your ordinary tools; you're relying on something that abstracts over those hosts (of course, there are exceptions, but they're just that: exceptions).