FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 10-29-2009, 11:59 PM
Thomas Bächler
 
Default Xen domU kernel - what to do?

Okay, it is obvious that we need a kernel which can run on Xen domU for
our servers. It would also be very convenient for those running Arch on
hosting services that have pv-grub available.


Until now, I compiled a modified version of the kernel26 package with
pv_ops/Xern enabled which - in theory - should also run on a real machine.


If all the external modules compile properly (which they probably do),
we could add these options to our normal stock kernel. I haven't tried
running it on a real machine though and tpowa said in the past the
nvidia module failed. This has to be tested.


However, compiling Xen on a 32 bit kernel requires enabling PAE which we
refused to do in the past for performance reasons (no idea if these are
valid concerns) and due to the fact that we want to encourage people to
run 64 bit if they have large amounts of memory.


Assuming all of untested things above work, what would you prefer:

1) Switch to PAE on the 32 bit kernel, ship Xen domU support with
kernel26 on both architectures.


2) Ship Xen domU support on the 64 bit kernel, and don't on the 32 bit
kernel (my favorite so far).


3) Leave kernel26 unchanged and create a separate kernel26-xen package
with domU support.


The advantage of 3) is that the Xen kernel could be very slim, as almost
all hardware drivers could be disabled. The advantage of 1) and 2) is
the lower maintenance cost.



On a different note, I'd like to try to switch over to pv-grub on our
servers. Right now, upgrading the kernel requires copying the kernel to
the dom0 manually, thus dom0 access is required to do a (potentially
security relevant) kernel update. With pv-grub, upgrading the kernel and
rebooting would be handled just like with a normal machine, as the dom0
only loads the pv-grub image which then runs inside the domU and can
load the right kernel from there.
The pv-grub is only available from Xen 3.3 and later, but we have Xen
3.2 - I compiled pv-grub from 3.4 though and guess it should work with
the older hypervisor as well, but I haven't tested that yet.


Anyway, please post your opinion on the issues above.
 
Old 10-30-2009, 12:03 AM
Giovanni Scafora
 
Default Xen domU kernel - what to do?

2009/10/29, Thomas Bächler <thomas@archlinux.org>:
> 3) Leave kernel26 unchanged and create a separate kernel26-xen package with
> domU support.

I would prefer the third solution.


--
Arch Linux Developer
http://www.archlinux.org
http://www.archlinux.it
 
Old 10-30-2009, 12:12 AM
Pierre Schmitz
 
Default Xen domU kernel - what to do?

Am Freitag 30 Oktober 2009 01:59:19 schrieb Thomas Bächler:
> 1) Switch to PAE on the 32 bit kernel, ship Xen domU support with
> kernel26 on both architectures.
>
> 2) Ship Xen domU support on the 64 bit kernel, and don't on the 32 bit
> kernel (my favorite so far).
>
> 3) Leave kernel26 unchanged and create a separate kernel26-xen package
> with domU support.

What about an 4th option: Add xen support to the lts kernel which is meant for
servers anyway.

--

Pierre Schmitz, https://users.archlinux.de/~pierre
 
Old 10-30-2009, 06:41 AM
Jan de Groot
 
Default Xen domU kernel - what to do?

On Fri, 2009-10-30 at 02:12 +0100, Pierre Schmitz wrote:
> What about an 4th option: Add xen support to the lts kernel which is
> meant for
> servers anyway.

Which is probably broken because pvops/xen matured after 2.6.27?
 
Old 10-30-2009, 07:21 AM
Thomas Bächler
 
Default Xen domU kernel - what to do?

Jan de Groot schrieb:

On Fri, 2009-10-30 at 02:12 +0100, Pierre Schmitz wrote:

What about an 4th option: Add xen support to the lts kernel which is
meant for
servers anyway.


Which is probably broken because pvops/xen matured after 2.6.27?


