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

[Ralph Passgang]

Am Donnerstag, 16. Februar 2006 10:12 schrieb Julien Danjou:
> On Wed, Feb 15, 2006 at 09:51:25PM -0600, Yvette Chanco wrote:
> Hello
>
> My point of view, quickly, on this subjects.
>
> > 1) Kernel Images
>
> Impossible.

I don't really know if it's impossible or just hard to manage. I think we 
should try to think about possible solutions, because for a complete "xen 
system" there also have to be a kernel images for at least i386, i386+pae and 
amd64 available.

Not all Debian and/or xen beginers are able to compile their own kernel and 
even if they are, if they don't check the right options they probably have to 
do it over and over again which costs a lot of time. I would like to help the 
user with kernel images, but of course this has to be an option, if someone 
wants his own kernel he always can use the kernel-patch-xen package and 
create his own kernel.

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

but also not very easy to solve I guess... What is the right direction 
anyways? disabling tls by moving the folder (but having problems with updates 
of libc6 then) or using a special libc6 package which is compiled with some 
special flags? (see: http://wiki.xensource.com/xenwiki/DebianSarge)

this could get quite difficult I think.

> > 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.
>
> I didn't see you workarount, but I'm pretty sure it will be ok to manage
> this.

the problem I see is, that update-grub only makes sense if we also provide 
kernel images, otherweise what kernel image should be in the menu.lst?

but I also would like to have that support in xen/grub, because it helps the 
user.

> > 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.
>
> Should be easy to fix with a timeout.


in xen3 the default behaviour is to suspend/save the running domains before 
shutdown and to restore them after the reboot. This is configured 
in /etc/sysconfig/xendomains (I don't like the location for this config file, 
but it's hardcoded in xen source). For example you can also have your domUs 
migrated before shutdown and do other things.

In this config file there is also an option to tell xendomains how long to 
wait before skipping an operation (xm shutdown, xm migrate, xm save, ...) if 
nothing happens anymore. I think this solves the problems you experienced in 
xen2.

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

and a better documentation maybe. some debian specific doc would help.

> Not sure to understand.
>
> > 5) xen-system
>
> To see.

What does this meta-package installs? kernel + xen itself or even more?

> > 6) Installer
>
> To see, but later ;)

would be nice, but I agree that this is not top priority.

> > 7) Upgrade
>
> You have to reboot. :-)

100% ack. there is no other way if you want to use the new hypervisor that 
comes within a new xen package. But "upgrade" will be an topic anyway, 
because what is the right way of handling running domUs.

> > 8) Life without xend
> >
> > This is also partially me, but I've been in contact with the vmtools
> > people, and we use them in some cases, so it's good to keep in mind the
> > various dependencies (what you need to boot, vs. what you need to start a
> > domu).
> >
> > That's it off the top of my head. I'll post a few more if I find
> > something I've forgotten, or if people ask for proof ;)
>
> We should probably split the Xen boot image and the xend/xen tools, in
> order to provide later vmtools or anything else.

never have thought about it, but maybe we really should split userspace 
appications and hypervisor...

--Ralph