Xen status in lenny?

15 views
Skip to first unread message

Lucas Nussbaum

unread,
Jul 10, 2008, 4:20:15 PM7/10/08
to
Hi,

AFAIK, the status of Xen in lenny is currently the following:
- no dom0 kernel
- domU kernel only for i386 (no domU kernel for amd64)

I was told (I don't remember where) that this is because the vanilla
kernel only supports domU for i386, and has no dom0 support, so distros
have to port the patches to their kernels (please correct me if I'm
wrong).

However:
- etch shipped with dom0 and domU kernels on i386 and amd64
- all major distros shipped with "full" Xen support

What are the plans for Xen for lenny? Is this situation likely to change
before the release?
--
| Lucas Nussbaum
| lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Ian Campbell

unread,
Jul 11, 2008, 4:00:12 AM7/11/08
to
On Thu, 2008-07-10 at 21:53 +0200, Lucas Nussbaum wrote:
> Hi,
>
> AFAIK, the status of Xen in lenny is currently the following:
> - no dom0 kernel
> - domU kernel only for i386 (no domU kernel for amd64)
>
> I was told (I don't remember where) that this is because the vanilla
> kernel only supports domU for i386, and has no dom0 support, so distros
> have to port the patches to their kernels (please correct me if I'm
> wrong).

That is correct.

The upstream -tip tree currently has some 64 bit domU patches queued
(probably for 2.6.27). They are rather new and far reaching since they
make some some nice infrastructure cleanups along the way etc. There's a
rather slim chance they might make it in for Lenny but given their young
age I'm not quite happy to say we could support a kernel with them for
the lifetime of Lenny.

dom0 support is being worked on by Fedora people (I think) but there are
no patches upstream yet.

> However:
> - etch shipped with dom0 and domU kernels on i386 and amd64
> - all major distros shipped with "full" Xen support

FWIW fc9 didn't ship with dom0 support -- that is targeted for fc10.
For now I think they recommend you stick with fc8 for dom0.

I think we will be in a similar situation -- recommending sticking with
Etch for dom0 (or at least the Etch kernel, which I run on sid for my
Xen uses just fine) is probably the best we can do at the moment.

> What are the plans for Xen for lenny? Is this situation likely to change
> before the release?

Without a massive injection of manpower (Debian side or upstream) I
don't see much changing. I've heard that maybe a Lenny + 1/2 kernel
might be able to add the features (64bit + dom0) which are missed this
time around if they are available upstream, but that isn't my call to
make.

Ian.
--
Ian Campbell

People usually get what's coming to them ... unless it's been mailed.

Bastian Blank

unread,
Jul 11, 2008, 5:30:08 AM7/11/08
to
On Thu, Jul 10, 2008 at 09:53:25PM +0200, Lucas Nussbaum wrote:
> AFAIK, the status of Xen in lenny is currently the following:
> - no dom0 kernel

Yep. There are some preliminary patches but they break non-paravirt
usage for now.

> - domU kernel only for i386 (no domU kernel for amd64)

x86_64 is currently worked on, but the stuff in fedora 9 is rather
unclean.

> However:
> - etch shipped with dom0 and domU kernels on i386 and amd64

Well, it ships a slightly broken variant.

> - all major distros shipped with "full" Xen support

RHEL5/FC8 are 2.6.18 based and ships full support. SLES10 is 2.6.16 based
and ships full support. FC9 is 2.6.24 based and ships only domU support.
Anything else can be considered more or less broken.

> What are the plans for Xen for lenny? Is this situation likely to change
> before the release?

It will ship the hypervisor and a domU kernel. For dom0 it will need
either the etch or my own[1] kernel. This may be changed later if we can
get a new kernel in the stable release.

Bastian

[1]:
deb http://kernel-archive.buildserver.net/debian-kernel/waldi/xen-extra all main

--
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3

signature.asc

Paul van der Vlis

unread,
Jul 11, 2008, 6:10:05 AM7/11/08
to

Lucas Nussbaum

unread,
Jul 11, 2008, 6:30:19 AM7/11/08
to
Hi,

On 11/07/08 at 11:24 +0200, Bastian Blank wrote:
> > - all major distros shipped with "full" Xen support
>
> RHEL5/FC8 are 2.6.18 based and ships full support. SLES10 is 2.6.16 based
> and ships full support. FC9 is 2.6.24 based and ships only domU support.
> Anything else can be considered more or less broken.

It seems that Ubuntu 8.04 shipped with a 2.6.24 domU. So Ubuntu is
the only distro shipping a dom0 based on Linux >> 2.6.18? How did they
achieve this? :-)

> > What are the plans for Xen for lenny? Is this situation likely to change
> > before the release?
>
> It will ship the hypervisor and a domU kernel. For dom0 it will need
> either the etch or my own[1] kernel. This may be changed later if we can
> get a new kernel in the stable release.

The problem I see with that is that people will be left without a
supported dom0 kernel at some point during the etch lifetime. Do we have
a plan to address that? Shouldn't we make it clear that we will support
the etch kernel until a lenny+1/2 kernel is available, for example?

Also, can you use the Xen 3.2 features with the etch kernel, or are you
somehow limited?

Wouldn't it be a good idea to ship a linux 2.6.18 kernel in lenny, only
for dom0, so it's clear that it is supported?

Thank you,

signature.asc

Bastian Blank

unread,
Jul 11, 2008, 7:00:10 AM7/11/08
to
On Fri, Jul 11, 2008 at 12:18:51PM +0200, Lucas Nussbaum wrote:
> On 11/07/08 at 11:24 +0200, Bastian Blank wrote:
> > Anything else can be considered more or less broken.
> It seems that Ubuntu 8.04 shipped with a 2.6.24 domU. So Ubuntu is
> the only distro shipping a dom0 based on Linux >> 2.6.18? How did they
> achieve this? :-)

FC8 ships a forward ported 2.6.22, Ubuntu 8.04 a forward ported 2.6.24.
They pushed work into it and got something which works more or less
good. The Ubuntu patch never worked for me.

> > It will ship the hypervisor and a domU kernel. For dom0 it will need
> > either the etch or my own[1] kernel. This may be changed later if we can
> > get a new kernel in the stable release.
> The problem I see with that is that people will be left without a
> supported dom0 kernel at some point during the etch lifetime.

Which is at least lenny + 1 year, which gives us some time.

> Do we have
> a plan to address that? Shouldn't we make it clear that we will support
> the etch kernel until a lenny+1/2 kernel is available, for example?

-security is needed for this.

> Also, can you use the Xen 3.2 features with the etch kernel, or are you
> somehow limited?

It does not support power management, but otherwise it works.

> Wouldn't it be a good idea to ship a linux 2.6.18 kernel in lenny, only
> for dom0, so it's clear that it is supported?

This needs redefining of the rule that we don't longer want multiple
kernels in a stable release. But should be possible if -release and
-security don't veto it.

Bastian

--
Where there's no emotion, there's no motive for violence.
-- Spock, "Dagger of the Mind", stardate 2715.1

signature.asc

Lucas Nussbaum

unread,
Jul 11, 2008, 7:10:20 AM7/11/08
to
On 11/07/08 at 12:18 +0200, Lucas Nussbaum wrote:
> Hi,
>
> On 11/07/08 at 11:24 +0200, Bastian Blank wrote:
> > > - all major distros shipped with "full" Xen support
> >
> > RHEL5/FC8 are 2.6.18 based and ships full support. SLES10 is 2.6.16 based
> > and ships full support. FC9 is 2.6.24 based and ships only domU support.
> > Anything else can be considered more or less broken.
>
> It seems that Ubuntu 8.04 shipped with a 2.6.24 domU. So Ubuntu is
^^^^ dom0 (well, they
shipped with a 2.6.24 domU, but my question is about the dom0)

> the only distro shipping a dom0 based on Linux >> 2.6.18? How did they
> achieve this? :-)
signature.asc

Vincent Bernat

unread,
Jul 11, 2008, 4:10:14 PM7/11/08
to
OoO Pendant le temps de midi du vendredi 11 juillet 2008, vers 12:18,
Lucas Nussbaum <lu...@lucas-nussbaum.net> disait :

> The problem I see with that is that people will be left without a
> supported dom0 kernel at some point during the etch lifetime. Do we have
> a plan to address that? Shouldn't we make it clear that we will support
> the etch kernel until a lenny+1/2 kernel is available, for example?

The problem also appears for vserver kernel.
--
printk("VFS: Busy inodes after unmount. "
"Self-destruct in 5 seconds. Have a nice day...\n");
2.3.99-pre8 /usr/src/linux/fs/super.c

Steve Langasek

unread,
Jul 12, 2008, 5:40:12 PM7/12/08
to
On Fri, Jul 11, 2008 at 12:18:51PM +0200, Lucas Nussbaum wrote:
> > > What are the plans for Xen for lenny? Is this situation likely to change
> > > before the release?

> > It will ship the hypervisor and a domU kernel. For dom0 it will need
> > either the etch or my own[1] kernel. This may be changed later if we can
> > get a new kernel in the stable release.

> The problem I see with that is that people will be left without a
> supported dom0 kernel at some point during the etch lifetime. Do we have
> a plan to address that? Shouldn't we make it clear that we will support
> the etch kernel until a lenny+1/2 kernel is available, for example?

Which "we" do you expect will support it? I haven't heard any comments from
the security team indicating that they're willing to provide support for
such a stale kernel beyond the normal support lifetime of etch. If there
should happen not to be a lenny+1/2 kernel, how long would the security team
be expected to provide security support for 2.6.18? Until the release of
lenny+1? Until the end of the *lenny* support cycle?

> Wouldn't it be a good idea to ship a linux 2.6.18 kernel in lenny, only
> for dom0, so it's clear that it is supported?

I think the first question to resolve is to establish that it *is*
supported...

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org

Roberto C. Sánchez

unread,
Jul 12, 2008, 6:10:08 PM7/12/08
to
On Sat, Jul 12, 2008 at 12:03:30PM -0700, Steve Langasek wrote:
> On Fri, Jul 11, 2008 at 12:18:51PM +0200, Lucas Nussbaum wrote:
> > > > What are the plans for Xen for lenny? Is this situation likely to change
> > > > before the release?
>
> > > It will ship the hypervisor and a domU kernel. For dom0 it will need
> > > either the etch or my own[1] kernel. This may be changed later if we can
> > > get a new kernel in the stable release.
>
> > The problem I see with that is that people will be left without a
> > supported dom0 kernel at some point during the etch lifetime. Do we have
> > a plan to address that? Shouldn't we make it clear that we will support
> > the etch kernel until a lenny+1/2 kernel is available, for example?
>
> Which "we" do you expect will support it? I haven't heard any comments from
> the security team indicating that they're willing to provide support for
> such a stale kernel beyond the normal support lifetime of etch. If there
> should happen not to be a lenny+1/2 kernel, how long would the security team
> be expected to provide security support for 2.6.18? Until the release of
> lenny+1? Until the end of the *lenny* support cycle?
>
> > Wouldn't it be a good idea to ship a linux 2.6.18 kernel in lenny, only
> > for dom0, so it's clear that it is supported?
>
> I think the first question to resolve is to establish that it *is*
> supported...
>
I think that the prudent thing for Debian to do is to continue to
support the older kernel if that is the only way to ensure Xen support
for the users. I personally have a few servers running Xen that run
stable. If the support for Xen in a stable release is not suitable, I
would have to consider migrating those servers to some other distro. I
would really hate to have to do that.

Regards,

-Roberto

--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

signature.asc

Lucas Nussbaum

unread,
Jul 12, 2008, 6:20:09 PM7/12/08
to
On 12/07/08 at 12:03 -0700, Steve Langasek wrote:
> On Fri, Jul 11, 2008 at 12:18:51PM +0200, Lucas Nussbaum wrote:
> > > > What are the plans for Xen for lenny? Is this situation likely to change
> > > > before the release?
>
> > > It will ship the hypervisor and a domU kernel. For dom0 it will need
> > > either the etch or my own[1] kernel. This may be changed later if we can
> > > get a new kernel in the stable release.
>
> > The problem I see with that is that people will be left without a
> > supported dom0 kernel at some point during the etch lifetime. Do we have
> > a plan to address that? Shouldn't we make it clear that we will support
> > the etch kernel until a lenny+1/2 kernel is available, for example?
>
> Which "we" do you expect will support it? I haven't heard any comments from
> the security team indicating that they're willing to provide support for
> such a stale kernel beyond the normal support lifetime of etch. If there
> should happen not to be a lenny+1/2 kernel, how long would the security team
> be expected to provide security support for 2.6.18? Until the release of
> lenny+1? Until the end of the *lenny* support cycle?
>
> > Wouldn't it be a good idea to ship a linux 2.6.18 kernel in lenny, only
> > for dom0, so it's clear that it is supported?
>
> I think the first question to resolve is to establish that it *is*
> supported...

If nothing changes, the only choice for users will be to run an etch
dom0 (or an etch dom0 kernel with a lenny userland, but that doesn't
change much). An etch dom0 will only be supported until the end of the
etch support cycle. After that, users will need a supported upgrade
path (and I would prefer it not to be "use Ubuntu").

We (Debian) should make a clear statement that users of Debian as dom0
will have at least one supported configuration at any time during the
lenny lifetime.

Shipping an additional 2.6.18 kernel in lenny is just one extreme
solution. Another solution might work too, like stating that we (Debian)
will support the etch dom0 kernel until a dom0 kernel is available in
lenny (+ an interim period), even if the support cycle for etch ends
before that.


--
| Lucas Nussbaum
| lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |

Gunnar Wolf

unread,
Jul 12, 2008, 7:50:12 PM7/12/08
to
Vincent Bernat dijo [Fri, Jul 11, 2008 at 10:08:09PM +0200]:

> > The problem I see with that is that people will be left without a
> > supported dom0 kernel at some point during the etch lifetime. Do we have
> > a plan to address that? Shouldn't we make it clear that we will support
> > the etch kernel until a lenny+1/2 kernel is available, for example?
>
> The problem also appears for vserver kernel.

It is currently in Sid [1], and it has been for some time already. It
seems it will very soon reach Lenny [2] (In case status changes by the
moment you check it: linux-2.6 is going in today (thanks to manual
hinting by luk) )

Greetings,

[1] http://packages.debian.org/search?keywords=linux-image-2.6.25-2-vserver-amd64

[2] http://release.debian.org/migration/testing.pl?package=linux-2.6

--
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF

Steve Langasek

unread,
Jul 13, 2008, 1:30:13 PM7/13/08
to
On Sat, Jul 12, 2008 at 06:05:14PM -0400, Roberto C. Sánchez wrote:
> > I think the first question to resolve is to establish that it *is*
> > supported...

> I think that the prudent thing for Debian to do is to continue to
> support the older kernel if that is the only way to ensure Xen support
> for the users. I personally have a few servers running Xen that run
> stable. If the support for Xen in a stable release is not suitable, I
> would have to consider migrating those servers to some other distro. I
> would really hate to have to do that.

The distro used on dom0 is pretty uninteresting, given that part of the
point of having Xen-style virtualization for servers is to a) be able to run
different OSes in different guests, and b) not to run services in dom0.[1]

If the Debian security team is unwilling or unable to provide support for a
2.6.18 kernel over the lifetime of lenny, I'm happy to see us let dom0 be
Somebody Else's Problem. I'm certainly happier with that than having us
/claim/ to support 2.6.18, have users rely on that claim, and then not be
able to deliver.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org

[1] I can sympathize with users who want to run Xen on systems for
virtualization purposes while also being able to run a full desktop
environment in dom0 where hardware is more accessible; but I think this is
probably a fairly small group of people still given the hardware
requirements, and in any case I don't think that's a use case that should
compel us to overextend ourselves.

Steve Langasek

unread,
Jul 13, 2008, 1:30:10 PM7/13/08
to
On Sun, Jul 13, 2008 at 12:10:28AM +0200, Lucas Nussbaum wrote:
> > > The problem I see with that is that people will be left without a
> > > supported dom0 kernel at some point during the etch lifetime. Do we have
> > > a plan to address that? Shouldn't we make it clear that we will support
> > > the etch kernel until a lenny+1/2 kernel is available, for example?

> > Which "we" do you expect will support it? I haven't heard any comments from
> > the security team indicating that they're willing to provide support for
> > such a stale kernel beyond the normal support lifetime of etch. If there
> > should happen not to be a lenny+1/2 kernel, how long would the security team
> > be expected to provide security support for 2.6.18? Until the release of
> > lenny+1? Until the end of the *lenny* support cycle?

> > > Wouldn't it be a good idea to ship a linux 2.6.18 kernel in lenny, only
> > > for dom0, so it's clear that it is supported?

> > I think the first question to resolve is to establish that it *is*
> > supported...

> If nothing changes, the only choice for users will be to run an etch
> dom0 (or an etch dom0 kernel with a lenny userland, but that doesn't
> change much). An etch dom0 will only be supported until the end of the
> etch support cycle. After that, users will need a supported upgrade
> path (and I would prefer it not to be "use Ubuntu").

I would note that, although built as part of the main 'linux' source package
in Ubuntu, the Xen kernel images are in Ubuntu universe - which means any
Xen-specific code is effectively not guaranteed to be covered by Canonical's
security support anyway. So you might want to take a closer look at the
security status of this, before deciding that Ubuntu is the right choice for
a security-supported dom0 kernel (or before goading Debian folks into
overcommitting themselves to Xen support in lenny using Ubuntu as a bogeyman
;).

(N.B., I'm not speaking on behalf of the Ubuntu Xen folks; they may indeed
have made arrangements with the security team to provide security coverage
for the Xen kernels - I'm just saying not to assume it's a given.)

> We (Debian) should make a clear statement that users of Debian as dom0
> will have at least one supported configuration at any time during the
> lenny lifetime.

What I don't see you saying is that *you* are volunteering to step up and
help provide security support for this kernel. So it's "we" when we're
making a statement, but it's still "they" who would have to provide the
actual support, AFAICS.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org

Roberto C. Sánchez

unread,
Jul 13, 2008, 3:10:13 PM7/13/08
to
On Sat, Jul 12, 2008 at 06:01:30PM -0700, Steve Langasek wrote:
> On Sat, Jul 12, 2008 at 06:05:14PM -0400, Roberto C. Sánchez wrote:
> > > I think the first question to resolve is to establish that it *is*
> > > supported...
>
> > I think that the prudent thing for Debian to do is to continue to
> > support the older kernel if that is the only way to ensure Xen support
> > for the users. I personally have a few servers running Xen that run
> > stable. If the support for Xen in a stable release is not suitable, I
> > would have to consider migrating those servers to some other distro. I
> > would really hate to have to do that.
>
> The distro used on dom0 is pretty uninteresting, given that part of the
> point of having Xen-style virtualization for servers is to a) be able to run
> different OSes in different guests, and b) not to run services in dom0.[1]
>
> If the Debian security team is unwilling or unable to provide support for a
> 2.6.18 kernel over the lifetime of lenny, I'm happy to see us let dom0 be
> Somebody Else's Problem. I'm certainly happier with that than having us
> /claim/ to support 2.6.18, have users rely on that claim, and then not be
> able to deliver.
>
While agree that from a technical standpoint, that distro is rather
uninteresting, I don't want to have increase the complexity of the
networks I administer by bringing yet another distro into the mix.
signature.asc

Guido Trotter

unread,
Jul 13, 2008, 3:40:15 PM7/13/08
to
On Sat, Jul 12, 2008 at 06:01:30PM -0700, Steve Langasek wrote:

Hi,

> The distro used on dom0 is pretty uninteresting, given that part of the
> point of having Xen-style virtualization for servers is to a) be able to run
> different OSes in different guests, and b) not to run services in dom0.[1]
>

Agreed, we shouldn't support arbitrary dom0s, but it would be nice to have one
supported way to run dom0 in debian, be it etch or lenny... If we say "run dom0
in etch" at least can we have the limited etch needed for a dom0 to work blessed
with an extended support, if not support 2.6.18 in lenny?

Thanks,

Guido

Loïc Minier

unread,
Jul 14, 2008, 8:20:28 AM7/14/08
to
On Sat, Jul 12, 2008, Steve Langasek wrote:
> The distro used on dom0 is pretty uninteresting, given that part of the
> point of having Xen-style virtualization for servers is to a) be able to run
> different OSes in different guests, and b) not to run services in dom0.[1]

A recent kernel to support new expensive hardware which you just bought
for virtualization might be useful though. (However, I agree that
copying over an old kernel to use new a distro userland's with an old
kernel for a dom0 doesn't seem too useful.)

--
Loïc Minier

Paul van der Vlis

unread,
Jul 14, 2008, 9:00:24 AM7/14/08
to
Steve Langasek schreef:

> If the Debian security team is unwilling or unable to provide support for a
> 2.6.18 kernel over the lifetime of lenny, I'm happy to see us let dom0 be
> Somebody Else's Problem. I'm certainly happier with that than having us
> /claim/ to support 2.6.18, have users rely on that claim, and then not be
> able to deliver.

Maybe we can stop with etch-and-a-half. For the security-team is
supporting the etch-and-a-half kernel (2.6.24) a lot more work then
supporting the etch-kernel.

I think "etch-and-a-half" is a good idea, but the team is very late with
it. Too late when Lenny is in time, in my opinion.

With regards,
Paul van der Vlis.


--
http://www.vandervlis.nl/


Luk Claes

unread,
Jul 14, 2008, 1:40:10 PM7/14/08
to
Paul van der Vlis wrote:
> Steve Langasek schreef:
>
>> If the Debian security team is unwilling or unable to provide support for a
>> 2.6.18 kernel over the lifetime of lenny, I'm happy to see us let dom0 be
>> Somebody Else's Problem. I'm certainly happier with that than having us
>> /claim/ to support 2.6.18, have users rely on that claim, and then not be
>> able to deliver.
>
> Maybe we can stop with etch-and-a-half. For the security-team is
> supporting the etch-and-a-half kernel (2.6.24) a lot more work then
> supporting the etch-kernel.
>
> I think "etch-and-a-half" is a good idea, but the team is very late with
> it. Too late when Lenny is in time, in my opinion.

If we abandon it now, all trouble we went through didn't serve anything
and if we want to try it again, we kind of have to start over again. I
don't think we should stop it, rather make it happen soon.

Cheers

Luk

Gunnar Wolf

unread,
Jul 14, 2008, 1:50:13 PM7/14/08
to
Paul van der Vlis dijo [Mon, Jul 14, 2008 at 02:41:20PM +0200]:

> Maybe we can stop with etch-and-a-half. For the security-team is
> supporting the etch-and-a-half kernel (2.6.24) a lot more work then
> supporting the etch-kernel.
>
> I think "etch-and-a-half" is a good idea, but the team is very late with
> it. Too late when Lenny is in time, in my opinion.

Keep in mind that Etch will be supported after one year after Lenny is
shipped. This means, there is still a large window for users to get
benefits from Etch-and-a-half. And as for Lenny-and-a-half, we might
even get back Xen dom0 support :)

--
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF

Goswin von Brederlow

unread,
Jul 15, 2008, 5:50:12 AM7/15/08
to
Bastian Blank <wa...@debian.org> writes:

> On Thu, Jul 10, 2008 at 09:53:25PM +0200, Lucas Nussbaum wrote:
>> What are the plans for Xen for lenny? Is this situation likely to change
>> before the release?
>
> It will ship the hypervisor and a domU kernel. For dom0 it will need
> either the etch or my own[1] kernel. This may be changed later if we can
> get a new kernel in the stable release.
>
> Bastian
>
> [1]:
> deb http://kernel-archive.buildserver.net/debian-kernel/waldi/xen-extra all main

Could I suggest adding a linux-2.6.18 package to lenny that builds a
dom0 kernel?

Otherwise lenny XEN support would be limited to the lifetime of
old-stable unless a point release adds a xen dom0 kernel image later
on.

MfG
Goswin

Lucas Nussbaum

unread,
Jul 15, 2008, 7:20:11 AM7/15/08
to
On 12/07/08 at 19:39 -0700, Steve Langasek wrote:
> On Sun, Jul 13, 2008 at 12:10:28AM +0200, Lucas Nussbaum wrote:
> > We (Debian) should make a clear statement that users of Debian as dom0
> > will have at least one supported configuration at any time during the
> > lenny lifetime.
>
> What I don't see you saying is that *you* are volunteering to step up and
> help provide security support for this kernel. So it's "we" when we're
> making a statement, but it's still "they" who would have to provide the
> actual support, AFAICS.