That, and I doubt the lts kernel will be around very long as packages
like udev (and more) are developping quite fast, and lts stays ancient.
I'd like to have something recent, at least on our server.
 
Old 10-30-2009, 10:38 AM
Pierre Schmitz
 
Default Xen domU kernel - what to do?

Am Freitag 30 Oktober 2009 09:21:13 schrieb Thomas Bächler:
> Jan de Groot schrieb:
> > On Fri, 2009-10-30 at 02:12 +0100, Pierre Schmitz wrote:
> >> What about an 4th option: Add xen support to the lts kernel which is
> >> meant for
> >> servers anyway.
> >
> > Which is probably broken because pvops/xen matured after 2.6.27?
>
> That, and I doubt the lts kernel will be around very long as packages
> like udev (and more) are developping quite fast, and lts stays ancient.
> I'd like to have something recent, at least on our server.

Fair enough. So as long as this change does not introduce püroblems or
decrease of performance for the average desktop user I am fine with whatever
you like.

--

Pierre Schmitz, https://users.archlinux.de/~pierre
 
Old 10-30-2009, 10:51 AM
Thomas Bächler
 
Default Xen domU kernel - what to do?

Pierre Schmitz schrieb:
Fair enough. So as long as this change does not introduce püroblems or
decrease of performance for the average desktop user I am fine with whatever
you like.


The performance question is hard to answer - however, as we have pv_ops
enabled anyway, I guess there will be no difference anymore. Even the
difference between pv_ops and no pv_ops is very small.
 
Old 10-30-2009, 01:04 PM
RedShift
 
Default Xen domU kernel - what to do?

Thomas Bächler wrote:
Okay, it is obvious that we need a kernel which can run on Xen domU for
our servers. It would also be very convenient for those running Arch on
hosting services that have pv-grub available.




What about dumping Xen in favor of KVM and move libvirt and virt-manager to extra?


Glenn
 
Old 10-30-2009, 10:51 PM
Dan McGee
 
Default Xen domU kernel - what to do?

On Thu, Oct 29, 2009 at 7:59 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Okay, it is obvious that we need a kernel which can run on Xen domU for our
> servers. It would also be very convenient for those running Arch on hosting
> services that have pv-grub available.
>
> Until now, I compiled a modified version of the kernel26 package with
> pv_ops/Xern enabled which - in theory - should also run on a real machine.
>
> If all the external modules compile properly (which they probably do), we
> could add these options to our normal stock kernel. I haven't tried running
> it on a real machine though and tpowa said in the past the nvidia module
> failed. This has to be tested.
>
> However, compiling Xen on a 32 bit kernel requires enabling PAE which we
> refused to do in the past for performance reasons (no idea if these are
> valid concerns) and due to the fact that we want to encourage people to run
> 64 bit if they have large amounts of memory.
>
> Assuming all of untested things above work, what would you prefer:
>
> 1) Switch to PAE on the 32 bit kernel, ship Xen domU support with kernel26
> on both architectures.
>
> 2) Ship Xen domU support on the 64 bit kernel, and don't on the 32 bit
> kernel (my favorite so far).
>
> 3) Leave kernel26 unchanged and create a separate kernel26-xen package with
> domU support.
>
> The advantage of 3) is that the Xen kernel could be very slim, as almost all
> hardware drivers could be disabled. The advantage of 1) and 2) is the lower
> maintenance cost.
>
>
> On a different note, I'd like to try to switch over to pv-grub on our
> servers. Right now, upgrading the kernel requires copying the kernel to the
> dom0 manually, thus dom0 access is required to do a (potentially security
> relevant) kernel update. With pv-grub, upgrading the kernel and rebooting
> would be handled just like with a normal machine, as the dom0 only loads the
> pv-grub image which then runs inside the domU and can load the right kernel
> from there.
> The pv-grub is only available from Xen 3.3 and later, but we have Xen 3.2 -
> I compiled pv-grub from 3.4 though and guess it should work with the older
> hypervisor as well, but I haven't tested that yet.
>
> Anyway, please post your opinion on the issues above.

