[Pkg-xen-devel] Of historical interest only [u]

Yvette Chanco yentlsoup at gmail.com
Thu Feb 16 23:54:05 UTC 2006


Note to self... post when I get up, not before I go to sleep. I've read the
responses, and hopefully remember enough to not make redundant comments.

1) Kernel Images



I believe this is being addressed in another thread...


2) /lib/tls
> We all know about this.


The current party line (last I checked) was that _eventually_ xen will deal
with this with the libc people, and that running a system without moving
this is not dangerous, simply slower. Ergo, the warnings are scary, but not
fatal, and if you are a performance user, you should know how to deal with
it.

My workaround was something that checked on shutdown and moved this
directory (bad for policy) - it works for me because I also use grub from
unstable, so I have a better idea of what kernel will be booted. My thought
on this was to cross my fingers and wait, but I really think it is a
discussion that should be brought back to the main list, because it's not
just a debian issue.


2) Grub menu entries
> People used to debian are used to update-grub just working. My workaround
> is kind of awkward, but xen boot stanzas are complex. I'd love to discuss.



K.... hate to be redundant, how familiar are all of us with how this script
works? It's pretty text based, and my work-around "patch" depended on
looking specifically at what kernels look like built either from Adam's
patch, or from pure xen. It sounds awkward, but that's kind of what it does,
anyway. The only other change was a configuration setting that allowed you
to change memory for dom0 and pass boot options.

3) Init scripts
> For example, hang on shutdowns (in xen 2) are not normal behavior; if the
> domU won't die, the system won't shut down.



I may not understand it all (as I've not had this be a big problem in xen3),
but it sounds like it's better, but from the feedback I got, sys admins
would like and additional timeout. Maybe they are wrong, but the opinion
seemed to be that if  a domU won't terminate, they'd at least like a warning
and a chance to fix it. Not really a problem to make the change in the
scripts, if people agree this is the "correct" behavior.

4) Network scripts
>
> More transparency in the routing vs. bridging setups



I believe the comment was made to deal with this through better
documentation. I agree. I like the fact that if the dependencies are right,
it works out of the box, and you can intervene later. Of course, I intervene
to such a high degree that I don't always know what it's like for others.

5) xen-system
>
> My packages have a "xen-system" meta-package. I've seen feedback both
> ways. Some people are far enough that they know how to make the parts work.
> Some people just want to do a quick benchmark. If the meta-package doesn't
> end up in debian, I'll probably have to maintain the "meta fiddly bits" for
> those who want them.



"My" xen-system gives a base kernel, hypervisor, xend+ friends, and my funky
changes to update grub and to move /lib/tls. As long as the hardware is
supported, it seems to work. It does NOT include domU images, although I can
see the argument to add that.

As of now, it doesn't have an "OR" option for kernels, although I always
hoped to add that.



6) Installer
>
> Did this on a lark. Spent way to much time learning about the details. Got
> used more than I would ever have thought. Currently on source-forge.
> Probably not directly part of this, but it seems to be of interest to those
> who would like to see greater acceptance of Xen in mainstream.


It seems that people aren't averse to this, so I'll keep it as a personal
low priority for the new packages. Only because I spent far too long
learning about debian-installer to let the info go to waste... and because a
few people have said it really, really helped.


7) Upgrade



Hopefully we have a debconf wizard on the team that can come out with the
correct set of questions. This is probably off-the-wall, but shorewall has a
switch that is something like "sysadminisabsentminded" and this defaults to
"true" in debian. If there was an equivalent for our configs, true would
mean "don't upgrade without sys admin approval."


8) Life without xend


Addressed in other posts.

-Yvette
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20060216/bc7fbb9a/attachment.htm


More information about the Pkg-xen-devel mailing list