Xen status in lenny?
Lucas Nussbaum
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
> 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
> 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
Paul van der Vlis
Some Fedora-links about Xen:
http://fedoraproject.org/wiki/Features/XenPvopsDom0
http://fedoraproject.org/wiki/Features/XenPvops
http://www.redhat.com/archives/fedora-xen/2008-March/msg00013.html
http://www.redhat.com/archives/fedora-xen/2008-March/thread.html
http://git.et.redhat.com/?p=xen-pvops-64.git
http://git.et.redhat.com/?p=linux-2.6-fedora-pvops.git;a=summary
http://cvs.fedora.redhat.com/viewcvs/rpms/kernel-xen-2.6/devel/
http://fedoraproject.org/wiki/Releases/10/Schedule
Eventually we could support the Etch-kernel in Lenny until there is
another solution?
Maybe we could make some publicity about this situation in Debian
Project News. Maybe there is someone who can help.
http://wiki.debian.org/ProjectNews/Issues/Current
With regards,
Paul van der Vlis.
Lucas Nussbaum
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,
Bastian Blank
> 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
Lucas Nussbaum
> 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
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? :-)
Vincent Bernat
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
> > > 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
> 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...
>
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
Lucas Nussbaum
> 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
> > 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
> > 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
> > > 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
> 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.
>
uninteresting, I don't want to have increase the complexity of the
networks I administer by bringing yet another distro into the mix.
Guido Trotter
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
> 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
> 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.
Luk Claes
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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.
John Goerzen
> 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
> 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
> 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
Pasi Kärkkäinen
> 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
> 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
> 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
> 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
> 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
William Pitcock
> 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
> > >
>
> 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?
> >
>
> pv_ops?
They include dom0 and are not based on paravirt_ops AFAIK.
William
Pasi Kärkkäinen
> <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
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
Bernd Zeimetz
>> 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
Well that's true..
Pasi Kärkkäinen
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
> 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
> 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
> 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
> 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
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
> 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
> 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.
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
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
Pasi Kärkkäinen
> 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
>
> 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
> 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
Gunnar Wolf
> > 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
> 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
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
> > 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?
Precisely.
Samuel
Goswin von Brederlow
> 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).
yes, obviously. :)
>> > - 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?
Yes, xen with paravirtualized hosts runs on cpus without hardware
virtualization.
> 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.
The "normal" kvm io uses the qemu device emulation and is dead slow
and unsecure. As such it is pretty much out of the question for
production work.
But kvm can also use the virtio drivers that raise the network speed
to slightly over 40MB/s. Disk speed is slower but that might just be
my laptops disk.
Now with xen on the other hand I get up to 180MB/s throughput on the
network interface.
> Greetings,
MfG
Goswin
Teodor
>> > > See: http://wiki.xensource.com/xenwiki/XenParavirtOps
>> > > I think x86-64 xen patches are going in for 2.6.27..
>
> a 32bit domU .. unless people build/get some other dom0 kernel.
What about the patches for x86-64 support in domU? If these are going
to be included in 2.6.27 does it mean they qualify [1] to be included
in the kernel for lenny?
Thanks
[1] http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
maximilian attems
> On Wed, Jul 16, 2008 at 2:49 PM, Pasi Kärkkäinen <pa...@iki.fi> wrote:
> >> > > See: http://wiki.xensource.com/xenwiki/XenParavirtOps
> >> > > I think x86-64 xen patches are going in for 2.6.27..
> >
> > 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.
>
> What about the patches for x86-64 support in domU? If these are going
> to be included in 2.6.27 does it mean they qualify [1] to be included
> in the kernel for lenny?
no.
please read a thread before posting to it, that question is already
answered twice.
--
maks
Pasi Kärkkäinen
> On Wed, Jul 16, 2008 at 07:53:52PM +0300, Teodor wrote:
> > On Wed, Jul 16, 2008 at 2:49 PM, Pasi Kärkkäinen <pa...@iki.fi> wrote:
> > >> > > See: http://wiki.xensource.com/xenwiki/XenParavirtOps
> > >> > > I think x86-64 xen patches are going in for 2.6.27..
> > >
> > > 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.
> >
> > What about the patches for x86-64 support in domU? If these are going
> > to be included in 2.6.27 does it mean they qualify [1] to be included
> > in the kernel for lenny?
>
> no.
> please read a thread before posting to it, that question is already
> answered twice.
>
btw out of curiosity do you know if the kernel patch policy was different
earlier (for etch), because xen kernel for etch (2.6.18-*-xen-686) contains
non-upstream xen patches (from xensource)..
-- Pasi
maximilian attems
> On Wed, Jul 16, 2008 at 07:26:48PM +0200, maximilian attems wrote:
> > On Wed, Jul 16, 2008 at 07:53:52PM +0300, Teodor wrote:
> > > On Wed, Jul 16, 2008 at 2:49 PM, Pasi Kärkkäinen <pa...@iki.fi> wrote:
> > > >> > > See: http://wiki.xensource.com/xenwiki/XenParavirtOps
> > > >> > > I think x86-64 xen patches are going in for 2.6.27..
> > > >
> > > > 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.
> > >
> > > What about the patches for x86-64 support in domU? If these are going
> > > to be included in 2.6.27 does it mean they qualify [1] to be included
> > > in the kernel for lenny?
> >
> > no.
> > please read a thread before posting to it, that question is already
> > answered twice.
> >
>
> btw out of curiosity do you know if the kernel patch policy was different
> earlier (for etch), because xen kernel for etch (2.6.18-*-xen-686) contains
> non-upstream xen patches (from xensource)..
xen upstream back then ported forward their own patches *and* everybody
expected their patches to be merged. earliest merge plans were floating
for 2.6.15.
reliance on external patches is always bad, kvm is in kernel.
it doesn't try to duplicate dog and cat, but uses linux scheduler
itself and so on..
also if release team still decides to push for 2.6.25, which is
possible if 2.6.26 turns out bad, you still have much less xen
features.
--
maks
Moritz Muehlenhoff
> 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.
Since there's now a sixth option - the forward-ported XenSource patch to
SLES's 2.6.26 - could we test this patch before we decide on a plan?
To me using the forward-ported SLES patch for Lenny and switching to pvops
post-Lenny seems ideal.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
Pasi Kärkkäinen
> On Wed, Jul 16, 2008 at 09:44:00PM +0300, Pasi Kärkkäinen wrote:
> > On Wed, Jul 16, 2008 at 07:26:48PM +0200, maximilian attems wrote:
> > > On Wed, Jul 16, 2008 at 07:53:52PM +0300, Teodor wrote:
> > > > On Wed, Jul 16, 2008 at 2:49 PM, Pasi Kärkkäinen <pa...@iki.fi> wrote:
> > > > >> > > See: http://wiki.xensource.com/xenwiki/XenParavirtOps
> > > > >> > > I think x86-64 xen patches are going in for 2.6.27..
> > > > >
> > > > > 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.
> > > >
> > > > What about the patches for x86-64 support in domU? If these are going
> > > > to be included in 2.6.27 does it mean they qualify [1] to be included
> > > > in the kernel for lenny?
> > >
> > > no.
> > > please read a thread before posting to it, that question is already
> > > answered twice.
> > >
> >
> > btw out of curiosity do you know if the kernel patch policy was different
> > earlier (for etch), because xen kernel for etch (2.6.18-*-xen-686) contains
> > non-upstream xen patches (from xensource)..
>
> xen upstream back then ported forward their own patches *and* everybody
> expected their patches to be merged. earliest merge plans were floating
> for 2.6.15.
>
Ok. This is what I expected happened back then.
> reliance on external patches is always bad, kvm is in kernel.
> it doesn't try to duplicate dog and cat, but uses linux scheduler
> itself and so on..
>
Yep.
> also if release team still decides to push for 2.6.25, which is
> possible if 2.6.26 turns out bad, you still have much less xen
> features.
>
Indeed. This is why the situation with Xen for Lenny is really problematic..
-- Pasi
Pasi Kärkkäinen
> Bastian Blank wrote:
> > 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.
>
> Since there's now a sixth option - the forward-ported XenSource patch to
> SLES's 2.6.26 - could we test this patch before we decide on a plan?
>
> To me using the forward-ported SLES patch for Lenny and switching to pvops
> post-Lenny seems ideal.
>
Yes, that would be ideal solution for users that want to have full-featured
Xen in Lenny.
But if you read the other messages in this thread, it won't happen I guess :(
That SLES forward-port for 2.6.26 is not acceptable based on Debian kernel
patch policy: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
-- Pasi
Peter Jordan
but is it acceptable to stop support for many debian etch xen dom0 machines?
PJ
Bastian Blank
> That SLES forward-port for 2.6.26 is not acceptable based on Debian kernel
> patch policy: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
Which is only the case for the main images. We have support for
additional feature sets, which have less strict rules.
Bastian
--
A little suffering is good for the soul.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0
maximilian attems
> On Thu, Jul 17, 2008 at 05:34:28PM +0300, Pasi Kärkkäinen wrote:
> > That SLES forward-port for 2.6.26 is not acceptable based on Debian kernel
> > patch policy: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
>
> Which is only the case for the main images. We have support for
> additional feature sets, which have less strict rules.
right but still no excuse to bring in a patch set that is *known*
to not be merged upstream.
--
maks
Bernd Eckenfels
> right but still no excuse to bring in a patch set that is *known*
> to not be merged upstream.
Isnt that the most obvious reason to distribute an additional patched
kernel? There is a user need and a patch..
Gruss
Bernd
Tollef Fog Heen
| On Fri, Jul 18, 2008 at 12:45:21AM +0200, Bastian Blank wrote:
| > On Thu, Jul 17, 2008 at 05:34:28PM +0300, Pasi Kärkkäinen wrote:
| > > That SLES forward-port for 2.6.26 is not acceptable based on Debian kernel
| > > patch policy: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
| >
| > Which is only the case for the main images. We have support for
| > additional feature sets, which have less strict rules.
|
| right but still no excuse to bring in a patch set that is *known*
| to not be merged upstream.
Of course it is when it is to prevent a fairly substantial regression
from etch. Whether etch should have shipped a dom0 or not is a
different question and a little late to complain about now; we just have
to do the best we can with what we have.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
maximilian attems
>
> Of course it is when it is to prevent a fairly substantial regression
> from etch. Whether etch should have shipped a dom0 or not is a
> different question and a little late to complain about now; we just have
> to do the best we can with what we have.
an lenny+half with upstream merged version makes sense indeed.
until then people can rely on etch + etch unofficial images.
the regression would have been *huge* if we had no guest image support
at all, but that got fixed and is tested.
--
maks
Bastian Blank
> right but still no excuse to bring in a patch set that is *known*
> to not be merged upstream.
So OpenVZ is also out of reach.
Bastian
--
There is an order of things in this universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1
maximilian attems
> On Fri, Jul 18, 2008 at 01:04:45AM +0200, maximilian attems wrote:
> > right but still no excuse to bring in a patch set that is *known*
> > to not be merged upstream.
>
> So OpenVZ is also out of reach.
openvz is actively working on namespace merge and using the emerging
bits. their patchsize is decreasing.
--
maks
Bastian Blank
> On Fri, Jul 18, 2008 at 11:08:43AM +0200, Bastian Blank wrote:
> > On Fri, Jul 18, 2008 at 01:04:45AM +0200, maximilian attems wrote:
> > > right but still no excuse to bring in a patch set that is *known*
> > > to not be merged upstream.
> > So OpenVZ is also out of reach.
> openvz is actively working on namespace merge and using the emerging
> bits. their patchsize is decreasing.
Which does not change the fact that the patch in this form will never be
accepted.
Bastian
--
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
stardate 4842.6
maximilian attems
> On Fri, Jul 18, 2008 at 11:23:19AM +0200, maximilian attems wrote:
> > On Fri, Jul 18, 2008 at 11:08:43AM +0200, Bastian Blank wrote:
> > > On Fri, Jul 18, 2008 at 01:04:45AM +0200, maximilian attems wrote:
> > > > right but still no excuse to bring in a patch set that is *known*
> > > > to not be merged upstream.
> > > So OpenVZ is also out of reach.
> > openvz is actively working on namespace merge and using the emerging
> > bits. their patchsize is decreasing.
>
> Which does not change the fact that the patch in this form will never be
> accepted.
sure patchsets of such size are never gobed in *one* step.
here you'll find a nice metric on their merge success:
http://community.livejournal.com/openvz/22369.html
--
maks
Florian Reitmeir
>On Fri, Jul 18, 2008 at 11:08:43AM +0200, Bastian Blank wrote:
>> On Fri, Jul 18, 2008 at 01:04:45AM +0200, maximilian attems wrote:
>> > right but still no excuse to bring in a patch set that is *known*
>> > to not be merged upstream.
>>
>> So OpenVZ is also out of reach.
>
>openvz is actively working on namespace merge and using the emerging
>bits. their patchsize is decreasing.
and whats about vserver?
--
Florian Reitmeir
Gunnar Wolf
> >openvz is actively working on namespace merge and using the emerging
> >bits. their patchsize is decreasing.
>
> and whats about vserver?
vserver support is just fine.
--
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
Guido Günther
[..snip..]
> dom0 support is being worked on by Fedora people (I think) but there are
> no patches upstream yet.
We could recommend kvm+xenner+libvirt as "dom0" for people with
hardware virtualization support:
http://kraxel.fedorapeople.org/xenner/
I don't think we have this packaged yet though. If anybody wants to work
on this I'd be happy to help.
Cheers,
-- Guido
Gunnar Wolf
> On Fri, Jul 11, 2008 at 08:37:01AM +0100, Ian Campbell wrote:
> [..snip..]
> > dom0 support is being worked on by Fedora people (I think) but there are
> > no patches upstream yet.
> We could recommend kvm+xenner+libvirt as "dom0" for people with
> hardware virtualization support:
> http://kraxel.fedorapeople.org/xenner/
> I don't think we have this packaged yet though. If anybody wants to work
> on this I'd be happy to help.
Umh... AFAICT, that would only work for people using Xen for
paravirtualization, not for full virtualization. Nowadays, Xen's
administration tools are still way more complete than KVM's - But I
think it is in place to tell people... That KVM is the way.
--
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
LM Jogbäck
>
> 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?
>
Is the forward-ported Xen patch for 2.6.26 available somewhere, so
that an unofficial build of a dom0 2.6.26 for debian could be build?
/LM
Ben Hutchings
> On Wed, Jul 16, 2008 at 2:54 AM, Ben Hutchings <b...@decadent.org.uk> wrote:
>
> >
> > 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?
> >
>
> Is the forward-ported Xen patch for 2.6.26 available somewhere, so
> that an unofficial build of a dom0 2.6.26 for debian could be build?
Not yet. Keep watching that directory.
Ben.
--
Ben Hutchings
Who are all these weirdos? - David Bowie, about L-Space IRC channel #afp
Aurelien Jarno
With latest kvm version (71), I am able to reach 174 MB/s throughput on
the virtio network interface, so it is now comparable to Xen.
> Now with xen on the other hand I get up to 180MB/s throughput on the
> network interface.
>
>> Greetings,
>
> MfG
> Goswin
>
>
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aur...@debian.org | aure...@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Frederik Schueler
On Fri, Jul 18, 2008 at 01:04:45AM +0200, maximilian attems wrote:
> right but still no excuse to bring in a patch set that is *known*
> to not be merged upstream.
with our current options, loosing xen dom0 support IS a very good
excuse for this, IMO.
Best regards
Frederik Schüler
--
ENOSIG
Pasi Kärkkäinen
> Hi!
>
> On Fri, Jul 18, 2008 at 01:04:45AM +0200, maximilian attems wrote:
> > right but still no excuse to bring in a patch set that is *known*
> > to not be merged upstream.
>
> with our current options, loosing xen dom0 support IS a very good
> excuse for this, IMO.
>
Just for the record, Ubuntu chose this way and patched their 2.6.24 kernel
in 8.04 LTS with forward-port of 2.6.18 xensource xen patches.
-- Pasi
André Luís Lopes
Hash: SHA1
Hello,
Bastian Blank escreveu:
> On Thu, Jul 17, 2008 at 05:34:28PM +0300, Pasi Kärkkäinen wrote:
>> That SLES forward-port for 2.6.26 is not acceptable based on Debian kernel
>> patch policy: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
>
> Which is only the case for the main images. We have support for
> additional feature sets, which have less strict rules.
Does anyone have an updated status on this issue ? I have been
watching [0] almost daily and it seems that it's only 2.6.25 until now.
Does someone have a better contact with Novell/SuSE guys which are
doing the forward port work ? One can read at [1] that SLES 11 beta
testing will be open starting from September and will last till
February, so it may be that SLES could even change to a later kernel and
not use 2.6.26 at all (I have no detailed information about it and no
one told me that, it's just a possibility given that SLES 11 beta
testing will last till February next).
[0]ftp://ftp.suse.com/pub/projects/kernel/kotd/SL110_BRANCH/i386/
[1]http://www.novell.com/communities/node/5925/beta-testing-opportunity-sledsles-11
- --
André Luís Lopes
andrelop@{andrelop,debian}.org
http://www.andrelop.org/blog/
Public GPG KeyID : 9D1B82F6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkiu134ACgkQW4/i9Z0bgvYU5ACgnb2MokxPtZCmU6wq5tidnhYT
7EcAnjGHPw2iS7ofC9pfIh5TXvmwkYlR
=JToZ
-----END PGP SIGNATURE-----
Ben Hutchings
<snip>
> Does someone have a better contact with Novell/SuSE guys which are
> doing the forward port work ? One can read at [1] that SLES 11 beta
> testing will be open starting from September and will last till
> February, so it may be that SLES could even change to a later kernel and
> not use 2.6.26 at all (I have no detailed information about it and no
> one told me that, it's just a possibility given that SLES 11 beta
> testing will last till February next).
I'm not in direct contact but have colleagues who are. My understanding
is they are now intending to use 2.6.27.
Ben.
--
Ben Hutchings
It is easier to write an incorrect program than to understand a correct one.
Jan Wagner
On Tuesday 15 July 2008 16:02, Bastian Blank wrote:
> 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-5] (Option 6 / SLES's 2.6.26 mentioned later in thread by Moritz)
> 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.
since we have rolled out over 50 dom0 with etch, we are really interested into
having xen dom0 support in lenny. Are there any further decisions made? We
choosed debian, cause we thought that Xen support won't be droped in the next
stable release and there is no influence by commercial interests into this.
Thanks for your work and please keep me (and all the others, that seems
interested by looking into this thread) updated.
With kind regards, Jan.
--
Never write mail to <wa...@spamfalle.info>, you have been warned!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT d-- s+: a- C+++ UL++++ P+ L+++ E- W+++ N+++ o++ K++ w--- O M V- PS PE
Y++ PGP++ t-- 5 X R tv- b+ DI- D++ G++ e++ h-- r+++ y+++
------END GEEK CODE BLOCK------
Bastian Blank
> [Option 1-5] (Option 6 / SLES's 2.6.26 mentioned later in thread by Moritz)
Please show it. SLES 11 ships 2.6.25.
Bastian
--
Men of peace usually are [brave].
-- Spock, "The Savage Curtain", stardate 5906.5
Jan Wagner
On Wednesday 17 September 2008, Paul van der Vlis wrote:
> > since we have rolled out over 50 dom0 with etch, we are really interested
> > into having xen dom0 support in lenny.
>
> So far I know you can run Lenny as a dom0, but not with the Lenny
> kernel. You can e.g. use the Etch Xen kernel or the Xensource kernel,
> both Linux 2.6.18.
thats not what I understand as "dom0 support in lenny". I'm looking for
security support also for the kernel. I guess even if it's planed to release
lenny+1/2 with a dom0 kernel, we have the chance to have 2 pita:
* there will no dom0 support from upstream available in reasonable time
* security support for dom0 etch kernel packages ends without a replacement
available
Paul van der Vlis
> since we have rolled out over 50 dom0 with etch, we are really interested into
> having xen dom0 support in lenny.
So far I know you can run Lenny as a dom0, but not with the Lenny
kernel. You can e.g. use the Etch Xen kernel or the Xensource kernel,
both Linux 2.6.18.
It's expected that a dom0 will be included in Linux 2.6.28 or 29, after
some time there will be such a kernel for Lenny.
And this will get security support when "lenny-and-a-half" is released.
( but, I must say: I have tried to upgrade my 64-bit Etch dom0 to Lenny,
but it still does not work at the moment )
With regards,
Paul van der Vlis.
Jan Wagner
On Wednesday 17 September 2008, Bastian Blank wrote:
> On Tue, Sep 16, 2008 at 10:32:49PM +0200, Jan Wagner wrote:
> > [Option 1-5] (Option 6 / SLES's 2.6.26 mentioned later in thread by
> > Moritz)
>
> Please show it. SLES 11 ships 2.6.25.
I was just refering Message-ID: <slrng7shs...@inutil.org>, didn't
verify it.
Pasi Kärkkäinen
> Good morning,
>
> On Wednesday 17 September 2008, Paul van der Vlis wrote:
> > > since we have rolled out over 50 dom0 with etch, we are really interested
> > > into having xen dom0 support in lenny.
> >
> > So far I know you can run Lenny as a dom0, but not with the Lenny
> > kernel. You can e.g. use the Etch Xen kernel or the Xensource kernel,
> > both Linux 2.6.18.
>
> thats not what I understand as "dom0 support in lenny". I'm looking for
> security support also for the kernel. I guess even if it's planed to release
> lenny+1/2 with a dom0 kernel, we have the chance to have 2 pita:
>
> * there will no dom0 support from upstream available in reasonable time
You can monitor these pages for dom0 related info:
dom0 (and other pv_ops) patches:
http://xenbits.xensource.com/paravirt_ops/patches.hg/
General information/progress about pv_ops upstream Xen kernel:
http://wiki.xensource.com/xenwiki/XenParavirtOps
-- Pasi
Jan Wagner
> On Wednesday 17 September 2008, Bastian Blank wrote:
> > On Tue, Sep 16, 2008 at 10:32:49PM +0200, Jan Wagner wrote:
> > > [Option 1-5] (Option 6 / SLES's 2.6.26 mentioned later in thread by
> > > Moritz)
> >
> > Please show it. SLES 11 ships 2.6.25.
>
> I was just refering Message-ID: <slrng7shs...@inutil.org>, didn't
> verify it.
What about
http://ftp.suse.com/pub/projects/kernel/kotd/HEAD/x86_64/2.6.26/kernel-
source-2.6.26-HEAD_20080808143035.src.rpm ?
Gustavo Noronha Silva
> ( but, I must say: I have tried to upgrade my 64-bit Etch dom0 to Lenny,
> but it still does not work at the moment )
I upgraded a dom0 I maintain to Lenny, the kernel got upgraded and I had
of course a boot failure when trying to boot Xen 3.2 and linux 2.6.26.
I'm not really sure about the reason since it is a remotely hosted box,
but I had to go back to 2.6.18.
See you,
--
Gustavo Noronha Silva <k...@debian.org>
Debian Project
Bastian Blank
> What about
> http://ftp.suse.com/pub/projects/kernel/kotd/HEAD/x86_64/2.6.26/kernel-
> source-2.6.26-HEAD_20080808143035.src.rpm ?
http://194.39.182.225/debian/xen/ contains packages using most of the
xen parts. http://194.39.182.225/linux/git/2.6.26-xen-suse includes the
patches.
Checksums:
| fdf0c5dd755146ad2b631a60b02e90aa39a20d91 linux-headers-2.6.26-1-xen-686_2.6.26-6_i386.deb
| 90e62bb5548945e19620c6aa0b04b3fc532bc090 linux-headers-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
| e4bcee9c5d8f1d23c915e56487f51ecb82f405ac linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb
| 414f9d9c31cfaccbf595011c21b860bb33c56232 linux-image-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
| db1c10f13b4972a9ed6a2d834f3c14c858e162e7 linux-modules-2.6.26-1-xen-686_2.6.26-6_i386.deb
| 57000e8ff722dad5b5dd027f3b6f487ad0a22ea5 linux-modules-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
| 5faad1f7e42d8bab766e01a109fd6b50799aa5f5 xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb
| b06d9c5373927db34787bddfd9b455dec0bf2a8f xen-linux-system-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
Bastian
--
Conquest is easy. Control is not.
-- Kirk, "Mirror, Mirror", stardate unknown
Bastian Blank
On Wed, Sep 17, 2008 at 06:52:38PM +0200, Bastian Blank wrote:
> Checksums:
| fdf0c5dd755146ad2b631a60b02e90aa39a20d91 linux-headers-2.6.26-1-xen-686_2.6.26-6_i386.deb
| 90e62bb5548945e19620c6aa0b04b3fc532bc090 linux-headers-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
| e4bcee9c5d8f1d23c915e56487f51ecb82f405ac linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb
| 414f9d9c31cfaccbf595011c21b860bb33c56232 linux-image-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
| db1c10f13b4972a9ed6a2d834f3c14c858e162e7 linux-modules-2.6.26-1-xen-686_2.6.26-6_i386.deb
| 57000e8ff722dad5b5dd027f3b6f487ad0a22ea5 linux-modules-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
| 5faad1f7e42d8bab766e01a109fd6b50799aa5f5 xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb
| b06d9c5373927db34787bddfd9b455dec0bf2a8f xen-linux-system-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
--
I'm a soldier, not a diplomat. I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9
André Luís Lopes
Hash: SHA1
Hello kov,
Gustavo Noronha Silva escreveu:
> On Wed, 2008-09-17 at 09:31 +0200, Paul van der Vlis wrote:
>> ( but, I must say: I have tried to upgrade my 64-bit Etch dom0 to Lenny,
>> but it still does not work at the moment )
>
> I upgraded a dom0 I maintain to Lenny, the kernel got upgraded and I had
> of course a boot failure when trying to boot Xen 3.2 and linux 2.6.26.
> I'm not really sure about the reason since it is a remotely hosted box,
> but I had to go back to 2.6.18.
Yes, this will happen as there's no official dom0 support for kernels
which are newer than 2.6.18 coming from XenSource. Etch had a kernel
which had dom0 support as it was based exactly on 2.6.18.
We are discussing exactly this subject here. The distros which wants
to have a working dom0 support would need to do one more forward-porting
work so dom0 support would be available on later kernels (2.6.26, por
example).
It seems that SuSE did the work fot 2.6.26. The idea is to use a
paravirt_ops based kernel in the future, possibly starting on Lenny+1/2,
which would support dom0 natively without the need of a
non-official/non-supported forward-port.
Regards,
- --
André Luís Lopes
andrelop@{andrelop,debian}.org
http://www.andrelop.org/blog/
Public GPG KeyID : 9D1B82F6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjRTyUACgkQW4/i9Z0bgvbuxQCgiU4dVH8T4K6tEdThOH3xcpv0
SLsAoIkecfUBKWucq/6em8WDGcz51vpY
=uoDF
-----END PGP SIGNATURE-----
Gustavo Noronha Silva
> Gustavo Noronha Silva escreveu:
> > On Wed, 2008-09-17 at 09:31 +0200, Paul van der Vlis wrote:
> >> ( but, I must say: I have tried to upgrade my 64-bit Etch dom0 to Lenny,
> >> but it still does not work at the moment )
> >
> > I upgraded a dom0 I maintain to Lenny, the kernel got upgraded and I had
> > of course a boot failure when trying to boot Xen 3.2 and linux 2.6.26.
> > I'm not really sure about the reason since it is a remotely hosted box,
> > but I had to go back to 2.6.18.
>
> Yes, this will happen as there's no official dom0 support for kernels
> which are newer than 2.6.18 coming from XenSource. Etch had a kernel
> which had dom0 support as it was based exactly on 2.6.18.
Yeah, I realized that. My goal with my email was to actually say that
the system does work correctly after the upgrade, even if the kernel is
'outdated', but I just noticed that I failed to mention that hehe. So
here it is.
Ben Hutchings
> On Tue, Sep 16, 2008 at 10:32:49PM +0200, Jan Wagner wrote:
> > [Option 1-5] (Option 6 / SLES's 2.6.26 mentioned later in thread by Moritz)
>
> Please show it. SLES 11 ships 2.6.25.
You mean OpenSUSE 11 - SLES 11 doesn't exist yet. However, latest news
is that it is likely to include 2.6.27.
Ben.
André Luís Lopes
Hash: SHA1
Hello Bastian,
Bastian Blank escreveu:
> Should actually sign this.
>
> On Wed, Sep 17, 2008 at 06:52:38PM +0200, Bastian Blank wrote:
>> Checksums:
> | fdf0c5dd755146ad2b631a60b02e90aa39a20d91 linux-headers-2.6.26-1-xen-686_2.6.26-6_i386.deb
> | 90e62bb5548945e19620c6aa0b04b3fc532bc090 linux-headers-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
> | e4bcee9c5d8f1d23c915e56487f51ecb82f405ac linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb
> | 414f9d9c31cfaccbf595011c21b860bb33c56232 linux-image-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
> | db1c10f13b4972a9ed6a2d834f3c14c858e162e7 linux-modules-2.6.26-1-xen-686_2.6.26-6_i386.deb
> | 57000e8ff722dad5b5dd027f3b6f487ad0a22ea5 linux-modules-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
> | 5faad1f7e42d8bab766e01a109fd6b50799aa5f5 xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb
> | b06d9c5373927db34787bddfd9b455dec0bf2a8f xen-linux-system-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
I tried to use these packages by installing them on my home machine,
which currently runs Debian unstable updated everyday.
First of all, I should say that after downloading
xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb,
linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb and
linux-modules-2.6.26-1-xen-686_2.6.26-6_i386.deb I checked their
sha1sums and they matched the ones you listed above.
Here's what I got while trying to install them :
andrelop@foolish:~$ export LC_ALL=C && sudo dpkg -i
xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb
linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb
xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb
(Reading database ... 125794 files and directories currently installed.)
Preparing to replace xen-linux-system-2.6.26-1-xen-686 2.6.26-6 (using
xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb) ...
Unpacking replacement xen-linux-system-2.6.26-1-xen-686 ...
Preparing to replace linux-image-2.6.26-1-xen-686 2.6.26-6 (using
linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb) ...
Unpacking replacement linux-image-2.6.26-1-xen-686 ...
Preparing to replace xen-linux-system-2.6.26-1-xen-686 2.6.26-6 (using
xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb) ...
Unpacking replacement xen-linux-system-2.6.26-1-xen-686 ...
More than one copy of package xen-linux-system-2.6.26-1-xen-686 has been
unpacked
in this run ! Only configuring it once.
dpkg: dependency problems prevent configuration of
xen-linux-system-2.6.26-1-xen-686:
xen-linux-system-2.6.26-1-xen-686 depends on
xen-hypervisor-3.2-1-i386-pae | xen-hypervisor-3.1-1-i386-pae; however:
Package xen-hypervisor-3.2-1-i386-pae is not installed.
Package xen-hypervisor-3.1-1-i386-pae is not installed.
dpkg: error processing xen-linux-system-2.6.26-1-xen-686 (--install):
dependency problems - leaving unconfigured
Setting up linux-image-2.6.26-1-xen-686 (2.6.26-6) ...
update-initramfs: Generating /boot/initrd.img-2.6.26-1-xen-686
Errors were encountered while processing:
xen-linux-system-2.6.26-1-xen-686
andrelop@foolish:~$
It seems the problem is that xen-linux-system-2.6.26-1-xen-686
depends on xen-hypervisor-3.2-1-i386-pae | xen-hypervisor-3.1-1-i386-pae
but unstable doesn't have these packages. Unstable has only
xen-hypervisor-3.2-1-i386 and it doesn't provide
xen-hypervisor-3.2-1-i386-pae.
Actually, I don't know if xen-hypervisor-3.2-1-i386 should provide
xen-hypervisor-3.2-1-i386-pae or not, I'm just reporting this. I know
that there were some changes regarding PAE support on Xen upstream, but
I don't know how it reflected on Xen packaging on Debian.
Anyway, I tried booting the dom0 provided by your
linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb package and the machine
actually came up. I couldn't install any tool for creating VM later
(xen-tools, virtinst, virt-manager, etc) as the package dependency
systems were all trying to "fix" my system after the problem left by the
error reported earlier on this message when installing these packages.
I had no more time left to use this machine as a testbed so I
rebooted on my usual 2.6.26-1-686 (non-Xen) kernel again to get some
work done.
However, I noticed the Xen kernel giving some WARNINGs when i booted
it and later asking me to install a "xen-friendly" version of
glibc/libc6 or moving my /lib/tls to /lib/tls.disabled unless I wanted
to my system to become slow.
Actually, I installed libc6-xen and I have no /lib/tls so I don't
know what could me done to fix this situation. I'm attaching (gziped)
the dmesg from dom0, which shows all the warnings and the message about
the "xen-friendly" libc.
What I noticed, as the boot message said, was that the system became
really slow after I booted the Xen kernel. Running aptitude took two or
three times more time than running it under a non Xen-enabled kernel,
for example.
I don't know if it was some mistake I did (probably), but it would be
nice if you could tell me if I should have done my testing in any other
way. I'll probably have a QuadCore machine at work which I could test it
in the next two or three days, so I woul be glad to test it there.
Regards,
- --
André Luís Lopes
andrelop@{andrelop,debian}.org
http://www.andrelop.org/blog/
Public GPG KeyID : 9D1B82F6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjRmXAACgkQW4/i9Z0bgvY30ACcDpMm6PIf8OGbx4dwjwuskKSu
3I0AnAnzLdeLkuHg/HYDMIt3iEYLSMYj
=2x+h
-----END PGP SIGNATURE-----
Gabor Gombas
> I upgraded a dom0 I maintain to Lenny, the kernel got upgraded and I had
> of course a boot failure when trying to boot Xen 3.2 and linux 2.6.26.
> I'm not really sure about the reason since it is a remotely hosted box,
> but I had to go back to 2.6.18.
Something is fishy with your boot configuration. I've multiple dom0s
running lenny; kernel 2.6.26 is installed of course, but grub always
puts the Xen-enabled 2.6.18 before 2.6.26, so the new kernel won't be
booted unless you select it manually.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
Bastian Blank
> Bastian Blank escreveu:
> > On Wed, Sep 17, 2008 at 06:52:38PM +0200, Bastian Blank wrote:
Next try: http://194.39.182.225/debian/xen/try2.
> >> Checksums:
| facc08ef408b745052189d99e971ee0d0c01450c linux-headers-2.6.26-1-xen-686_2.6.26-6_i386.deb
| e819d7a6d849b738f39c4988b1f6c722f81eb5e1 linux-headers-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
| 7b8659fd984f8a1711fd5324bed20ad5b3f168bc linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb
| 7e01af430254ac90203fcf4c0ba7bf49ca9c7e4d linux-image-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
| e2b3ea5a57d3dfe89defe57c595a5a7f0025bbbc linux-modules-2.6.26-1-xen-686_2.6.26-6_i386.deb
| 73e9bb968768e2920735f7eb77fd9667f0ffce20 linux-modules-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
| 07ef8c3b6c4e2496afd3fc86347f5cf640a644f9 xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb
| ddfd7db322b8540cb0f606f974758e883d416a67 xen-linux-system-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb
> It seems the problem is that xen-linux-system-2.6.26-1-xen-686
> depends on xen-hypervisor-3.2-1-i386-pae | xen-hypervisor-3.1-1-i386-pae
> but unstable doesn't have these packages. Unstable has only
> xen-hypervisor-3.2-1-i386 and it doesn't provide
> xen-hypervisor-3.2-1-i386-pae.
Yes. Fixed in the new packages.
> Anyway, I tried booting the dom0 provided by your
> linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb package and the machine
> actually came up. I couldn't install any tool for creating VM later
> (xen-tools, virtinst, virt-manager, etc) as the package dependency
> systems were all trying to "fix" my system after the problem left by the
> error reported earlier on this message when installing these packages.
You could have just removed xen-linux-system-* as it is only a meta
package without actual functionality.
> However, I noticed the Xen kernel giving some WARNINGs when i booted
> it and later asking me to install a "xen-friendly" version of
> glibc/libc6 or moving my /lib/tls to /lib/tls.disabled unless I wanted
> to my system to become slow.
Yes. I removed that warning now as it makes more grief than good and is
not included in the paravirt_ops implementation.
> What I noticed, as the boot message said, was that the system became
> really slow after I booted the Xen kernel. Running aptitude took two or
> three times more time than running it under a non Xen-enabled kernel,
> for example.
This is the result of a bug in libc6-xen, set the following in
/etc/ld.so.conf.d/lib6-xen.conf
| hwcap 1 nosegneg
and run ldconfig. See #499366.
> I don't know if it was some mistake I did (probably), but it would be
> nice if you could tell me if I should have done my testing in any other
> way. I'll probably have a QuadCore machine at work which I could test it
> in the next two or three days, so I woul be glad to test it there.
I would appriciate any possible testing.
Bastian
--
Knowledge, sir, should be free to all!
-- Harry Mudd, "I, Mudd", stardate 4513.3