11:24 a.m.
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.
11:35 a.m.
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?
11:34 a.m.
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.
--
Jesse Keating
Release Engineer: Fedora
11:49 a.m.
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
3:12 p.m.
>>>> "JB" == Josh Boyer
<jwboyer(a)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
11:53 a.m.
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.
6:54 a.m.
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
7:50 a.m.
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.
5:46 p.m.
>>>> "GR" == Gerry Reno
<greno(a)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
6139
days inactive
6140
days old
9 comments
5 participants
participants (5)
-
Benny Amorsen -
Dan Williams -
Gerry Reno -
Jesse Keating -
Josh Boyer