On Tue, Jul 10, 2007 at 11:37:52AM +0200, Henning Sprang wrote:
> Axel Thimm wrote:
>
> > Actually I found the cause and I strongly disagree with the above:
>
> With which part exactly? (You cited two statements)
Well, if you hadn't trimmed them I would be able to tell, in doubt
both.
> > The reason the domU was blocking was because it didn't have enough
> > memory in the default setup. Once the memory limits were increased
> > it worked fine.
>
> I think, this is an issue of the Redhat Xen installer(I assume you are
> not trying to manually run anaconda somehow but use virt-install), not
> Xen in general.
>
> Why?
> 1) this problem never occured to me with xen-tools on Debian and Yast on
> SuSE
>
> 2) Sure, a user has always the chance to make wrong settings and break
> stuff, but in your case, the writers of the Redhat Xen install scripts
> should know how much memory is needed by their anaconda.
>
> So, it is undoubtedly easy to check for them at the very start, and at
> least give out a visible warning that you try to run the stuff with not
> enough memory, instead of let you run into a strange blocking state.
> ( In case I missed you writing you found the fix through such a warning,
> I admit you that point!)
I think you sound a bit biased against the Red Hat tools. There is no
special xen treatment in anaconda other than supplying a xen
kernel. And the issue I raised is not solved by blaimg distro A vs
distro X. The issue is
"How do I find out why xen blocks a guest? What kind of IO
state is the system waiting on? How can I debug this further?"
For the example at hand this is solved, but what happens when tomorrow
someone comes by and says that the FAI installer is stalled in "b"
state and he has no idea on how to diagnose further xen's behaviour?
Lecture on how good other distros install?
--
Axel.Thimm at ATrpms.net
pgpatWNa2kjZa.pgp
Description: PGP signature
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home