[Pkg-xen-devel] Current status

[Ralph Passgang]

Am Sonntag, 19. Februar 2006 10:58 schrieb Guido Trotter:
> On Sun, Feb 19, 2006 at 01:14:08AM -0800, Jeremy T. Bouse wrote:
[...]
> >     I think for now this is prolly the best course of action since we
> > can't provide any default kernels for dom0 or domU currently. I do think
> > for a complete solution to be able to be done out-of-the-box install we
> > will need atleast a basic dom0 in the archive eventually but that will
> > most likely mean dealing through -devel to get consensus and approval
> > first.
>
> Ok

For the most users it's enough to have one kernel that works for dom0 and 
domU's. That's also the default solution that other precompiled solutions 
offer and the way the xen community suggest to install a xen3 setup.

The only disadvantage that I see is, that the kernel are quite big, because of 
the modules for all the hardware, but domU's cannot really use them, because 
they have no real hw-access. But it's working very well this way and I also 
do this on the production servers at work where we sell virt. root servers 
with. It's easier to manage & maintain one kernel then a lot of diffrent 
ones.

at least for every xen release it's adviced to compile a new kernel, because 
the "patch" will most likely will have changed. for 3.0.x releases an older 
kernel should work on a newer hypervisor, but I guess no xen developer would 
guarantee this :)

If someone patches a vanilla 2.6.12 with our kernel-patch-xen it will also 
have a default .config that supplies all needed options for using it for 
dom0's and domU's. it includes more or less all possible modules/drivers and 
is "optimized" for -686 (pentium-pro).

> >     I think debianizing might be the best way to go. I think it will be
> > easier to manage for someone new but understands the standard
> > configuration usage within debian. That said I think it should be
> > attempted to maintain backwards compatibility if possible should we go
> > that route. As you said the current way interferes with the network
> > configuration and that isn't an ideal situation. As well there isn't
> > much documentation I could find for handling multiple NICs where only
> > one is used for domUs and the other is for dom0 only or even setting up
> > multiple NICs to be used.
>
> Ok, so still some more work to do... ;)

Yeah, it's not really the debian-way for now, but it could get complicated to 
get a really debian-compatible solution for the bridged, routed and NAT 
setup. the default is the bridged mode, which is probablly the easiest to 
setup.

at least (if we don't "debianize" it) we have to document how the user can 
setup a xen system for his needs.

> >     I had already thought about this myself, though I'd put it off till
> > we had packaging we were ready to upload. I have sent emails to Adam on
> > multiple occassions as well as through the BTS and have yet to receive
> > anything one way or the other. I know I'm not the only one that has
> > attempted to contact him as well. I'm certainly not the only one
> > frustrated with the lack of response.

I also tried to contact him since end of december / beginning of january, but 
haven't recieved any response. the last I have read was on the xen devel ml, 
were he reported that he is in progress of creating xen3 packages, but since 
then there was no other "lifesign" anymore.

> >     I was planning on one more attempt to contact Adam plus Cc'ing to
> > -devel expressing the intention to take over maintainership and give a
> > delay before it is uploaded. In fact I was going to suggest doing the
> > upload myself, so as to take any flak that might result from what would
> > essentially seem to appear like a hostile takeover to some possibly. I
> > would make use of the delayed upload [2] to automate the delay so we
> > wouldn't need to take further action once I upload the file it would be
> > released after the given number of days delay. I was figuring something
> > between 7-15 days delay to give Adam ample time to respond.
>
> Well, a mail to -devel now could be nice, and maybe also attract other
> contributors... Even if I think we tried to involve everybody who said he
> was interested... Also an announcement made through alioth could be useful:
> we want to have a consensus as large as possible...
>
> As for the upload you can of course do it, but you're not going to take the
> blame alone, if there will be any! We're all working on this, so both good
> and bad reactions should be considered by all of us!

I think we doing the right thing, because adam didn't answered at all and he 
also have not provided a package for the last xen2 release either, so the xen 
packages are bit like unmaintained right now. Also we are a team and open for 
everbody that seriously wants to contribute, so even adam could join in 
future.

> >     Well without doing anything to /lib/tls Xen itself should spit out a
> > warning message to the console, should the user bother to notice it. The
> > notice does describe the technic to move it out of the way and disable
> > it. We again should put this in a NEWS.Debian or README.Debian anyway if
> > we decide to go this route.
>
> I think it should go in README.Debian, as it's nothing new! ;)
>
> >     Another route might be to modify the init.d script to determine if
> > we are running under Xen and move the directory out of the way on
> > boot-up and move it back on shutdown. Not sure if we want to go this
> > route or not, but it would only affect the system while running under
> > Xen and leave it alone when running a standard kernel.
>
> Problems: what if there is both tls and tls.disabled from an older version
> of Xen? Anyway before doing this we must get permission from debian-policy
> and debian-devel!

I am against this! It even wrose then any of my hooks in the rules file ;-P

a) the init.d scripts are called right late, so there will be a warning 
already before tls is moved away by the xend/xendomains script.

b) if the user created the initrd for the kernel on a tls enabled system (a 
normal kernel for example), then he also will see this warning, even if there 
is no /lib/tls on his system when he boots his dom0 kernel. this confuses the 
user, so explaining how to deal with /lib/tls in a readme would help more.

c) this is not a solution for domU's, because they have no xen-related init 
scripts (or even one of our packages) installed at well.

We should write some documentation for that. There might be some other 
interessting points for domU systems that we should also mention, for 
example:

- because of the missing rtc-support in domU it's the best to remove the 
hwclock.sh and hwclock-first.sh script by using "update-rc.d".

- copy /lib/modules/<kernelvers.>-xen to the domU fs.

any maybe more.

If we really want a solution for the tls problem without having the user to 
take care of that, we should try it with special libc6 packages.

we could try to get the libc6 maintainers to have another libc6 package (for 
example called libc6-xen) that will provide the tls libraries compiled with a 
special switch, so that xen can life with it without loosing performance. 
That would be a good solution, because this would work without manipulating 
any directories and is supported by the libc6 guys. This would also work in 
any domU.

> > 	Other than that I can't think of anything else at this time. I believe
> > the 'installer' issue will be left as a wishlist item for the time being
> > as I think that it won't be practical until we can put the dom0/domU
> > kernels in the archive with atleast a base default configuration. The
> > idea of the 'installer', as I understand it from Yvette, is to be able to
> > do a Xen install from scratch. Just like how the new d-i just finally
> > started allowing MD and LVM on install I think this will take time once
> > things stablize and default kernels can be included. As well it would
> > entail making udeb's which could be added to d-i process. A bit more work
> > than we want right now until we get everything already on our plate dealt
> > with.
>
> Oh, so it was actually "integration with d-i"... Yeah, we definitely need
> to postpone it until kernel and tls are sorted out, at least!

right, it's great idea but to complicated for now.

with the packages that I provide currently (which also consist of a kernel 
image) I definitly don't need more then 10 minutes for the xen installation 
after a fresh debian sarge has been installed. it's as easy as adding the 
required line in apt's sources.list + one apt-get call + creating initrd + 
editing menu.lst...

There are also some good documentations available (written by others) that 
explains these steps really good. for example by steve kamp, but also from 
others. We could ask them if they want to write a documentation for the 
offical package? 

so what is really missing for our packages will be the kernel images. the 
integration in the d-i is nice-to-have, but not sooo important.

>
> Guido
>
> PS going to be mostly away for today! Have a good weekend!

you too ;-P

--Ralph