First release of OpenVZ enabled 2.6.32 Kernel ... pvetest repository!

martin

martin

Proxmox Staff Member
Staff member
Apr 28, 2005
754
1,742
223
Hi all,

We just released our first 2.6.32 Kernel with OpenVZ support. The new packages are already available via the pvetest repository (deb http://download.proxmox.com/debian lenny pvetest), everybody is invited to test and give feedback.

The upcoming new ISO installer (available soon) will be based on these packages and this 2.6.32 Kernel.

Short release notes (30.08.2010)

  • New 2.6.32 kernel including OpenVZ support, based on latest Debian Squeeze Kernel
  • Removed KSM (OpenVZ does not support KSM)
  • DRBD tools: update to drbd 8.3.7
  • New KVM user-space tools (0.12.5)
  • New OpenVZ user-space tools (vzctl 3.0.24)
  • Bug fixes
Many thanks for testing.
__________________
Best regards,
Martin Maurer
 
Last edited by a moderator:
Removed KSM (OpenVZ does not support KSM)
Click to expand...
Why?! If it's not supported then keep KVM only fork of 2.6.32. That makes no sense to me really (provided it comes out of pvetest to pve rep. in that state). If something is broken then don't publish it... I thought that BROKEN ksm kept you from using openVZ on 2.6.32.
 
Last edited:
meto said:
Why?! If it's not supported then keep KVM only fork of 2.6.32. That makes no sense to me really (provided it comes out of pvetest to pve rep. in that state). If something is broken then don't publish it...
Click to expand...

Read the announcement. OpenVZ does not support KSM. it is not broken, it is just not supported. We also think of providing an optional KVM only Kernel (later). it is hard to keep all you guys happy ...
 
tom said:
Read the announcement. OpenVZ does not support KSM. it is not broken, it is just not supported. We also think of providing an optional KVM only Kernel (later). it is hard to keep all you guys happy ...
Click to expand...
So maybe if you have to work on new KVM only kernel you could buld them based on latest stable kernel there is. I believe that's good idea since KVM is in kernel itself.
 
meto said:
So maybe if you have to work on new KVM only kernel you could buld them based on latest stable kernel there is. I believe that's good idea since KVM is in kernel itself.
Click to expand...

+1 there are some new features like block IO controller I would like to use. If You are going to split kvm and opevz kernels it would be great if each kernel would provide as many stable features as possible.
 
meto said:
Why?! If it's not supported then keep KVM only fork of 2.6.32. That makes no sense to me really
Click to expand...

We simply can't maintain an unlimited number of kernels. But we need a newer kernel, because 2.6.18 and 2.6.24 are out of date. And not releasing anything does not help either.
 
dietmar said:
We simply can't maintain an unlimited number of kernels. But we need a newer kernel, because 2.6.18 and 2.6.24 are out of date. And not releasing anything does not help either.
Click to expand...
I understand that, but why would you choose something that is broken, ekhm not supported? I guess there are many people here not even remotely interested in OpenVZ due to some inconveniences, as there may be some people who don't care about KVM. Please don't discriminate nobody.

In my mind .24 should be dropped, and .18 should be provided until RH takes care of it. Then you'd have one very stable KVM + OpenVZ yet less feature (.18 -), one OpenVZ + basic KVM (.32) and latest KVM (latest stable). Just my crazy thoughts.
 
Right now there are 3 kernels:
* 2.6.18 - old kvm and most stable openvz
* 2.6.24 - little newer kvm and less stable openvz
* 2.6.32 - quite new kvm and no opevz

Mixing both openvz and kvm is nice in theory but in practice there are two many differences to keep them both feature rich and stable in single kernel. So I guess that it makes sense to keep just two kernels:
* openvz - one that makes the most out of the openvz world
* kvm - one that makes the most out of the kvm world
 
l.mierzwa said:
Mixing both openvz and kvm is nice in theory but in practice there are two many differences to keep them both feature rich and stable in single kernel.
Click to expand...

I am not sure about what feature you talk about? The main issue is see is KSM, and that is of limited use for most people - simply by more RAM is much easier and cheaper (KSM needs to much CPU power).

Anyways, there are plans to release a KVM only kernel using the latest kernel sources (but not now).

And you can always compile one yourself if you really need that.
 
dietmar said:
The main issue is see is KSM, and that is of limited use for most people - simply by more RAM is much easier and cheaper (KSM needs to much CPU power).
Click to expand...
Try to do that on dedicated server, especially on OVH (which is supposed to be your partner). My issue is that Ram is 90% full and CPU is utilized ~20-30% WITH ksm.
 
dietmar said:
I am curious - how much memory do you share/save with KSM on your server?
Click to expand...
On one of our production servers we've got: 227941 pages times 4096 bytes per page = ~ 900MB
4 Linux VMs: CentOS, CloudLinux (CentOS basicly), Ubuntu 8.04, Ubuntu 10.04
I believe, that results could be much better if used in more homogenic environment.
 
dietmar said:
I am not sure about what feature you talk about? The main issue is see is KSM, and that is of limited use for most people - simply by more RAM is much easier and cheaper (KSM needs to much CPU power).

Anyways, there are plans to release a KVM only kernel using the latest kernel sources (but not now).

And you can always compile one yourself if you really need that.
Click to expand...

KSM is one of the features, block IO controller is another (You need 2.6.33), there is vhost-net around the corner, red hat is working on transparent huge pages, so openvz limits Your choices which kernel to use as it works only with few older kernels.
Ram is cheap if You don't want to buy much, I've got few boxes with HP DL360G6, each with 32GB of memory, if I would like to add another 32GB it would cost a lot.
KSM saves me around 20% (last time I checked) eating 30-40% of single core, I run mostly developer and testing boxes and they don't do anything most of the time.
Also please keep in mind that 2.0 will have HA for kvm, so You need extra free RAM to run virtual machines from failed hosts.
 
l.mierzwa said:
KSM is one of the features, block IO controller is another (You need 2.6.33), there is vhost-net around the corner, red hat is working on transparent huge pages, so openvz limits Your choices which kernel to use as it works only with few older kernels.
Ram is cheap if You don't want to buy much, I've got few boxes with HP DL360G6, each with 32GB of memory, if I would like to add another 32GB it would cost a lot.
KSM saves me around 20% (last time I checked) eating 30-40% of single core, I run mostly developer and testing boxes and they don't do anything most of the time.
Also please keep in mind that 2.0 will have HA for kvm, so You need extra free RAM to run virtual machines from failed hosts.
Click to expand...
As my dev box I've got Intel rack server with 12GB of RAM also. 4GB per slot is still peaty expensive (especially in Poland - Mr. Mierzwa should agree) not to talk about 8+.

I'd not risk building my own kernel on remote box without KVM - and forget about it in OVH. I know they have it, but look at the prices. Also if you buy KVM in OVH you can't discontinue to use it - you must cancel your server.

I'd vote for mainline .32 for OpenVZ + KSM-less KVM (for those who CAN add more ram) and latest stable for KVM. Using RHEL kernel may be a good idea also as third option since OpenVZ will definitely stick with it and it will provide KVM (which will be broken by OpenVZ probably as in .18).

Since we are wishing/requesting stuff, I'd like to propose also that you try to cooperate with Ksplice Uptrack (http://www.ksplice.com/) to introduce rebootless kernel upgrades - using and loving it.
 
Last edited:
l.mierzwa said:
KSM is one of the features, block IO controller is another (You need 2.6.33), there is vhost-net around the corner, red hat is working on transparent huge pages, so openvz limits Your choices which kernel to use as it works only with few older kernels.
Click to expand...

Why that is true, you talk about brand new experimental code. And maybe some of that gets backported to 2.6.32 anyways (like many other pieces in the debian 2.6.32 kernel).

Also, I still hope that the OpenVZ team decide to support those features. It would be of great help if some of you request those features on the OpenVZ forum, and comment on the filed bug.

http://bugzilla.openvz.org/show_bug.cgi?id=1623
 
dietmar said:
Why that is true, you talk about brand new experimental code. And maybe some of that gets backported to 2.6.32 anyways (like many other pieces in the debian 2.6.32 kernel).

Also, I still hope that the OpenVZ team decide to support those features. It would be of great help if some of you request those features on the OpenVZ forum, and comment on the filed bug.

http://bugzilla.openvz.org/show_bug.cgi?id=1623
Click to expand...
Done. I've read that bug report earlier. It seams that OpenVZ team couldn't care less about broken KSM. As if they are saying "If we dont use it then who cares if it works"...
 
dietmar said:
Why that is true, you talk about brand new experimental code. And maybe some of that gets backported to 2.6.32 anyways (like many other pieces in the debian 2.6.32 kernel).

Also, I still hope that the OpenVZ team decide to support those features. It would be of great help if some of you request those features on the OpenVZ forum, and comment on the filed bug.

http://bugzilla.openvz.org/show_bug.cgi?id=1623
Click to expand...

All I mean is that mixing openvz and kvm in one kernel means that You are forced to use whatever kernel openvz will support, and it may not be the best kernel for kvm.
This is not an issue, just a opinion. If there some new features that I need are merged to vanilla kernel and marked as stable then I will use vanilla kernel and won't complain about it.
 
You must log in or register to reply here.
Top Bottom