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

LightVM – A new virtualization solution based on Xen

cnp.neclab.eu

Post reply on HN
Print view View original

31–40 of 59 posts

Re: LightVM – A new virtualization solution based on Xen

#31

Post by monocasa »

Xen 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 that'll be the way we end up running what we currently call unikernels.

Re: LightVM – A new virtualization solution based on Xen

#32

Post by _joel »

tyingq wrote: post #10
mapsnapps wrote: post #4

If I'm reading this right, that's pretty major. The isolation benefits of a VM with a bootspeed faster than docker?

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

Re: LightVM – A new virtualization solution based on Xen

#33

Post by jpalomaki »

bmitch3020 wrote: post #28

VM's tend to lose the overlay layered filesystem which can dramatically reduce disk usage. Having the filesystem reset to a clean state for every new container is a huge feature of containers. And VM's tend to need predefined dedicated resources for things like memory. A process in a container would only allocate memory when it needs and can free up for other processes to use. It's not all about the startup speed. Th…

>Having the filesystem reset to a clean state for every new container is a huge feature of containers.

Could you use file system snapshots for this? Maybe also for the layers?

Re: LightVM – A new virtualization solution based on Xen

#34

Post by wise0wl »

Philipp__ wrote: post #24
weberc2 wrote: post #16

Earlier quoted context omitted.

Boot speed is a big selling point for Docker, but Docker's isolation story is poorer than a VM. If you can make a VM boot as quickly as Docker while preserving isolation, then Docker loses a big selling point.

It’s called Zones (on illumos, prev. on Solaris)

I'm a huge fan of Illumos and SmartOS and think that Zones + LX Branding are a far superior technology than the hodgepodge of cgroups + namespaces + userland container technology. HOWEVER---the amount of driver support in the OpenSolaris forks, the awful package management system, the ancient IPF system etcetera make it a non-starter for most environments. I have used SmartOS in production (along with the Triton ecosystem) and found it to be well thought out and compelling, albeit woefully immature and buggy.

I think that these reasons, plus the EOL nature of Solaris "upstream", would easily put off most people in charge of making a long term technology commitment. I know it did for me.

Re: LightVM – A new virtualization solution based on Xen

#35

Post by tilpner »

bmitch3020 wrote: post #28

VM's tend to lose the overlay layered filesystem which can dramatically reduce disk usage. Having the filesystem reset to a clean state for every new container is a huge feature of containers. And VM's tend to need predefined dedicated resources for things like memory. A process in a container would only allocate memory when it needs and can free up for other processes to use. It's not all about the startup speed. Th…

An example for such an alternative backend would be runv, which can apparently be used with Docker (though I couldn't get it to work well, but that was probably just my fault)

https://github.com/hyperhq/runv#run-it-with-docker

Re: LightVM – A new virtualization solution based on Xen

#36

Post by uytuijhgj »

lbotos wrote: post #12
mapsnapps wrote: post #4

If I'm reading this right, that's pretty major. The isolation benefits of a VM with a bootspeed faster than docker?

I haven't been on the server side in a while, but 1) isn't Xen falling out of favor and 2) is docker boot speed a big problem?

> isn't Xen falling out of favor

what are you talking about? somebody tell amazon, stat!

idiot. one shouldn't talk when one doesn't know what he's talking about.

Re: LightVM – A new virtualization solution based on Xen

#37

Post by mastax »

jpalomaki wrote: post #33
bmitch3020 wrote: post #28

VM's tend to lose the overlay layered filesystem which can dramatically reduce disk usage. Having the filesystem reset to a clean state for every new container is a huge feature of containers. And VM's tend to need predefined dedicated resources for things like memory. A process in a container would only allocate memory when it needs and can free up for other processes to use. It's not all about the startup speed. Th…

>Having the filesystem reset to a clean state for every new container is a huge feature of containers. Could you use file system snapshots for this? Maybe also for the layers?

If it works for docker[1], it probably works for this.

[1]: https://docs.docker.com/engine/userguide/storagedriver/zfs-d...

Re: LightVM – A new virtualization solution based on Xen

#38

Post by tinco »

contingencies wrote: post #26

Great job and nice to see Romania featuring in the news! To those who just spent the last two years retraining your teams and retooling your infrastructure explicitly for docker (who may show up in this thread embracing and enhancing with a large marketing budget shortly), do take this opportunity to learn the architectural and management/maintenance value of abstraction. ;)

You do realize that Docker containers have an abstract interface and can be run on all OCI runtimes right?

Re: LightVM – A new virtualization solution based on Xen

#39

Post by wkz »

weberc2 wrote: post #18
wkz wrote: post #14

Earlier quoted context omitted.

With the debugging benefits of a brick.

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. That might be fine for GDB, but what about all the tools to observe a running system? How would I ftrace, perf, strace, netstat, tcpdump, poke around in /proc and /sys etc?

Sure there is noting stopping you from developing equivalent tools. But it's not very practical. 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.

Post reply on HN