Slashdot Mirror

"Paravirtualization is really only useful when the host CPU doesn't have the hardware necessary for virtualization."

That's not true. Paravirtualization can provide better performance in either case. From the virtio wiki

So-called "full virtualization" is a nice feature because it allows you to run any operating system virtualized. However, it's slow because the hypervisor has to emulate actual physical devices such as RTL8139 network cards . This emulation is both complicated and inefficient.

Virtio is a virtualization standard for network and disk device drivers where just the guest's device driver "knows" it is running in a virtual environment, and cooperates with the hypervisor. This enables guests to get high performance network and disk operations, and gives most of the performance benefits of paravirtualization.

Note that virtio is different, but architecturally similar to, Xen paravirtualized device drivers (such as the ones that you can install in a Windows guest to make it go faster under Xen). Also similar is VMWare's Guest Tools.

The difference is BSD Jails are entirely separate environments with their own unshared kernel datastructures, and the jail communicates with the host via an API. Linux namespaces is just metadata added to shared environments.

I'm sorry, but this notion is completely wrong. A BSD Jail is a forked process (the "jail process"), which calls the "jail" kernel system call and then executes a chroot. The jail syscall serves to attach the "prison" data structure to the "proc" data structure of the jail process, allowing the kernel to identify the process as "jailed" and treat it accordingly. The isolation of the environments is dependent entirely on the kernel recognizing that the process is jailed and putting the appropriate restrictions on it.
https://www.freebsd.org/doc/en...

An LXC container is a forked process with a chroot that is assigned a set of namespaces, which are then restricted by kernel cgroups and kernel capabilities. The end result is that the forked process is only able to communicate with other processes within its namespace and is only allowed to access resources that cgroups allow that namespace to access. The only way for a containerized process to communicate with the host is through a vnet bridge device, which is similar to way it works with Jails.
https://libvirt.org/drvlxc.htm...

So in other words, the specific implementations details are different, but the result is nearly identical. A forked process executes a chroot and then is assigned a special status by the kernel which determines which resources it can access and which processes it can communicate with.

KVM provides full virtualization with hardware acceleration, and the line between Type 1 and Type 2 is significantly blurred by virtue of the fact that the loadable kernel module for it does indeed operate as a bare metal hypervisor. You aren't limited to Linux guests, either. I've got a combination of Linux, BSD, Windows, and Solaris guests running in a cluster right now. These guests run unmodified, and performance is admirable. In fact, it's better than I've achieved on similar hardware with VMware, and I actually have better control of the entire network stack from a host perspective via ebtables and arptables. Fine grained resource management is available via cgroups facilities.

Do you actually operate anything in a KVM environment?

libvert is what communicates to the virtualized instance, and is the actual OS abstraction that runs on top of Xen in this case.

If there's no OS, we code to the metal, and there's zero "elasticity" in terms of being able to pop your process into any available machine in the cloud.

libvirt maybe ? It is a library and tooling for handling all kinds of VM.

http://libvirt.org/
http://virt-manager.et.redhat.com/

Here is a list of applications:

http://libvirt.org/apps.html

Or maybe this ?:

http://community.abiquo.com/display/ABI17/Abiquo+Documentation+Home

libvirt maybe ? It is a library and tooling for handling all kinds of VM.

http://libvirt.org/
http://virt-manager.et.redhat.com/

Here is a list of applications:

http://libvirt.org/apps.html

Or maybe this ?:

http://community.abiquo.com/display/ABI17/Abiquo+Documentation+Home

You mean something like libvirt and derivatives?

Overall that sounds like a pretty good mix of languages. Far more important to get a wide understanding of different approaches than to learn any one language exclusively, and in the short term a mix is also much more marketable.

The only omission is functional programming, which is not yet commercially important but is incredibly powerful - one example is mlvirsh, which is a rewrite in the OCaml functional language of a C-based library, reducing number of lines of code by 85% - see http://libvirt.org/ocaml/README.txt for the stats.

Redhat are dropping Xen like a hot potato and moving to KVM.

Is there an actual citation to back that up? What a bunch of misinformed FUD. Red Hat is taking a more Hyper-Visor agnostic approach. In other words they are building management tools which will work across all the major Open Source virtualization platforms. Red Hat is not going to dictate whether their customers run KVM, Xen, or QEMU.

While I MAY agree that their current solution are not so mature, still they are very powerful, extendable and generic. Given enough (not so much) time they can compete and overtake proprietary solutions. See http://libvirt.org/

KVM is nice and shows promise, but performance wise the paravirtualized approach of xen is still significantly faster (as in very-near-bare-metal, even significantly faster than vmware ESX on most loads).

VirtIO, which is in latest versions of KVM, paravirtualizes all the hardware and gives you almost all the benefit.

KVM is where things are going because as a poster said above, it avoids having to write all the drivers twice over. Xen dropped the ball by not working closely with the Linux kernel developers. Now XenSource have been bought out by a Microsoft proxy, so the future for Linux & Xen is looking even less rosy.

As you say, Red Hat offers libvirt which hides the differences between virtualization systems, so for most administrators and application programmers, which system "wins" is not going to matter. (My personal opinion is that none of them will win outright, at least not for many many years - different approaches to virtualization are suitable for different areas).

Rich.

XenSource/Citrix, Virtual Iron, Red Hat, and Novell have invested millions in Xen, and for the sake of backwards compatibility they are now stuck with it.

You are wrong. Red Hat and others have invested in libvirt and all the virtualisation management tools they ship are based on libvirt. Libvirt supports Xen, QEMU and KVM, and will soon support OpenVZ too. There is also discussion about supporting VMWare.

Rich.

XenSource/Citrix, Virtual Iron, Red Hat, and Novell have invested millions in Xen, and for the sake of backwards compatibility they are now stuck with it.

You are wrong. Red Hat and others have invested in libvirt and all the virtualisation management tools they ship are based on libvirt. Libvirt supports Xen, QEMU and KVM, and will soon support OpenVZ too. There is also discussion about supporting VMWare.

Rich.

Red Hat do this because Xen trademarked the term and restrict its usage.

The comment about libvirt is funny though. I would invite anyone to come and look at libvirt and particularly the mailing list archives and to decide for themselves if libvirt is really "proprietary software published openly" (whatever that even means).

Rich.