| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: Unofficial Xen 2.0 debian packages kinda broken
Brian Wolfe wrote:
> But hey, each admin has their own magical formula. *grin*
Exactly. What I have considered doing for a while is to make wrapper
around make-kpkg and the kernel directory with a curses UI that would
lessen confusion about what operations can be done next and what
options need to be passed to all commands and all that. A bit like how
debian-installer looks like.
> Where does make-kpkg stick the ekrnel and modules for unprived
> domains? I'm assuming still in /boot and /lib/modules.
Yes, /boot and /lib/modules.
> I had a long discussion with Adam over the location of the kernel
> and modules for "loaded" kernels such as the ones used for starting
> domains via xm. We came to the conclusion that it made more sense to
> use /usr/lib/kernels for UML and xenlinux kernels (other than
> domain-0, which stays in /lib/modules and /boot). This way you can
> simply nfs export the modules and kernel to the unprived domains
> instead of having to load the darn package to every domain that
> needs them.
Well, it is a complex issue. For user-mode-linux, make-kpkg uses
/usr/bin/linux-x.x.x and /usr/lib/uml/x.x.x I believe.
I myself think about the matter a different way. I think the kernel is
a part of the *guest* filesystem. And inside the guest,
/lib/modules/x.x.x should be the kernel modules, /boot/config-x.x.x
should have the kernel config, /boot/System.map-x.x.x should be the
system map and the kernel binary should be found under /boot. And in
the Debian world, these things should be installed inside the guest
filesystem by a debian package. Special cases are honeypot guests and
secure guests where they should not have access to the kernel binary
or something.
The fact that the kernel is started from the host side (or even run as
a normal program on the host like in UML) is just an implementation
detail - and to behave as much like a 'real' virtual machine, there
should be a 'boot loader' which would dig the kernel binary from
inside the guest filesystem and then boot that, just like Grub does on
a native system.
And specifically in Xen's case when the priviledged domain 0 kernel
can also be booted as a guest kernel, I believe all the kernels and
modules should belong in /boot and /lib/modules.
But, like said, each admin has their own magical formula.
> What kind of 3rd part patches have you been using with xen so far?
I've put in some netfilter patches.
> If I do that I inevitably run into a mess with 2.4.27 and skbuff as
> well as IPSec issues in both 2.4.27 and 2.6.8. 8-P
I use 2.6.8 and don't use IPSec. So perhaps that's why.
> If you are using the debs I'm producing of xen, you may want to try
> using the kernel-patch-xen package instead of mkbuildtree for your
> kernels since it avoids the issues I mentioned above with sparse
> patching the deb source. The patch set I create seems to apply with
> a minimal fuzzing to a pristine kernel source as well as the debian
> kernel source.
I wanted to first see if the regular mkbuildtree could be used to
build - and yeah, I will probably use the kernel-patch-xen in the
future. Before this I just didn't know if the patch was good or not ;)
> Sorry for the spanish inquisition Nuutti. :)
No problem, glad to give a different point of view.
-- Naked
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home