Re: LuaJIT-on-Xen?
- From: Justin Cormack <justin@xxxxxxxxxxxxxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sun, 5 May 2013 10:41:46 +0100
On Sun, May 5, 2013 at 6:19 AM, Javier Guerra Giraldez
<javier@xxxxxxxxxxx> wrote:
> 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
I tend to agree, there is a lot you can do with lxc before you need to
go to full virtualization (which also has potential security issues)
if you adopt a multi layer approach to security. I have been trying to
add all the stuff you need to ljsyscall, which has lxc container
support for isolation, also capabilities support, BPF based system
call filtering. There is a bit more to do (cgroups support which is
pretty simple and iptables support). It is certainly much better than
just process isolation (or chroot). But if you already have VM
isolation I can see you may view it as a step backwards.
>
>>> 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.
The advantage in a way of kvm is that we already have some luajit
network drivers for similar hardware
https://github.com/SnabbCo/snabbswitch although some tweaking for the
actual emulated ones is needed. Looking at the Xen stuff you get a raw
message queue but not sure what its characteristics are (I presume it
is potentially lossy for example, but maybe the scheduler takes care
of that?).
I am thinking of doing a Luajit binding to the NetBSD rump kernel
(which is modular components of the kernel functionality that you can
run in userspace on other OSes, eg to run a TCP stack, file systems)
http://www.netbsd.org/docs/rump/ - my plan was to present the same
interface as ljsyscall, but I haven't had a chance to start yet. To
run LuaJIT in a hypervisor you would still need to implement enough
other stuff to get LuaJIT to run, like memory allocation.
Another interim solution is running a minimal Linux kernel (only
compile what little you need) and then use ljsyscall to talk to that.
It will be much less to maintain than a Linux distro. I intend to
package up an example of this using lguest (because it is small and
can run on the command line through a pipe sanely, not because you
might want to use it in production).
Justin
Other related posts:
