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.<br><br><div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">1) Kernel Images</blockquote><div><br>
<br>
I believe this is being addressed in another thread...<br>
<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) /lib/tls <br>
We all know about this.</blockquote><div><br>
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.<br>
<br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) Grub menu entries<br>
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.</blockquote><div><br>
<br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3) Init scripts<br>
For example, hang on shutdowns (in xen 2) are not normal behavior; if the domU won't die, the system won't shut down.</blockquote><div><br>
<br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
4) Network scripts<br>
<br>
More transparency in the routing vs. bridging setups</blockquote><div><br>
<br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
5) xen-system<br>
<br>
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.</blockquote><div><br>
<br>
"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. <br>
<br>
As of now, it doesn't have an "OR" option for kernels, although I always hoped to add that. <br>
<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
6) Installer<br>
<br>
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.</blockquote><div><br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
7) Upgrade</blockquote><div><br>
<br>
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."<span style="font-weight: bold;"></span><br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
8) Life without xend</blockquote><div><br>
Addressed in other posts.<br>
<br>
-Yvette <br>
</div><br></div><br>