Are there any plans on the roadmap to add kernel support for virtual environments (as opposed to virtual machines). I'm referring to OpenVZ and Linux-vServer here.
On Fri, 2007-06-29 at 12:24 -0400, Gerry Reno wrote:
Are there any plans on the roadmap to add kernel support for virtual environments (as opposed to virtual machines). I'm referring to OpenVZ and Linux-vServer here.
Most likely not until they are in the upstream kernel.
josh
Josh Boyer wrote:
On Fri, 2007-06-29 at 12:24 -0400, Gerry Reno wrote:
Are there any plans on the roadmap to add kernel support for virtual environments (as opposed to virtual machines). I'm referring to OpenVZ and Linux-vServer here.
Most likely not until they are in the upstream kernel.
josh
Do you know when they will make it in the upstream kernel?
On Friday 29 June 2007 12:35:05 Gerry Reno wrote:
Do you know when they will make it in the upstream kernel?
Magic 8 ball says....
Seriously some of these may never make it in. It all depends on the motivations of the teams producing these things.
On Fri, 2007-06-29 at 12:34 -0400, Jesse Keating wrote:
On Friday 29 June 2007 12:35:05 Gerry Reno wrote:
Do you know when they will make it in the upstream kernel?
Magic 8 ball says....
Seriously some of these may never make it in. It all depends on the motivations of the teams producing these things.
Right. It would be better to ask the OpenVZ and Linux-vServer projects when they are going to push for upstream inclusion. Even once that has started, it can take a few months to get accepted, depending on how things go.
josh
"JB" == Josh Boyer jwboyer@jdub.homelinux.org writes:
JB> Right. It would be better to ask the OpenVZ and Linux-vServer JB> projects when they are going to push for upstream inclusion. Even JB> once that has started, it can take a few months to get accepted, JB> depending on how things go.
OpenVZ is pushing the network bits already. The reception on the linux-networking list has not been overly enthusiastic.
/Benny
Jesse Keating wrote:
On Friday 29 June 2007 12:35:05 Gerry Reno wrote:
Do you know when they will make it in the upstream kernel?
Magic 8 ball says....
LOL :-)
Seriously some of these may never make it in. It all depends on the motivations of the teams producing these things.
I've been trying to follow some of the discussion on 'linux-kernel' about all this 'partitioning' and 'containers' related to openvz and linux-vserver but I couldn't really get a sense of when something might come of this. So I guess I was looking if someone knew of a target date. I couldn't find any.
On Fri, 2007-06-29 at 12:34 -0400, Jesse Keating wrote:
On Friday 29 June 2007 12:35:05 Gerry Reno wrote:
Do you know when they will make it in the upstream kernel?
Magic 8 ball says....
Seriously some of these may never make it in. It all depends on the motivations of the teams producing these things.
The vserver guys have tried in the past to get it in, but they got some pushback on some things, and they now seem completely uninterested taking the time needed to clean their stuff up and actually get it into the kernel. I wouldn't hold out much hope unless something changes dramatically.
Dan
Dan Williams wrote:
On Fri, 2007-06-29 at 12:34 -0400, Jesse Keating wrote:
On Friday 29 June 2007 12:35:05 Gerry Reno wrote:
Do you know when they will make it in the upstream kernel?
Magic 8 ball says....
Seriously some of these may never make it in. It all depends on the motivations of the teams producing these things.
The vserver guys have tried in the past to get it in, but they got some pushback on some things, and they now seem completely uninterested taking the time needed to clean their stuff up and actually get it into the kernel. I wouldn't hold out much hope unless something changes dramatically.
Dan
I think the best approach would be to provide a VE framework in the kernel with an API that both OpenVZ and Linux-vServer (and anybody else) could use. Keep particular implementation details outside in loadable modules.
"GR" == Gerry Reno greno@verizon.net writes:
GR> I think the best approach would be to provide a VE framework in GR> the kernel with an API that both OpenVZ and Linux-vServer (and GR> anybody else) could use. Keep particular implementation details GR> outside in loadable modules.
That is the approach taken, apart from the last line -- OpenVZ and Linux-vserver will end up just being user space tools using a common kernel interface. Rather like racoon and openswan these days, if you don't apply the openswan KLIPS patch. They should not need separate modules.
/Benny