How/if we will support Xen in lenny is more a policy decision than a
technical decision, even if it has important technical aspects.

Even if it's not optimal, I agree with do-ocracy for technical
decisions. However, using it for everything is dangerous. Instead, I
prefer to:
1/ understand the situation
2/ determine the possible solutions
3/ determine the best solutions, given external constraints (inc.
manpower)
4/ try to find someone to do the work

Throwing "you are not going to do the work anyway, so you are
irrelevant" at everybody is not helpful at all, and just adds noise to
the discussion, because we are still between stages 2 and 3 here.


--
| Lucas Nussbaum
| lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |

Thijs Kinkhorst

unread,
Jul 15, 2008, 8:10:16 AM7/15/08
to
On Tuesday 15 July 2008 13:08, Lucas Nussbaum wrote:
> How/if we will support Xen in lenny is more a policy decision than a
> technical decision, even if it has important technical aspects.
>
> Even if it's not optimal, I agree with do-ocracy for technical
> decisions. However, using it for everything is dangerous. Instead, I
> prefer to:
> 1/ understand the situation
> 2/ determine the possible solutions
> 3/ determine the best solutions, given external constraints (inc.
> manpower)
> 4/ try to find someone to do the work
>
> Throwing "you are not going to do the work anyway, so you are
> irrelevant" at everybody is not helpful at all, and just adds noise to
> the discussion, because we are still between stages 2 and 3 here.

I find it a pity that your mail doesn't contain any argumentation for your
postulations. For a start, I don't think it's obvious that this is a policy
decision, nor that a "do-ocracy is dangerous" in a general sense.

Xen is just one solution to virtualisation. I may agree that a general
decision to support virtualisation on Debian could be a policy decision, but
whether we'll support one specific technology, for which there are many
alternatives, is very much a technical decision. Does it work, can we get it
to work and do we have the people to keep it work after release?


Thijs

Lucas Nussbaum

unread,
Jul 15, 2008, 9:00:19 AM7/15/08
to
On 15/07/08 at 14:01 +0200, Thijs Kinkhorst wrote:
> Xen is just one solution to virtualisation. I may agree that a general
> decision to support virtualisation on Debian could be a policy decision, but
> whether we'll support one specific technology, for which there are many
> alternatives, is very much a technical decision. Does it work, can we get it
> to work and do we have the people to keep it work after release?

Debian supported Xen in etch. Which of the "many alternatives" should
Debian recommend to its users currently running a Debian dom0 in
paravirt mode?

I don't think that any of the alternatives are valid candidates yet:
- Linux-Vserver, OpenVZ: clearly not the same use case.
- Virtualbox, qemu: poor performance under some workloads.
- KVM: is very promising but is it really a valid alternative *now*
for current Xen users?

This might change in a few months, of course, but in a few months lenny
will be released. ;-)

Pasi Kärkkäinen

unread,
Jul 15, 2008, 9:30:16 AM7/15/08
to
On Tue, Jul 15, 2008 at 01:08:23PM +0200, Lucas Nussbaum wrote:
> On 12/07/08 at 19:39 -0700, Steve Langasek wrote:
> > On Sun, Jul 13, 2008 at 12:10:28AM +0200, Lucas Nussbaum wrote:
> > > We (Debian) should make a clear statement that users of Debian as dom0
> > > will have at least one supported configuration at any time during the
> > > lenny lifetime.
> >
> > What I don't see you saying is that *you* are volunteering to step up and
> > help provide security support for this kernel. So it's "we" when we're
> > making a statement, but it's still "they" who would have to provide the
> > actual support, AFAICS.
>
> How/if we will support Xen in lenny is more a policy decision than a
> technical decision, even if it has important technical aspects.
>
> Even if it's not optimal, I agree with do-ocracy for technical
> decisions. However, using it for everything is dangerous. Instead, I
> prefer to:
> 1/ understand the situation
> 2/ determine the possible solutions
> 3/ determine the best solutions, given external constraints (inc.
> manpower)
> 4/ try to find someone to do the work
>
> Throwing "you are not going to do the work anyway, so you are
> irrelevant" at everybody is not helpful at all, and just adds noise to
> the discussion, because we are still between stages 2 and 3 here.

The situation is pretty much like this:

- Upstream vendor (Xensource) only develops 2.6.18 Xen dom0/domU kernel atm.

- paravirt_ops (pv_ops) Xen support in vanilla (v2.6.24+) Linux kernels is currently
domU only. Also it's 32bit PAE only, no 64bit yet. Other features are
missing too (compared to xensource 2.6.18 xen kernel).

- Xen kernel features from 2.6.18 are being ported and added slowly to 2.6.2x
pv_ops kernels but it takes time and effort to get them ported and accepted
upstream (by linus). Currently Jeremy Fitzhardinge (from Xensource) is doing
this work. I think currently he's working on getting 64bit domU support ready/integrated.

- Redhat/Fedora has done some pv_ops xen dom0 support work, but it's not
ready yet and it hasn't had much progress lately.. unfortunately.

- 2.6.22 and 2.6.24 (non pv_ops) kernels with forward ported patches from 2.6.18
are a real pain for kernel maintainers..

- Fedora decided to drop dom0 xen kernel for Fedora 9. Fedora 9 only ships
with xen pv_ops domU kernel. They're planning to add dom0 support back for
Fedora 10 if/when (pv_ops) dom0 support is included in the upstream
vanilla (linus) kernel.

Some links:

http://wiki.xensource.com/xenwiki/XenParavirtOps
http://fedoraproject.org/wiki/Features/XenPvopsDom0

-- Pasi

Bastian Blank

unread,
Jul 15, 2008, 10:10:10 AM7/15/08
to
On Thu, Jul 10, 2008 at 09:53:25PM +0200, Lucas Nussbaum wrote:
> What are the plans for Xen for lenny? Is this situation likely to change
> before the release?

As we have seen, there is no real plan. So lets summarize the
possibilities:

Option 1: Use alternatives
==========================
Well, I don't know any real alternative.

There are some other virtualization techniques, but the decision which
one may be usable needs an evaluation of the actual usecase.

Option 2: Stick to Etch
=======================
Ask the users to stick to Etch until we can get a kernel into Lenny
which supports this type of operation.

Contra:
- No new software for Xen users.
- May hit the end of the security support for Etch.
Needed work: Documentation.

Option 3: Lenny with Etch kernel
================================
Ask the users to use the old Etch kernel with a Lenny userland.

Pro:
- New software.
Contra:
- May hit the end of the security support for Etch.
Needed work: Some documentation how to do this.

Option 4: 2.6.18 kernel in Lenny, until Lenny+1/2
=================================================
Push a (Xen-only) 2.6.18 kernel into Lenny. Either with the Etch or
preferably a newer Xen patch. This kernel will be supported until
Lenny+1/2 hopefully pushs a kernel with the necessary support into the
stable release, but at most until the Lenny+1 release. It may be
possible that this will also need a Xen update to work with the new
kernels.

Pro:
- New software.
- Full support for the beginning.
Contra:
- We have to overwrite the decision to support only one Linux kernel in
a stable release.
- Dropping support of a package during the lifetime of a stable release
was always a last resort solution. So this needs a fat warning in the
release notes.[1]
Needed work for kernel/security team[2]:
- Until end of Etch support: Push the same update in oldstable-security
and stable-security.
- After end of Etch support: Continue the support for this old kernel.
Lets hope that this will not take too long.
Needed work for other teams: Documentation.

Option 5: 2.6.18 kernel in Lenny
================================
Push a (Xen-only) 2.6.18 kernel into Lenny. Either with the Etch or
preferably a newer Xen patch. This kernel will be supported until the
normal end of the normal support.

Pro:
- New software.
- Full support.
Contra:
- We have to overwrite the decision to support only one Linux kernel in
a stable release.
Needed work for kernel/security team:
- Until end of Etch support: Push the same update in oldstable-security
and stable-security.
- After end of Etch support: Continue the support for this old kernel.

For further, not applicable options, see
http://fedoraproject.org/wiki/Features/XenPvops.

Conclusion
==========
Xen got a often used technique in the last two years. All of the large
distributions got some sort of support for it. Debian Etch have full
support for it. There was several requests of various people so I think
not providing at least a minimal support in Lenny is wrong.

I think option 4 would be the solution which produces the least amount
of extra work and provides our users with support for there systems. I
would provide the necessary packages but I want an okay for that
solution from the security and the release team.

Bastian, with his kernel and Xen hat on

[1]: Maybe it would be possible to replace the not-longer supported
packages with a critical warning in preinst. This package would never
allow themself to be configured.
[2]: Kernel security support is mostly done by Dann Frazier, who does it
as member of the kernel team.
--
Is truth not truth for all?
-- Natira, "For the World is Hollow and I have Touched
the Sky", stardate 5476.4.

signature.asc

John Goerzen

unread,
Jul 15, 2008, 10:30:18 AM7/15/08
to
Lucas Nussbaum wrote:
> On 15/07/08 at 14:01 +0200, Thijs Kinkhorst wrote:
> - KVM: is very promising but is it really a valid alternative *now*
> for current Xen users?

That is an interesting question. We are doing some research on that
topic right now. I've migrated some VMware and xen stuff on my own
workstation to KVM, with highly encouraging results. That is, of
course, different than a server situation, but a data point nonetheless.

We have been happy with Xen in principle, but there have been enough
strange things happen over the past year or two that we're not entirely
comfortable with it anymore. These things include the hypervisor
crashing on creation or removal of a domU, strange kernel oops in domUs,
and severe brokenness of pciback.

It should be noted that KVM does not include PCI backend support, though
with the degree of brokenness of it in Xen, that may not be an issue.
Also, KVM requires hardware virtualization support, which Xen does not.
So it is not entirely a drop-in replacement.

The fact that Xensource is supporting 2.6.18 only, and that work on KVM
is integrated into the kernel upstream, is a strong argument to us for
converting to KVM. Unless something changes drastically with Xen's
kernel support, I can't see us doing anything but KVM long term.

-- John

Pasi Kärkkäinen

unread,
Jul 15, 2008, 10:50:17 AM7/15/08
to
On Tue, Jul 15, 2008 at 02:54:09PM +0200, Lucas Nussbaum wrote:
> On 15/07/08 at 14:01 +0200, Thijs Kinkhorst wrote:
> > Xen is just one solution to virtualisation. I may agree that a general
> > decision to support virtualisation on Debian could be a policy decision, but
> > whether we'll support one specific technology, for which there are many
> > alternatives, is very much a technical decision. Does it work, can we get it
> > to work and do we have the people to keep it work after release?
>
> Debian supported Xen in etch. Which of the "many alternatives" should
> Debian recommend to its users currently running a Debian dom0 in
> paravirt mode?
>
> I don't think that any of the alternatives are valid candidates yet:
> - Linux-Vserver, OpenVZ: clearly not the same use case.
> - Virtualbox, qemu: poor performance under some workloads.
> - KVM: is very promising but is it really a valid alternative *now*
> for current Xen users?
>

One big difference between Xen and KVM is the fact that KVM always requires
hardware virtualization (HVM) support from the CPU.

Xen doesn't need that for paravirt guests (linux).

Xen still is the most feature rich hypervisor.. that might change some day,
of course.

The biggest advantage of KVM is that it's included in vanilla kernel..

Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
important Xen kernel features ported to pv_ops framework and integrated
into vanilla linus kernels soon..

Status/todo:
http://wiki.xensource.com/xenwiki/XenParavirtOps

Redhat/Fedora pv_ops Xen kernel dom0 support status:
http://fedoraproject.org/wiki/Features/XenPvopsDom0

-- Pasi

Bastian Blank

unread,
Jul 15, 2008, 11:10:18 AM7/15/08
to
On Tue, Jul 15, 2008 at 05:22:55PM +0300, Pasi Kärkkäinen wrote:
> One big difference between Xen and KVM is the fact that KVM always requires
> hardware virtualization (HVM) support from the CPU.

It uses the the qemu device emulation code, which is security wise one
large catastrophe. Okay, Xen uses it also for full virtualized guests,
which is the reason why I currently discurage anyone from using it.
However this will change in the near future.

> The biggest advantage of KVM is that it's included in vanilla kernel..

Sure. This is the confession that small patchsets are much more likely
to be accepted than large ones. Xen started long time ago and they drag
a huge patch through the last years without the perspective to get
anything in without much rework.

> Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
> important Xen kernel features ported to pv_ops framework and integrated
> into vanilla linus kernels soon..

Yep.

Bastian

--
Witch! Witch! They'll burn ya!
-- Hag, "Tomorrow is Yesterday", stardate unknown

signature.asc

Pasi Kärkkäinen

unread,
Jul 15, 2008, 1:10:19 PM7/15/08
to
On Tue, Jul 15, 2008 at 09:24:08AM -0500, John Goerzen wrote:
> Lucas Nussbaum wrote:
> > On 15/07/08 at 14:01 +0200, Thijs Kinkhorst wrote:
> > - KVM: is very promising but is it really a valid alternative *now*
> > for current Xen users?
>
> That is an interesting question. We are doing some research on that
> topic right now. I've migrated some VMware and xen stuff on my own
> workstation to KVM, with highly encouraging results. That is, of
> course, different than a server situation, but a data point nonetheless.
>
> We have been happy with Xen in principle, but there have been enough
> strange things happen over the past year or two that we're not entirely
> comfortable with it anymore. These things include the hypervisor
> crashing on creation or removal of a domU, strange kernel oops in domUs,
> and severe brokenness of pciback.
>
> It should be noted that KVM does not include PCI backend support, though
> with the degree of brokenness of it in Xen, that may not be an issue.
> Also, KVM requires hardware virtualization support, which Xen does not.
> So it is not entirely a drop-in replacement.
>
> The fact that Xensource is supporting 2.6.18 only, and that work on KVM
> is integrated into the kernel upstream, is a strong argument to us for
> converting to KVM. Unless something changes drastically with Xen's
> kernel support, I can't see us doing anything but KVM long term.
>

Xensource has a developer working on getting xen patches ported to Linux
pv_ops framework and integrated into upstream (vanilla) kernel.

Vanilla Linux v2.6.26 already contains 32bit (PAE) paravirtual domU support
with SMP, framebuffer, memory ballooning (contraction only) etc..

More features are being currently prepared for 2.6.27.. including 64bit domU
support, save/restore/migration etc..

Atm biggest (most important) missing feature from vanilla kernel is dom0 support..

See: http://wiki.xensource.com/xenwiki/XenParavirtOps

So in short the situation is getting better slowly..

At the moment "full" Xen feature set is only available in xensource 2.6.18
kernel.

-- Pasi

John Goerzen

unread,
Jul 15, 2008, 2:10:12 PM7/15/08
to
Pasi Kärkkäinen wrote:
> On Tue, Jul 15, 2008 at 09:24:08AM -0500, John Goerzen wrote:

>
> Xensource has a developer working on getting xen patches ported to Linux
> pv_ops framework and integrated into upstream (vanilla) kernel.

That is, to me, only mildly encouraging. 2.6.18 came out on Sept. 19,
2006, and there haven't been official Xen patches on anything else
since. I don't know if that programmer hasn't been able to be very
productive, or if Xensource has just recently assigned someone to the
task. But in any case, it does not speak well of the long-term
viability of Xen.

Not only that, but I like the KVM model of Linux as the hypervisor. Xen
hypervisor is kinda finicky about hardware; I've had it refuse to boot
properly on Athlon64 machines for instance.

-- John

Pasi Kärkkäinen

unread,
Jul 15, 2008, 3:30:27 PM7/15/08
to
On Tue, Jul 15, 2008 at 12:49:07PM -0500, John Goerzen wrote:
> Pasi Kärkkäinen wrote:
> > On Tue, Jul 15, 2008 at 09:24:08AM -0500, John Goerzen wrote:
>
> >
> > Xensource has a developer working on getting xen patches ported to Linux
> > pv_ops framework and integrated into upstream (vanilla) kernel.
>
> That is, to me, only mildly encouraging. 2.6.18 came out on Sept. 19,
> 2006, and there haven't been official Xen patches on anything else
> since. I don't know if that programmer hasn't been able to be very
> productive, or if Xensource has just recently assigned someone to the
> task. But in any case, it does not speak well of the long-term
> viability of Xen.
>

Xensource is using 2.6.18 (RHEL5) in their own commercial product, so that's
why they're focusing xen kernel development on that version..

Xensource tried getting xen patches integrated into upstream linux earlier,
but it didn't succeed (too big changes?) and kernel developers decided
they need to create this common "pv_ops" framework for running paravirtual
linux on hypervisors..

So that has taken some time.. and only recently (some) xen features have been ported to
this pv_ops framework and integrated into vanilla kernel.. more features are being ported.

So yeah.. atm the xen/dom0 kernel situation is a bit shitty..

pv_ops (VMI) paravirtual linux kernels are also supported by VMware.

-- Pasi

Goswin von Brederlow

unread,
Jul 15, 2008, 5:20:21 PM7/15/08
to
Lucas Nussbaum <lu...@lucas-nussbaum.net> writes:

> On 15/07/08 at 14:01 +0200, Thijs Kinkhorst wrote:
>> Xen is just one solution to virtualisation. I may agree that a general
>> decision to support virtualisation on Debian could be a policy decision, but
>> whether we'll support one specific technology, for which there are many
>> alternatives, is very much a technical decision. Does it work, can we get it
>> to work and do we have the people to keep it work after release?
>
> Debian supported Xen in etch. Which of the "many alternatives" should
> Debian recommend to its users currently running a Debian dom0 in
> paravirt mode?

Isn't the policy decision in question here to only have one kernel
source in a release?

> I don't think that any of the alternatives are valid candidates yet:
> - Linux-Vserver, OpenVZ: clearly not the same use case.
> - Virtualbox, qemu: poor performance under some workloads.

Unusable for production work. Emulation is just too slow. The group of
people that can live with that much slow down compared to xen is
miniscule.

> - KVM: is very promising but is it really a valid alternative *now*
> for current Xen users?

KVM needs hardware support and even then its I/O is slower. It also
deadlocks the I/O under I/O load from time to time.

I could live with the I/O slowdown but nothing will make hardware
magically appear.

> This might change in a few months, of course, but in a few months lenny
> will be released. ;-)


MfG
Goswin

Ben Hutchings

unread,
Jul 15, 2008, 9:00:14 PM7/15/08
to
On Tue, Jul 15, 2008 at 05:22:55PM +0300, Pasi Kärkkäinen wrote:
<snip>

> Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
> important Xen kernel features ported to pv_ops framework and integrated
> into vanilla linus kernels soon..
>
> Status/todo:
> http://wiki.xensource.com/xenwiki/XenParavirtOps
>
> Redhat/Fedora pv_ops Xen kernel dom0 support status:
> http://fedoraproject.org/wiki/Features/XenPvopsDom0

SLES 11 will include Linux 2.6.26 with Xen patches - packages should be
available any day now from
<ftp://ftp.suse.com/pub/projects/kernel/kotd/SL110_BRANCH/i386/>. Is it
possible that those patches will be usable in lenny, as I believe the
kernel team expects to release with Linux 2.6.26?

Ben.

--
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth

signature.asc

William Pitcock

unread,
Jul 16, 2008, 4:40:13 AM7/16/08
to
On Wed, 2008-07-16 at 11:12 +0300, Pasi Kärkkäinen wrote:

> On Wed, Jul 16, 2008 at 01:54:50AM +0100, Ben Hutchings wrote:
> > On Tue, Jul 15, 2008 at 05:22:55PM +0300, Pasi Kärkkäinen wrote:
> > <snip>
> > > Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
> > > important Xen kernel features ported to pv_ops framework and integrated
> > > into vanilla linus kernels soon..
> > >
> > > Status/todo:
> > > http://wiki.xensource.com/xenwiki/XenParavirtOps
> > >
>
> This xensource wiki page was just updated to contain up-to-date status,
> ie. features present in 2.6.26 and features submitted for 2.6.27.

>
>
> > > Redhat/Fedora pv_ops Xen kernel dom0 support status:
> > > http://fedoraproject.org/wiki/Features/XenPvopsDom0
> >
> > SLES 11 will include Linux 2.6.26 with Xen patches - packages should be
> > available any day now from
> > <ftp://ftp.suse.com/pub/projects/kernel/kotd/SL110_BRANCH/i386/>. Is it
> > possible that those patches will be usable in lenny, as I believe the
> > kernel team expects to release with Linux 2.6.26?
> >
>
> Interesting.. do you know if they have dom0 support etc included? based on
> pv_ops?

They include dom0 and are not based on paravirt_ops AFAIK.

William

signature.asc

Pasi Kärkkäinen

unread,
Jul 16, 2008, 4:40:17 AM7/16/08
to
On Wed, Jul 16, 2008 at 01:54:50AM +0100, Ben Hutchings wrote:
> On Tue, Jul 15, 2008 at 05:22:55PM +0300, Pasi Kärkkäinen wrote:
> <snip>
> > Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
> > important Xen kernel features ported to pv_ops framework and integrated
> > into vanilla linus kernels soon..
> >
> > Status/todo:
> > http://wiki.xensource.com/xenwiki/XenParavirtOps
> >

This xensource wiki page was just updated to contain up-to-date status,


ie. features present in 2.6.26 and features submitted for 2.6.27.

> > Redhat/Fedora pv_ops Xen kernel dom0 support status:
> > http://fedoraproject.org/wiki/Features/XenPvopsDom0
>
> SLES 11 will include Linux 2.6.26 with Xen patches - packages should be
> available any day now from
> <ftp://ftp.suse.com/pub/projects/kernel/kotd/SL110_BRANCH/i386/>. Is it
> possible that those patches will be usable in lenny, as I believe the
> kernel team expects to release with Linux 2.6.26?
>

Interesting.. do you know if they have dom0 support etc included? based on
pv_ops?

-- Pasi

William Pitcock

unread,
Jul 16, 2008, 5:00:13 AM7/16/08
to
Hi,

On Wed, 2008-07-16 at 11:42 +0300, Pasi Kärkkäinen wrote:
>
> I guess it was faster _now_, but they'll have to live with the forward
> porting pain for years more now..

While this is true, the patches still allow for Debian to ship Lenny
without a feature regression in Xen support.

William

signature.asc

Bernd Zeimetz

unread,
Jul 16, 2008, 5:00:13 AM7/16/08
to
Gunnar Wolf wrote:
>> The problem also appears for vserver kernel.
>
> It is currently in Sid [1], and it has been for some time already. It
> seems it will very soon reach Lenny [2] (In case status changes by the
> moment you check it: linux-2.6 is going in today (thanks to manual
> hinting by luk) )
>
> Greetings,
>
> [1] http://packages.debian.org/search?keywords=linux-image-2.6.25-2-vserver-amd64

Where does this patch come from? I can't find anything about it on
http://linux-vserver.org

--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79

Pasi Kärkkäinen

unread,
Jul 16, 2008, 5:10:09 AM7/16/08
to

Well that's true..

Pasi Kärkkäinen

unread,
Jul 16, 2008, 5:10:13 AM7/16/08
to

Argh.. even more forward porting from xensource 2.6.18 tree instead of
porting to pv_ops and getting the pathes integrated upstream to vanilla
kernel :(

I guess it was faster _now_, but they'll have to live with the forward
porting pain for years more now..

-- Pasi

maximilian attems

unread,
Jul 16, 2008, 5:10:18 AM7/16/08
to
On Wed, 16 Jul 2008, Ben Hutchings wrote:

> On Tue, Jul 15, 2008 at 05:22:55PM +0300, Pasi Kärkkäinen wrote:
> <snip>
> > Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
> > important Xen kernel features ported to pv_ops framework and integrated
> > into vanilla linus kernels soon..
> >
> > Status/todo:
> > http://wiki.xensource.com/xenwiki/XenParavirtOps
> >
> > Redhat/Fedora pv_ops Xen kernel dom0 support status:
> > http://fedoraproject.org/wiki/Features/XenPvopsDom0
>
> SLES 11 will include Linux 2.6.26 with Xen patches - packages should be
> available any day now from
> <ftp://ftp.suse.com/pub/projects/kernel/kotd/SL110_BRANCH/i386/>. Is it
> possible that those patches will be usable in lenny, as I believe the
> kernel team expects to release with Linux 2.6.26?

dom0 looks currently out of reach,
what we have is the snapshotting features of 2.6.27 for x86_32.

see relevant posts of Ian Campbell on d-kernel


--
maks

Pasi Kärkkäinen

unread,
Jul 16, 2008, 6:20:17 AM7/16/08
to
On Wed, Jul 16, 2008 at 10:50:22AM +0200, maximilian attems wrote:
> On Wed, 16 Jul 2008, Ben Hutchings wrote:
>
> > On Tue, Jul 15, 2008 at 05:22:55PM +0300, Pasi Kärkkäinen wrote:
> > <snip>
> > > Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
> > > important Xen kernel features ported to pv_ops framework and integrated
> > > into vanilla linus kernels soon..
> > >
> > > Status/todo:
> > > http://wiki.xensource.com/xenwiki/XenParavirtOps
> > >
> > > Redhat/Fedora pv_ops Xen kernel dom0 support status:
> > > http://fedoraproject.org/wiki/Features/XenPvopsDom0
> >
> > SLES 11 will include Linux 2.6.26 with Xen patches - packages should be
> > available any day now from
> > <ftp://ftp.suse.com/pub/projects/kernel/kotd/SL110_BRANCH/i386/>. Is it
> > possible that those patches will be usable in lenny, as I believe the
> > kernel team expects to release with Linux 2.6.26?
>
> dom0 looks currently out of reach,
> what we have is the snapshotting features of 2.6.27 for x86_32.
>

Hmm.. what do you mean with "out of reach" ? pv_ops dom0 is not yet
ready/working, but those SLES 11 patches have the xensource (2.6.18 forward
port) of dom0 and all the other xen kernel features for 2.6.26..

> see relevant posts of Ian Campbell on d-kernel
>

You mean this?: http://lists.debian.org/debian-kernel/2008/07/msg00070.html

I think the situation has changed after that..

See: http://wiki.xensource.com/xenwiki/XenParavirtOps

I think x86-64 xen patches are going in for 2.6.27..

http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=summary

"9 hours ago Ingo Molnar Merge branch 'xen-64bit'"

-- Pasi

maximilian attems

unread,
Jul 16, 2008, 7:00:24 AM7/16/08
to
On Wed, Jul 16, 2008 at 12:51:21PM +0300, Pasi Kärkkäinen wrote:
> On Wed, Jul 16, 2008 at 10:50:22AM +0200, maximilian attems wrote:
> > On Wed, 16 Jul 2008, Ben Hutchings wrote:
> >
> > > On Tue, Jul 15, 2008 at 05:22:55PM +0300, Pasi Kärkkäinen wrote:
> > > <snip>
> > > > Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
> > > > important Xen kernel features ported to pv_ops framework and integrated
> > > > into vanilla linus kernels soon..
> > > >
> > > > Status/todo:
> > > > http://wiki.xensource.com/xenwiki/XenParavirtOps
> > > >
> > > > Redhat/Fedora pv_ops Xen kernel dom0 support status:
> > > > http://fedoraproject.org/wiki/Features/XenPvopsDom0
> > >
> > > SLES 11 will include Linux 2.6.26 with Xen patches - packages should be
> > > available any day now from
> > > <ftp://ftp.suse.com/pub/projects/kernel/kotd/SL110_BRANCH/i386/>. Is it
> > > possible that those patches will be usable in lenny, as I believe the
> > > kernel team expects to release with Linux 2.6.26?
> >
> > dom0 looks currently out of reach,
> > what we have is the snapshotting features of 2.6.27 for x86_32.
> >
>
> Hmm.. what do you mean with "out of reach" ? pv_ops dom0 is not yet
> ready/working, but those SLES 11 patches have the xensource (2.6.18 forward
> port) of dom0 and all the other xen kernel features for 2.6.26..

sorry but no please read
http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines

pv_ops is the upstream way we enabled them in 2.6.25 and
enhance the existing 2.6.26 base.
what are you moaning?



> > see relevant posts of Ian Campbell on d-kernel
> >
>
> You mean this?: http://lists.debian.org/debian-kernel/2008/07/msg00070.html
>
> I think the situation has changed after that..
>
> See: http://wiki.xensource.com/xenwiki/XenParavirtOps
>
> I think x86-64 xen patches are going in for 2.6.27..
>
> http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=summary
>
> "9 hours ago Ingo Molnar Merge branch 'xen-64bit'"

right but you seem to have zero idea about the x86 upstream git
tree and it's dependencies. the merge of that is out of question
for the upcoming stable kernel.

--
maks

Ian Campbell

unread,
Jul 16, 2008, 7:10:18 AM7/16/08
to
On Wed, 2008-07-16 at 12:51 +0300, Pasi Kärkkäinen wrote:
> On Wed, Jul 16, 2008 at 10:50:22AM +0200, maximilian attems wrote:
> > see relevant posts of Ian Campbell on d-kernel
> >
>
> You mean this?: http://lists.debian.org/debian-kernel/2008/07/msg00070.html
>
> I think the situation has changed after that..

The save/restore and ballooning patches were applied to the trunk 2.6.26
Debian kernel a few days back, enabling these features for 32 bit
kernels.

>
> See: http://wiki.xensource.com/xenwiki/XenParavirtOps
>
> I think x86-64 xen patches are going in for 2.6.27..
>
> http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=summary
>
> "9 hours ago Ingo Molnar Merge branch 'xen-64bit'"

Lenny will be releasing with (at most) 2.6.26 and these patches are a
bit too large and intrusive to non-Xen code paths to be backported.

Ian.
--
Ian Campbell
Current Noise: Orange Goblin - Land Of Secret Dreams

Speak softly and own a big, mean Doberman.
-- Dave Millman


--
To UNSUBSCRIBE, email to debian-ker...@lists.debian.org

Pasi Kärkkäinen

unread,
Jul 16, 2008, 7:50:10 AM7/16/08
to

This thread was started to discuss possible ways to get xen dom0 support
into lenny.. this SLES11 patch thingie was one option.

But I guess it's not possible solution.


> > > see relevant posts of Ian Campbell on d-kernel
> > >
> >
> > You mean this?: http://lists.debian.org/debian-kernel/2008/07/msg00070.html
> >
> > I think the situation has changed after that..
> >
> > See: http://wiki.xensource.com/xenwiki/XenParavirtOps
> >
> > I think x86-64 xen patches are going in for 2.6.27..
> >
> > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=summary
> >
> > "9 hours ago Ingo Molnar Merge branch 'xen-64bit'"
>
> right but you seem to have zero idea about the x86 upstream git
> tree and it's dependencies. the merge of that is out of question
> for the upcoming stable kernel.
>

I only meant that those patches are queued for 2.6.27.

-- Pasi

Pasi Kärkkäinen

unread,
Jul 16, 2008, 7:50:13 AM7/16/08
to
On Wed, Jul 16, 2008 at 11:57:26AM +0100, Ian Campbell wrote:
> On Wed, 2008-07-16 at 12:51 +0300, Pasi Kärkkäinen wrote:
> > On Wed, Jul 16, 2008 at 10:50:22AM +0200, maximilian attems wrote:
> > > see relevant posts of Ian Campbell on d-kernel
> > >
> >
> > You mean this?: http://lists.debian.org/debian-kernel/2008/07/msg00070.html
> >
> > I think the situation has changed after that..
>
> The save/restore and ballooning patches were applied to the trunk 2.6.26
> Debian kernel a few days back, enabling these features for 32 bit
> kernels.
>

Yep.

> >
> > See: http://wiki.xensource.com/xenwiki/XenParavirtOps
> >
> > I think x86-64 xen patches are going in for 2.6.27..
> >
> > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=summary
> >
> > "9 hours ago Ingo Molnar Merge branch 'xen-64bit'"
>
> Lenny will be releasing with (at most) 2.6.26 and these patches are a
> bit too large and intrusive to non-Xen code paths to be backported.
>

Yeah, I only meant those patches are queued for upstream 2.6.27. I didn't
mean they should be applied to debian xen kernel for lenny.

Like said, this thread was started to discuss about possible options of
getting xen dom0 support into lenny, and I pasted that git link to give a
status update of pv_ops work happening atm.

-- Pasi

maximilian attems

unread,
Jul 16, 2008, 8:10:08 AM7/16/08
to
On Wed, Jul 16, 2008 at 02:23:26PM +0300, Pasi Kärkkäinen wrote:
> Like said, this thread was started to discuss about possible options of
> getting xen dom0 support into lenny, and I pasted that git link to give a
> status update of pv_ops work happening atm.

current best guess is lenny+half.

having seen the lessons of etch+half and with the established procedure
we should start sooner. 4 upstream version after the release as goal.
that would be 2.6.30 if naming stays the same. most probably this
would have much wider xen support including dom0.

there still exists the unofficial waldi's dom0 2.6.18 latest xen branch
based kernels.

--
maks

William Pitcock

unread,
Jul 16, 2008, 8:10:16 AM7/16/08
to

Without dom0, lenny will be unusable for several installations of mine
which presently run an ugly combination of etch's dom0 and lenny's
kernel. I would like to do that in a different way.

If we will not see dom0 in linux-2.6 on Debian, we should at least have
a 2.6.18 tree with dom0.

William

signature.asc

Pasi Kärkkäinen

unread,
Jul 16, 2008, 8:10:18 AM7/16/08
to
On Wed, Jul 16, 2008 at 02:23:26PM +0300, Pasi Kärkkäinen wrote:
> On Wed, Jul 16, 2008 at 11:57:26AM +0100, Ian Campbell wrote:
> > On Wed, 2008-07-16 at 12:51 +0300, Pasi Kärkkäinen wrote:
> > > On Wed, Jul 16, 2008 at 10:50:22AM +0200, maximilian attems wrote:
> > > > see relevant posts of Ian Campbell on d-kernel
> > > >
> > >
> > > You mean this?: http://lists.debian.org/debian-kernel/2008/07/msg00070.html
> > >
> > > I think the situation has changed after that..
> >
> > The save/restore and ballooning patches were applied to the trunk 2.6.26
> > Debian kernel a few days back, enabling these features for 32 bit
> > kernels.
> >
>
> Yep.
>
> > >
> > > See: http://wiki.xensource.com/xenwiki/XenParavirtOps
> > >
> > > I think x86-64 xen patches are going in for 2.6.27..
> > >
> > > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=summary
> > >
> > > "9 hours ago Ingo Molnar Merge branch 'xen-64bit'"
> >
> > Lenny will be releasing with (at most) 2.6.26 and these patches are a
> > bit too large and intrusive to non-Xen code paths to be backported.
> >
>
> Yeah, I only meant those patches are queued for upstream 2.6.27. I didn't
> mean they should be applied to debian xen kernel for lenny.
>
> Like said, this thread was started to discuss about possible options of
> getting xen dom0 support into lenny, and I pasted that git link to give a
> status update of pv_ops work happening atm.
>

Lenny will ship with a much worse Xen support than etch.. which sucks.

Lenny will not support 64bit, no dom0.. so basicly lenny can only be used as
a 32bit domU .. unless people build/get some other dom0 kernel.

Obviously this is not debian's fault, and that's why we have this discussion
now.. trying to see if there are any options of fixing the situation.

(this thread was started on debian-xen list btw.. at some point it has
falled off from CC list though)

maximilian attems

unread,
Jul 16, 2008, 8:30:22 AM7/16/08
to
On Wed, Jul 16, 2008 at 07:11:06AM -0500, William Pitcock wrote:
>
> Without dom0, lenny will be unusable for several installations of mine
> which presently run an ugly combination of etch's dom0 and lenny's
> kernel. I would like to do that in a different way.
>
> If we will not see dom0 in linux-2.6 on Debian, we should at least have
> a 2.6.18 tree with dom0.

no.
we will not have 2 different linux-2.6 versions in Lenny.
please think of the implications before throwing out suggestions.

William Pitcock

unread,
Jul 16, 2008, 8:30:25 AM7/16/08
to
On Wed, 2008-07-16 at 14:11 +0200, maximilian attems wrote:
> On Wed, Jul 16, 2008 at 07:11:06AM -0500, William Pitcock wrote:
> >
> > Without dom0, lenny will be unusable for several installations of mine
> > which presently run an ugly combination of etch's dom0 and lenny's
> > kernel. I would like to do that in a different way.
> >
> > If we will not see dom0 in linux-2.6 on Debian, we should at least have
> > a 2.6.18 tree with dom0.
>
> no.
> we will not have 2 different linux-2.6 versions in Lenny.
> please think of the implications before throwing out suggestions.
>

What about the implications of introducing feature regressions? The
patches to enable dom0 without pv-ops are available, yet they are
unwanted.

Wouldn't it be possible to build with both pv-ops and non-pv-ops for
dom0?

At any rate, please make it well documented where waldi's kernels are if
you intend to not have dom0 in 2.6.26.

William

signature.asc

Gunnar Wolf

unread,
Jul 16, 2008, 8:50:21 AM7/16/08
to
Goswin von Brederlow dijo [Tue, Jul 15, 2008 at 11:10:30PM +0200]:

> > I don't think that any of the alternatives are valid candidates yet:
> > - Linux-Vserver, OpenVZ: clearly not the same use case.
> > - Virtualbox, qemu: poor performance under some workloads.
>
> Unusable for production work. Emulation is just too slow. The group of
> people that can live with that much slow down compared to xen is
> miniscule.

Just to state the obvious: I understand your lines applie to
virtualbox and qemu, not to linux-vserver, which is completely usable
for production work - although it's a completely different approach,
completely useless to people who really want seemingly independent
full machines (i.e. different OSs or kernel features).

> > - KVM: is very promising but is it really a valid alternative *now*
> > for current Xen users?
>
> KVM needs hardware support and even then its I/O is slower. It also
> deadlocks the I/O under I/O load from time to time.
>
> I could live with the I/O slowdown but nothing will make hardware
> magically appear.

Please explain further on this. Do you mean that xen can run
paravirtualized hosts without the hardware features (i.e. the lesser
CPUs sold nowadays) while kvm does require VMX/SVM?

I have not done extensive testing yet (I'm a newbie to both
approaches), but I don't feel the slowdown you mention when under kvm.

Greetings,

--
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF

Pasi Kärkkäinen

unread,
Jul 16, 2008, 8:50:17 AM7/16/08
to
On Wed, Jul 16, 2008 at 02:11:48PM +0200, maximilian attems wrote:
> On Wed, Jul 16, 2008 at 07:11:06AM -0500, William Pitcock wrote:
> >
> > Without dom0, lenny will be unusable for several installations of mine
> > which presently run an ugly combination of etch's dom0 and lenny's
> > kernel. I would like to do that in a different way.
> >
> > If we will not see dom0 in linux-2.6 on Debian, we should at least have
> > a 2.6.18 tree with dom0.
>
> no.
> we will not have 2 different linux-2.6 versions in Lenny.
> please think of the implications before throwing out suggestions.
>

So basicly Debian takes the same route as Fedora did (see my other mail
about it).

It's understandable from the distribution/kernel maintencance point of view.

But it's really sucky for the users.. This needs good documentation in the
release notes etc.. so people realize lenny won't support Xen virtualization
anymore (running virtual machines on lenny host).

-- Pasi

Pasi Kärkkäinen

unread,
Jul 16, 2008, 8:50:26 AM7/16/08
to
On Wed, Jul 16, 2008 at 07:11:06AM -0500, William Pitcock wrote:

For comparison Fedora people decided to release F9 with only domU support
included.. they didn't want to do anymore forward porting from xensource
2.6.18 xen kernels (I bet noone wants to do that) and decided to include
pv_ops based upstream kernel. And they wanted to have same versions of
both the normal (baremetal) kernel and kernel-xen.

but they patched 64bit xen pv_ops domU support in. So F9 supports both 32b
and 64b pv_ops domU. F9 has 2.6.25 kernel.

Fedora is planning to add dom0 support back to their kernel when pv_ops
based dom0 is functional.. It's not yet certain if it will be ready for
their next release (F10).

Fedora people didn't want to include separate (2.6.18) xen dom0 kernel..
because it would have created too many problems with other tools/packages
requiring features/APIs/ABIs from the kernel.. too big difference between
2.6.18 (xensource) and 2.6.25+ (vanilla/upstream linux).

So yeah, just to wrap up their thoughts.

-- Pasi

Samuel Thibault

unread,
Jul 16, 2008, 9:30:24 AM7/16/08