I'm -1 on the PAE, leaving options 2 and 3 as viable. 2 is the easiest
for maintenance; 3 sounds like the best solution long term as it would
be a very lightweight and well-suited kernel package.

If not for the maintenance issues, 3 seems by far the best. Is there
anyway we can automate the creation of this package to the point where
it doesn't take much extra effort? e.g. try to share resources with
the primary kernel package.

-Dan
 
Old 10-30-2009, 11:22 PM
Aaron Griffin
 
Default Xen domU kernel - what to do?

On Fri, Oct 30, 2009 at 6:51 PM, Dan McGee <dpmcgee@gmail.com> wrote:
> On Thu, Oct 29, 2009 at 7:59 PM, Thomas Bächler <thomas@archlinux.org> wrote:
>> Okay, it is obvious that we need a kernel which can run on Xen domU for our
>> servers. It would also be very convenient for those running Arch on hosting
>> services that have pv-grub available.
>>
>> Until now, I compiled a modified version of the kernel26 package with
>> pv_ops/Xern enabled which - in theory - should also run on a real machine.
>>
>> If all the external modules compile properly (which they probably do), we
>> could add these options to our normal stock kernel. I haven't tried running
>> it on a real machine though and tpowa said in the past the nvidia module
>> failed. This has to be tested.
>>
>> However, compiling Xen on a 32 bit kernel requires enabling PAE which we
>> refused to do in the past for performance reasons (no idea if these are
>> valid concerns) and due to the fact that we want to encourage people to run
>> 64 bit if they have large amounts of memory.
>>
>> Assuming all of untested things above work, what would you prefer:
>>
>> 1) Switch to PAE on the 32 bit kernel, ship Xen domU support with kernel26
>> on both architectures.
>>
>> 2) Ship Xen domU support on the 64 bit kernel, and don't on the 32 bit
>> kernel (my favorite so far).
>>
>> 3) Leave kernel26 unchanged and create a separate kernel26-xen package with
>> domU support.
>>
>> The advantage of 3) is that the Xen kernel could be very slim, as almost all
>> hardware drivers could be disabled. The advantage of 1) and 2) is the lower
>> maintenance cost.
>>
>>
>> On a different note, I'd like to try to switch over to pv-grub on our
>> servers. Right now, upgrading the kernel requires copying the kernel to the
>> dom0 manually, thus dom0 access is required to do a (potentially security
>> relevant) kernel update. With pv-grub, upgrading the kernel and rebooting
>> would be handled just like with a normal machine, as the dom0 only loads the
>> pv-grub image which then runs inside the domU and can load the right kernel
>> from there.
>> The pv-grub is only available from Xen 3.3 and later, but we have Xen 3.2 -
>> I compiled pv-grub from 3.4 though and guess it should work with the older
>> hypervisor as well, but I haven't tested that yet.
>>
>> Anyway, please post your opinion on the issues above.
>
> I'm -1 on the PAE, leaving options 2 and 3 as viable. 2 is the easiest
> for maintenance; 3 sounds like the best solution long term as it would
> be a very lightweight and well-suited kernel package.
>
> If not for the maintenance issues, 3 seems by far the best. Is there
> anyway we can automate the creation of this package to the point where
> it doesn't take much extra effort? e.g. try to share resources with
> the primary kernel package.

Can you illustrate why you're -1 on PAE? I can't find exact info on
the performance hit caused by enabling that, and with machines having
more and more RAM, I'm sure we'll eventually need to enable PAE. I
_know_ we're trying to push people to 64bit, but that shouldn't mean
we leave the i686 arch in the dust.

I'm just sure we're EVENTUALLY going to need to enable this. Why not now?
 

Thread Tools




All times are GMT. The time now is 02:44 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org