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.
Atomicorp - Security For Everyone
Co-Author of Troubleshooting Linux Firewalls.