Re: LuaJIT-on-Xen?
- From: Javier Guerra Giraldez <javier@xxxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sun, 5 May 2013 00:19:27 -0500
On Sat, May 4, 2013 at 11:54 PM, Alexander Gladysh <agladysh@xxxxxxxxx> wrote:
>> Xen itself (as of a few years ago) is pretty well documented in "The
>> Definitive Guide to the Xen Hypervisor". But it's not clear to me that
>> there are advantages to Xen as a hypervisor relative to, say, kvm or
>> even LXC.
>
> Well, Xen vs. kvm is debatable, but, AFAIK, LXC does not allow any
> meaningful resource management, and reuses the host kernel. We had
> this with OpenVZ years ago, and that was quite enough..
LXC "containers" are quite nice. they all use the same kernel, so
there's no "extra" virtualization overhead. you can limit CPU,
network bandwidth, IO, RAM, etc, you can suspend, freeze, save,
restore, migrate... it basically does everything Virtuozzo did ages
ago (and OpenVZ after that). I think the administration tools are not
so polished, but now it's fully supported from libvirt and OpenStack.
in fact, this project would be almost trivial with LXC, since a
container starts with an arbitrary process that becomes the root of
the subtee, and looks like PID#1 "from inside". if that process is
"init", and you give it a full installation in the chroot, then you
have a new OS in a VM. if it's any other proces (say, a LuaJIT
worker!) then it's a lot simpler, like a better chroot
>> If you're stuck on a Xen host, of course, yes, it would be
>> nice to be able to toss the OS in the DomU out and get down to "bare
>> metal" Xen.
>
> Are you suggesting that it will be easier with, say, kvm?
I don't think so. kvm doesn't have a 'paravirtualization' flavor, so
everything looks like hardware. even virtio (the generic interface
below the "paravirtualized drivers") is presented like a PCI hardware.
Xen syscalls are slightly higher level.
--
Javier
Other related posts:
