Any luck on the LVM stuff so your kernel can be used with cloudlinux or incorporate the same limiting capabilities?

LVE you mean? Not yet, still waiting on openvz to catch up with the 2.6.32's

Yes, sorry LVE - Had LVM on the brain since we were doing some hard drive mappings and mount conversions
Any sort of idea of a time frame?
are we talking a matter of days, weeks, months, quarters, next year?

I dont know when or even if they're planning on updating openvz to the later 2.6.32 kernels. I suspect that they dont have a lot of pressure to do it with the redhat kernel being in a known state like it is. Which means we'd have to update that code, and last I checked there were over 150 files in conflict stil.

LVE itself if you're not familiar with its internals is reliant on the openvz scheduler. It doesnt really use any other part of openvz, so maybe its possible to get that scheduler separated. The other possible option is that cloudlinux would dump openvz's scheduler since you cannot actually *use* openvz with cloudlinux. They could also adopt one of the other schedulers that made it into the mainline kernel (openvz will probably never make it). One of the other downsides with it is that you have to get rid of the Cgroups support (this allow you to allocate resources like CPU, memory, bandwidth, etc to processes or users), so we'd probably have to have 2 forks of the ASL kernel to keep that intact.

The RHEL6 OpenVZ kernel is based on the RHEL6 2.6.32 kernel. Or am I missing something?

http://wiki.openvz.org/Download/kernel/rhel6

semi-sorta-kinda. It was at one point in its life 2.6.32 (not 2.6.32.1, not 2.6.32.59). it is now, some 1400 patches later... something else.

Ah ok, you were talking about vanilla 2.6.32.

Vanilla 2.6.32 I could do, vanilla 2.6.32.59 on the other hand.... 150 files in conflict.

Its even more work that it seems. As you may know, 2.6.32 is the stable branch, which has changing for several years now. So unlike in the past where 2.6.32 was just 2.6.32, we have over 60 revisions to that branch alone over several years. Its a bit like comparing 2.6.12 and 2.6.18, theres gaps between them. The same is the case for 2.6.32, a lot changes in the 32 tree from rev to rev. (Fixes though, so not big leaps like 18 to 32)

The current openvz kernel is based on a version of 2.6.32 from either late 2010 or maybe January of 2011. A lot has changed in 2.6.32 since then, and even more has changed from the version of the kernel they started with. In short, they have not kept up with 2.6.32, their patches are totally out of date.

So they need to catch up to where 2.6.32 is now. What they have now is based on a very old and really out of date version of 2.6.32.

Who is 'they' you're referring to exactly? OpenVZ? Or Red Hat (Enterprise Linux 6)?

I understand this situation makes it hard for you to incorporate their patches into the ASL kernel, which does track the vanilla kernel development more closely, but I guess it makes sense from their perspective and it's totally expected for an enterprise Linux distribution to operate like this.

Openvz mostly (although because openvz is using the Redhat backports, Redhat plays a small role in this too). The openvz code for 2.6.32 is based on a kernel that is over a year old. That kernel itself (2.6.32, and not 2.6.32.x) is old and no longer maintained branch of the 32 kernel.

Openvz/Parallels/whomever has not kept up with 2.6.32, its just a series of backports against the vanilla 2.6.32 with redhats backports in there presumably to address fixes/security issues etc. Aside from the security enhancements in our kernel not being designed for the way out of date 2.6.32, so they would have to be backported (if its even possible), it just does not make any sense for us to do this.

The 32 tree is a stable branch, unlike Redhat who wont support the stable branch, we have no problem supporting it. In this case Redhats choice to stick with an old branch is a bad one IMHO, this isnt like 2.6.18 when backporting might have made some sense because newer kernels might change things radically, that doesnt happen in 32. The whole point of the 32 tree is long term support. Theres a ton of people working on that, there's less people working on the Redhat backports, and even less working on the openvz forks and backport refactoring.

The latest openvz patch is over 1400 patches to the base 2.6.32 kernel, which as I said is years old, and includes some of red hats back ports. Its a mess of changes and bafflingly unnecessary. Lots and lots of fixes have been committed to 2.6.32, this would be more like someone putting out a patch for 2.6.0, and ignoring everything up to 32, just backporting fixes (and hopefully doing it correctly).

IMHO, its risky to rely on a kernel like that if security is your priority, and security IS our priority. The shear volume of fixes in 32 alone makes me wary that someone might get a backport wrong, because redhat backports themselves dont always work with the openvz modifications, these backports themselves to be fixed to work with the openvz kernel modifications. Or someone might misunderstand the backport, as what happened with Debians well intentioned changes to openssl, that eviscerated the key generation engine. Security is hard enough as it is.

I would not personally recommend a kernel with that many changes, they may be backported, but can you be sure, are you sure it was done right? Theres no telling what might be missing or just wrong.

Since our first priority is security, this kind of fork is risky. We put a lot of eyes on the current 2.6.32 branch, but forks like this are unnecessary for us. We already support the current 2.6.32.x tree, we dont need to do backports. I'm not sure why Redhat does this either. If redhat is backporting fixes and security fixes, then why isnt Redhat using the current 2.6.32.x release? Its a stable tree, this is why 2.6.32 is there. Thats the whole point, its stable, and its why we have the 3.x tree for new features.

Our focus is on bringing the openvz code up to date with the current 2.6.32.x stable. Forks are not a good idea in security where you need lots of eyes, and not a lot of people are paying attention to that fork. So we are working on this, but we wont be using the fork patch on the openvz site, its not a good fit for our priorities of putting security first.