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

[Guido Trotter]

On Thu, Feb 16, 2006 at 10:49:54AM +0100, Ralph Passgang wrote:

Him

> > > 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.
> 

The point is that the security team doesn't want more kernels... They are doing
a great effort in order to reduce them, to be able to provide support, so
probably they aren't going to like to have ours! 

*if* and *when* xen is merged in the mainline everything becomes easier: we can
just ask them to produce more "flavors" from the same source, and nobody will
have issues with that... Then we can even make a debian-xen system installed
directly from d-i, if people agree that's useful!

> > > 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.
> 

Probably we need a xen-friendly glibc installed, at some point! 

> > > 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?
> 

That's true... :/

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

Well... it could be a feature of kernel-patch-xen, perhaps...

> > > 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.
> 

Good! ;)

> > > 4) Network scripts
> > >
> > > More transparency in the routing vs. bridging setups
> 
> and a better documentation maybe. some debian specific doc would help.
> 

Yeah... If we want bridging by default we should probably:

a) recommend bridge-utils
b) remove all the xen hack about moving the addresses under xen-br0, it's a lot
cleaner to use a "normal" br0 instead, created under /etc/network/interfaces !
We can surely do that by documentation, we have to see if we can make this work
"automagically" without breaking to many policies! ;)

> > > 5) xen-system
> >
> > To see.
> 
> What does this meta-package installs? kernel + xen itself or even more?
> 

I agree that it can absolutely fit in, if it's needed...

> > > 6) Installer
> >
> > To see, but later ;)
> 
> would be nice, but I agree that this is not top priority.
> 

I'm not sure about what exactly this is... Can someone explain, please! :)

> > > 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.
> 

Well, even when you upgrade the kernel you have to reboot... So nothing terribly
new for people! ;) 

> > > 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...
> 

Sorry, I don't know what vmtools is, and I'm not sure about what you mean by
"Life without xend", can someone explain a bit more, please?

Splitting the hypervisor and the tools would be useful... Only issue, we cannot
call the package xen-tools, as there is already a xen-tools (unless that changes
to xen-debian-tools or something, or gets integrated here, or...)

Guido