As we move forward with Xen enablement, there's a desire for being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The options for handling this are 1) Another kernel. This is bad due to a) we're running out of CD space already b) keeping things matched up between the HV and the guest kernels c) migration is worlds of pain with two types of kernels 2) Switch the 32-bit xen kernels to require PAE. For most "current" non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops 3) Do nothing, tell people to use 64bit if they want more than 4 gigs of RAM 4) Make the PAE code handled at runtime. This is a pretty non-trivial amount of work :)
Given these, we're looking at going with #2 and thus only having Xen work on PAE-capable hardware in the development tree. And we're planning to try to execute this switchover the beginning of next week. Note that this will not affect bare metal installs at all.
Jeremy
On 5/17/06, Jeremy Katz katzj@redhat.com wrote:
As we move forward with Xen enablement, there's a desire for being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The options for handling this are
- Another kernel. This is bad due to a) we're running out of CD space already b) keeping things matched up between the HV and the guest kernels c) migration is worlds of pain with two types of kernels
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops 3) Do nothing, tell people to use 64bit if they want more than 4 gigs of RAM 4) Make the PAE code handled at runtime. This is a pretty non-trivial amount of work :)
Given these, we're looking at going with #2 and thus only having Xen work on PAE-capable hardware in the development tree. And we're planning to try to execute this switchover the beginning of next week. Note that this will not affect bare metal installs at all.
Jeremy
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
xen always needed p6 hardware (didnt run on k6-II for example), and AFAIK p6 supports PAE always, so not any lose here i think
On Thu, 2006-05-18 at 03:41 +0200, Arjan van de Ven wrote:
xen always needed p6 hardware (didnt run on k6-II for example), and AFAIK p6 supports PAE always, so not any lose here i think
you lose pentium M's.
Some of them. I have a Pentium M that has PAE. Though I just bought it about a month ago.
josh
On Wed, May 17, 2006 at 10:49:03PM +0200, Antonio Vargas wrote:
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops
xen always needed p6 hardware (didnt run on k6-II for example), and AFAIK p6 supports PAE always, so not any lose here i think
Sadly, not the case.. Celerons, and some Pentium-M's (as Jeremy noted above) are P6 class, yet lack PAE.
Dave
Dave Jones wrote:
On Wed, May 17, 2006 at 10:49:03PM +0200, Antonio Vargas wrote:
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops
xen always needed p6 hardware (didnt run on k6-II for example), and AFAIK p6 supports PAE always, so not any lose here i think
Sadly, not the case.. Celerons, and some Pentium-M's (as Jeremy noted above) are P6 class, yet lack PAE.
Ouch, this just bit my Dell D800 Pentium M 1.3GHz :-(
Obviously there haven't been Xen kernels available for a while, the previous one I had was 2.6.17-1.2307_FC6xen which worked for me, now I've updated to 2.6.17-1.2462.fc6xen and can't boot due to lack of PAE, presumably this does at least mean fc6t2 is "real close now" ...
I was already considering upgrading to a D820 to get HVM capability once the merom CPUs hit the shelves, I guess this will provide additional impetus ...
On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote:
As we move forward with Xen enablement, there's a desire for being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The options for handling this are
- Another kernel. This is bad due to a) we're running out of CD space already b) keeping things matched up between the HV and the guest kernels c) migration is worlds of pain with two types of kernels
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops
How do I know if my laptop if affected? :)
- Do nothing, tell people to use 64bit if they want more than 4 gigs of
RAM 4) Make the PAE code handled at runtime. This is a pretty non-trivial amount of work :)
Given these, we're looking at going with #2 and thus only having Xen work on PAE-capable hardware in the development tree. And we're planning to try to execute this switchover the beginning of next week. Note that this will not affect bare metal installs at all.
Jeremy
How do I know if my laptop if affected? :)
$ grep ' pae ' < /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
So that machine has the necessary harware. If ' pae ' is missing, then such a machine does not have good enough hardware.
On Wed, May 17, 2006 at 03:27:51PM -0700, John Reiser wrote:
How do I know if my laptop if affected? :)
$ grep ' pae ' < /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
So that machine has the necessary harware. If ' pae ' is missing, then such a machine does not have good enough hardware.
That already kills my 1 1/2 year old laptop :(
On Thu, May 18, 2006 at 12:31:09AM +0200, Axel Thimm wrote:
So that machine has the necessary harware. If ' pae ' is missing, then such a machine does not have good enough hardware.
That already kills my 1 1/2 year old laptop :(
And my laptop, and all of my other remaining x86-32 boxes which are VIA processor and where Xen would be most useful to aggregate them further.
The question is how common such boxes are however.
Alan
On Wed, 2006-05-17 at 15:27 -0700, John Reiser wrote:
$ grep ' pae ' < /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
So that machine has the necessary harware. If ' pae ' is missing, then such a machine does not have good enough hardware.
This is not entirely true. At least one laptop within Red Hat does NOT advertise PAE, but boots the kernel just fine (when the checking for pae in said file is disabled). So it would seem that there are chips out there that LIE about what they can do :/
On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote:
As we move forward with Xen enablement, there's a desire for being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The options for handling this are
- Another kernel. This is bad due to a) we're running out of CD space already b) keeping things matched up between the HV and the guest kernels c) migration is worlds of pain with two types of kernels
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops 3) Do nothing, tell people to use 64bit if they want more than 4 gigs of RAM 4) Make the PAE code handled at runtime. This is a pretty non-trivial amount of work :)
Given these, we're looking at going with #2 and thus only having Xen work on PAE-capable hardware in the development tree. And we're planning to try to execute this switchover the beginning of next week. Note that this will not affect bare metal installs at all.
Jeremy
Judging from the feedback I would derive that
o in later production environments usually hardware with PAE support will be used.
o during development, though, people would like to test xen on their non-PAE hardware like their laptops.
So maybe rawhide should continue with both PAE and non-PAE kernels and decide on dropping the non-PAE when a release is about to be cut? Otherwise you will keep out a large amount of (admittedly casual) testers.
And maybe until then the runtime handling emerges out of the blue and solves all issues. It's that improbable that it has to happen ;)
On Sat, 2006-05-20 at 16:14 +0200, Axel Thimm wrote:
On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote:
As we move forward with Xen enablement, there's a desire for being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The options for handling this are
- Another kernel. This is bad due to a) we're running out of CD space already b) keeping things matched up between the HV and the guest kernels c) migration is worlds of pain with two types of kernels
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops 3) Do nothing, tell people to use 64bit if they want more than 4 gigs of RAM 4) Make the PAE code handled at runtime. This is a pretty non-trivial amount of work :)
Given these, we're looking at going with #2 and thus only having Xen work on PAE-capable hardware in the development tree. And we're planning to try to execute this switchover the beginning of next week. Note that this will not affect bare metal installs at all.
Jeremy
Judging from the feedback I would derive that
o in later production environments usually hardware with PAE support will be used.
o during development, though, people would like to test xen on their non-PAE hardware like their laptops.
So maybe rawhide should continue with both PAE and non-PAE kernels and decide on dropping the non-PAE when a release is about to be cut?
I don't think so. I think you missed the "worlds of pain" part about having two kernels. It also becomes a resource issue.
I think option 1 is simply too much burden. So options 2 and 3 are left. It seems to come down to which is the "greater good". Which group is larger? The ones that don't have PAE hardware, or the ones that have machines with >= 4 gigs of RAM that are non-64bit.
Personally, I think option 2 is fine. Of course, both my machines have PAE :).
josh
On Sat, May 20, 2006 at 09:47:17AM -0500, Josh Boyer wrote:
On Sat, 2006-05-20 at 16:14 +0200, Axel Thimm wrote:
On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote:
As we move forward with Xen enablement, there's a desire for being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The options for handling this are
- Another kernel. This is bad due to a) we're running out of CD space already b) keeping things matched up between the HV and the guest kernels c) migration is worlds of pain with two types of kernels
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops 3) Do nothing, tell people to use 64bit if they want more than 4 gigs of RAM 4) Make the PAE code handled at runtime. This is a pretty non-trivial amount of work :)
Given these, we're looking at going with #2 and thus only having Xen work on PAE-capable hardware in the development tree. And we're planning to try to execute this switchover the beginning of next week. Note that this will not affect bare metal installs at all.
Jeremy
Judging from the feedback I would derive that
o in later production environments usually hardware with PAE support will be used.
o during development, though, people would like to test xen on their non-PAE hardware like their laptops.
So maybe rawhide should continue with both PAE and non-PAE kernels and decide on dropping the non-PAE when a release is about to be cut?
I don't think so. I think you missed the "worlds of pain" part about having two kernels. It also becomes a resource issue.
Not within rawhide, or?
I think option 1 is simply too much burden. So options 2 and 3 are left. It seems to come down to which is the "greater good". Which group is larger? The ones that don't have PAE hardware, or the ones that have machines with >= 4 gigs of RAM that are non-64bit.
Personally, I think option 2 is fine. Of course, both my machines have PAE :).
If personal bits matter, then I'd go for 3. I have no 32 bit machine with >= 4GB, but quite a few 64 bits ones. And the toy machines I would use to play with rawhide have no PAE. I guess whoever needs that much memory also needs something like x86_64' in-chip memory controller.
(the only systems I've recently seen with large memories running on 32 bits were 64-bits platforms with Debian, due to Debian not supporting multilib ...)
On Sat, 2006-05-20 at 17:26 +0200, Axel Thimm wrote:
On Sat, May 20, 2006 at 09:47:17AM -0500, Josh Boyer wrote:
On Sat, 2006-05-20 at 16:14 +0200, Axel Thimm wrote:
So maybe rawhide should continue with both PAE and non-PAE kernels and decide on dropping the non-PAE when a release is about to be cut?
I don't think so. I think you missed the "worlds of pain" part about having two kernels. It also becomes a resource issue.
Not within rawhide, or?
There's still just as much pain needed to do it just in the devel tree. The only thing that removes is the CD space burden/
I think option 1 is simply too much burden. So options 2 and 3 are left. It seems to come down to which is the "greater good". Which group is larger? The ones that don't have PAE hardware, or the ones that have machines with >= 4 gigs of RAM that are non-64bit.
Personally, I think option 2 is fine. Of course, both my machines have PAE :).
If personal bits matter, then I'd go for 3. I have no 32 bit machine with >= 4GB, but quite a few 64 bits ones. And the toy machines I would use to play with rawhide have no PAE. I guess whoever needs that much memory also needs something like x86_64' in-chip memory controller.
(the only systems I've recently seen with large memories running on 32 bits were 64-bits platforms with Debian, due to Debian not supporting multilib ...)
Sadly, many people continue to run 32-bit distros even on brand new hardware due to dependencies on "other stuff"[1]
Jeremy
[1] Think flash and the endless going on about that in 64bit browsers, or on the even more painful side there are things which require kernel modules :-/
On Mon, May 22, 2006 at 10:51:26AM -0400, Jeremy Katz wrote:
On Sat, 2006-05-20 at 17:26 +0200, Axel Thimm wrote:
On Sat, May 20, 2006 at 09:47:17AM -0500, Josh Boyer wrote: If personal bits matter, then I'd go for 3. I have no 32 bit machine with >= 4GB, but quite a few 64 bits ones. And the toy machines I would use to play with rawhide have no PAE. I guess whoever needs that much memory also needs something like x86_64' in-chip memory controller.
(the only systems I've recently seen with large memories running on 32 bits were 64-bits platforms with Debian, due to Debian not supporting multilib ...)
Sadly, many people continue to run 32-bit distros even on brand new hardware due to dependencies on "other stuff"[1]
Jeremy
[1] Think flash and the endless going on about that in 64bit browsers, or on the even more painful side there are things which require kernel modules :-/
So it's Desktop x86_64 users vs us poor ia32-no-PAE laptops. ;)
Anyway, I think you should pick what will make development for you easier/faster, which is probably more worth than any additional few random community testers. Maybe I'll get the chance to upgrade my laptop and then I'll make sure for the new one to be PAE-capable (unless this means too much $$$, but it sounded like any new laptop is supposed to have PAE).
Am Samstag, den 20.05.2006, 16:14 +0200 schrieb Axel Thimm:
On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote:
As we move forward with Xen enablement, there's a desire for being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The options for handling this are
[...]
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops
[...]
Given these, we're looking at going with #2 and thus only having Xen work on PAE-capable hardware in the development tree. And we're planning to try to execute this switchover the beginning of next week. Note that this will not affect bare metal installs at all.
[...] So maybe rawhide should continue with both PAE and non-PAE kernels and decide on dropping the non-PAE when a release is about to be cut? Otherwise you will keep out a large amount of (admittedly casual) testers.
Well, I was always against kernel's in Fedora Extras (and I still am, [mostly]). But having a Xen non-PAE kernel in Extras sounds like the proper solution for the above problem. But having kernels in Extras would only be okay for me if - they are build with the same spec-file as the other kernels - they are build on the same build system in the same step as the other kernels - they are moved to the proper Extras repo in the same moment as the other kernels are pushed out
There are some technical problems that probably would need to be solved before the above could be realized, but that should be possible if we really want to.
CU thl
On Sat, May 20, 2006 at 05:40:20PM +0200, Thorsten Leemhuis wrote:
Am Samstag, den 20.05.2006, 16:14 +0200 schrieb Axel Thimm:
On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote:
As we move forward with Xen enablement, there's a desire for being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The options for handling this are
[...]
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops
[...]
Given these, we're looking at going with #2 and thus only having Xen work on PAE-capable hardware in the development tree. And we're planning to try to execute this switchover the beginning of next week. Note that this will not affect bare metal installs at all.
[...] So maybe rawhide should continue with both PAE and non-PAE kernels and decide on dropping the non-PAE when a release is about to be cut? Otherwise you will keep out a large amount of (admittedly casual) testers.
Well, I was always against kernel's in Fedora Extras (and I still am, [mostly]). But having a Xen non-PAE kernel in Extras sounds like the proper solution for the above problem. But having kernels in Extras would only be okay for me if
- they are build with the same spec-file as the other kernels
- they are build on the same build system in the same step as the other
kernels
- they are moved to the proper Extras repo in the same moment as the
other kernels are pushed out
There are some technical problems that probably would need to be solved before the above could be realized, but that should be possible if we really want to.
Basically you want src.rpms in Core, but a way to move subpackages from a "Core build" to Extras, correct?
That only covers Jeremy's "no place on CD" point, what about migration and maintenance/security etc.?
Am Samstag, den 20.05.2006, 17:46 +0200 schrieb Axel Thimm:
On Sat, May 20, 2006 at 05:40:20PM +0200, Thorsten Leemhuis wrote:
Am Samstag, den 20.05.2006, 16:14 +0200 schrieb Axel Thimm:
On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote:
As we move forward with Xen enablement, there's a desire for being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The options for handling this are
[...]
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops
[...]
Given these, we're looking at going with #2 and thus only having Xen work on PAE-capable hardware in the development tree. And we're planning to try to execute this switchover the beginning of next week. Note that this will not affect bare metal installs at all.
[...] So maybe rawhide should continue with both PAE and non-PAE kernels and decide on dropping the non-PAE when a release is about to be cut? Otherwise you will keep out a large amount of (admittedly casual) testers.
Well, I was always against kernel's in Fedora Extras (and I still am, [mostly]). But having a Xen non-PAE kernel in Extras sounds like the proper solution for the above problem. But having kernels in Extras would only be okay for me if
- they are build with the same spec-file as the other kernels
- they are build on the same build system in the same step as the other
kernels
- they are moved to the proper Extras repo in the same moment as the
other kernels are pushed out
There are some technical problems that probably would need to be solved before the above could be realized, but that should be possible if we really want to.
Basically you want src.rpms in Core, but a way to move subpackages from a "Core build" to Extras, correct?
Yes.
That only covers Jeremy's "no place on CD" point, what about migration and maintenance/security etc.?
Build from the same specfile in the same step as the other (kernel-)packages, so maintenance/security is and should still be in the hands of the core maintainer.
CU thl
- Another kernel. This is bad due to a) we're running out of CD space already b) keeping things matched up between the HV and the guest kernels c) migration is worlds of pain with two types of kernels
Well, I was always against kernel's in Fedora Extras (and I still am, [mostly]). But having a Xen non-PAE kernel in Extras sounds like the proper solution for the above problem. But having kernels in Extras would only be okay for me if
Basically you want src.rpms in Core, but a way to move subpackages from a "Core build" to Extras, correct?
Yes.
That only covers Jeremy's "no place on CD" point, what about migration and maintenance/security etc.?
Build from the same specfile in the same step as the other (kernel-)packages, so maintenance/security is and should still be in the hands of the core maintainer.
But that's what the xen fedorians want to avoid, maintaining HV and migration for several kernels. The CD space argument is only valid for the time when the next release is to be cut, so it isn't high priority right now.
On Sat, 2006-05-20 at 17:40 +0200, Thorsten Leemhuis wrote:
Am Samstag, den 20.05.2006, 16:14 +0200 schrieb Axel Thimm:
On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote:
As we move forward with Xen enablement, there's a desire for being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The options for handling this are
[...]
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops
[...]
Given these, we're looking at going with #2 and thus only having Xen work on PAE-capable hardware in the development tree. And we're planning to try to execute this switchover the beginning of next week. Note that this will not affect bare metal installs at all.
[...] So maybe rawhide should continue with both PAE and non-PAE kernels and decide on dropping the non-PAE when a release is about to be cut? Otherwise you will keep out a large amount of (admittedly casual) testers.
Well, I was always against kernel's in Fedora Extras (and I still am, [mostly]). But having a Xen non-PAE kernel in Extras sounds like the proper solution for the above problem. But having kernels in Extras would only be okay for me if
- they are build with the same spec-file as the other kernels
- they are build on the same build system in the same step as the other
kernels
- they are moved to the proper Extras repo in the same moment as the
other kernels are pushed out
This involves huge fundamental changes to the build infrastructure that I'm really not sure are worth doing
There are some technical problems that probably would need to be solved before the above could be realized, but that should be possible if we really want to.
The other problem is the kernel binaries *have* to be with the installer, too -- otherwise, you can't install the guest as everything (HV + dom0 kernel + domU kernel) has to either be PAE or not. Mixing and matching can't happen :(
Jeremy
Am Montag, den 22.05.2006, 10:51 -0400 schrieb Jeremy Katz:
On Sat, 2006-05-20 at 17:40 +0200, Thorsten Leemhuis wrote:
Am Samstag, den 20.05.2006, 16:14 +0200 schrieb Axel Thimm:
On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote:
As we move forward with Xen enablement, there's a desire for being able to access more than 4 gigs of RAM on 32-bit Xen hosts. The options for handling this are
[...]
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops
[...]
Given these, we're looking at going with #2 and thus only having Xen work on PAE-capable hardware in the development tree. And we're planning to try to execute this switchover the beginning of next week. Note that this will not affect bare metal installs at all.
[...] So maybe rawhide should continue with both PAE and non-PAE kernels and decide on dropping the non-PAE when a release is about to be cut? Otherwise you will keep out a large amount of (admittedly casual) testers.
Well, I was always against kernel's in Fedora Extras (and I still am, [mostly]). But having a Xen non-PAE kernel in Extras sounds like the proper solution for the above problem. But having kernels in Extras would only be okay for me if
- they are build with the same spec-file as the other kernels
- they are build on the same build system in the same step as the other
kernels
- they are moved to the proper Extras repo in the same moment as the
other kernels are pushed out
This involves huge fundamental changes to the build infrastructure that I'm really not sure are worth doing
Well, that could be nice for other aspects, too. E.g. moving some devel packages and/or not that important sub-packages/language packs/whatever to Extras sound like a good idea in my eyes in general (at least in the long term).
There are some technical problems that probably would need to be solved before the above could be realized, but that should be possible if we really want to.
The other problem is the kernel binaries *have* to be with the installer, too -- otherwise, you can't install the guest as everything (HV + dom0 kernel + domU kernel) has to either be PAE or not. Mixing and matching can't happen :(
Okay, that's a good argument :-/
CU thl
On Mon, 2006-05-22 at 17:11 +0200, Thorsten Leemhuis wrote:
Well, that could be nice for other aspects, too. E.g. moving some devel packages and/or not that important sub-packages/language packs/whatever to Extras sound like a good idea in my eyes in general (at least in the long term).
More easily accomplished by putting everything outside and building it out there.
On Sat, 2006-05-20 at 16:14 +0200, Axel Thimm wrote:
Judging from the feedback I would derive that
o in later production environments usually hardware with PAE support will be used.
o during development, though, people would like to test xen on their non-PAE hardware like their laptops.
Basically.
So maybe rawhide should continue with both PAE and non-PAE kernels and decide on dropping the non-PAE when a release is about to be cut? Otherwise you will keep out a large amount of (admittedly casual) testers.
But this then requires doing all of the work to handle the case of both as well as breaking any sort of upgradeability. Plus, the testing will then largely end up on what's not shipped. Which isn't really what you want. Not to mention the last minute name switcheroo (which was quite nearly a disaster before FC5 :-)
And maybe until then the runtime handling emerges out of the blue and solves all issues. It's that improbable that it has to happen ;)
If we could only be so lucky... :)
Jeremy
On Mon, May 22, 2006 at 10:51:24AM -0400, Jeremy Katz wrote:
o during development, though, people would like to test xen on their non-PAE hardware like their laptops.
Basically.
Once you get into the habit of having your "desktop" as a Xen guest you migrate between your desktop and laptop when you travel you'll stop seeing it as a devlopment tool, very fast..
Alan Cox wrote:
Once you get into the habit of having your "desktop" as a Xen guest you migrate between your desktop and laptop when you travel you'll stop seeing it as a devlopment tool, very fast..
How do you migrate your storage?
Even with gigabit ethernet, copying a 50GB virtual disk can take a long time.
On Mon, 2006-05-22 at 18:24 +0300, Avi Kivity wrote:
How do you migrate your storage?
You don't just copy it blindly, you can synch it differentially, via something like rsync for example. I'm sure you can do even better with a special filesystem that can track what changed since last synch.
Dimi Paun wrote:
On Mon, 2006-05-22 at 18:24 +0300, Avi Kivity wrote:
How do you migrate your storage?
You don't just copy it blindly, you can synch it differentially, via something like rsync for example. I'm sure you can do even better with a special filesystem that can track what changed since last synch.
Well, you could have the desktop and laptop in a raid-1 over nbd with a write intent bitmap, so that only changed blocks are copied. Seems like everything is in place for that.
On Mon, 2006-05-22 at 18:39 +0300, Avi Kivity wrote:
Well, you could have the desktop and laptop in a raid-1 over nbd with a write intent bitmap, so that only changed blocks are copied. Seems like everything is in place for that.
Yeah, that should work, but I wonder what you lose by doing it at such a low level. For one, you need to have two identical partitions on the laptop and desktop. Not a big deal I guess, but mildly inconvenient. Second, you give up a bit of performance by working on the block level, but this may be negligible. Third, you lose the semantics of what's being changed, and this may be a problem when you update both the laptop and the desktop.
CODA has a disconnected operation mode, but I've never used it personally.
Alan Cox wrote:
On Mon, May 22, 2006 at 06:24:07PM +0300, Avi Kivity wrote:
Even with gigabit ethernet, copying a 50GB virtual disk can take a long time.
Rsync.
Still have to read every byte on the disk. I doubt you'd get away with less than 20 minutes.
Alan Cox wrote:
On Mon, May 22, 2006 at 07:48:53PM +0300, Avi Kivity wrote:
Rsync.
Still have to read every byte on the disk. I doubt you'd get away with less than 20 minutes.
That isn't a problem I find. It takes me a good hour to pack 8)
Actually rsync is slower than copying. Rsync has to read and write the entire image on the target, while a copy only needs to write it.
Rsync is excellent when network bandwidth is low, but with GbE, network bandwidth exceeds disk bandwidth.
On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote:
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops
Will the kernel src.rpm stay supporting building non-PAE kernels (via changing some macro)?
On Sat, May 20, 2006 at 05:47:40PM +0200, Jos Vos wrote:
On Wed, May 17, 2006 at 02:07:59PM -0400, Jeremy Katz wrote:
- Switch the 32-bit xen kernels to require PAE. For most "current"
non-laptop hardware, this is a non-issue. It does mean that xen won't work a lot of earlier PentiumM laptops
Will the kernel src.rpm stay supporting building non-PAE kernels (via changing some macro)?
That's doomed to break, reminds me of the switch to allow kernel-source(code) to build. Once it's off by default, noone will look anymore into it, and one day it will be removed as cruft (which it will have become ;).