From: Michael Paesold <mpaesold@gmx.at>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
Ewan Mellor <ewan@xensource.com>
Subject: Re: Deficiencies in guest bootloader design
Date: Thu, 13 Apr 2006 20:09:20 +0200 [thread overview]
Message-ID: <443E93D0.3050607@gmx.at> (raw)
In-Reply-To: <443E6D3C.3080802@us.ibm.com>
Anthony Liguori wrote:
> Ewan Mellor wrote:
>> On Thu, Apr 13, 2006 at 04:29:23PM +0200, Michael Paesold wrote:
>>
>>> I have tried to use a dynamically activated block device with pygrub
>>> (actually drbd, but could be enbd, nbd, or simply any vbd other than
>>> phy: or file:). That does not work.
...
>>> Is there anyone working on bootloader improvements? If not, is a
>>> change to move the bootloader stuff from xm to Xend acceptable? In
>>> that case I could try to come up with a patch.
>>>
>>
>> Certainly such a patch would be accepted.
>
> Just as a warning, it's not going to be simple to run something like
> pygrub from Xend. The reason it runs from xm now is that it needs to
> interact with the user. If it were launched from Xend, it need to find
> a way to attach to a PTY that xenconsoled would use so that it can
> display the text over the normal console before actually launching the
> domain.
>
> It's certainly not impossible but it touches quite a few things.
Thanks for that important hint. Hmm, output of pygrub is only really
important in the case when xm create is called with -c. In that case the
console must be setup anyway, but I guess that this only happens after at
least part of the guest initialization.
<digression>
After reading through past discussion, I have a feeling that porting real
boot loaders to xen (e.g. grub) would be a better long term solution.
Just for booting linux, pygrub is really ok, and I prefer it over
domUloader because it relies on existing infrastructure in domU (menu.lst)
to get the correct kernel to boot ("yum update" inside domU will do the
right thing once grub configuration is setup correctly).
On the other hand pygrub only handles ext2/3 and reiserfs, so booting a bsd
guest won't work easily.
</digression>
Best Regards,
Michael Paesold
next prev parent reply other threads:[~2006-04-13 18:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-13 14:29 Deficiencies in guest bootloader design Michael Paesold
2006-04-13 14:34 ` Matt Ayres
2006-04-13 17:28 ` Michael Paesold
2006-04-13 15:10 ` Ewan Mellor
2006-04-13 15:24 ` Anthony Liguori
2006-04-13 15:36 ` Ewan Mellor
2006-04-13 15:40 ` Anthony Liguori
2006-04-13 18:09 ` Michael Paesold [this message]
2006-04-13 17:13 ` Michael Paesold
2006-04-13 19:19 ` Michael Paesold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=443E93D0.3050607@gmx.at \
--to=mpaesold@gmx.at \
--cc=aliguori@us.ibm.com \
--cc=ewan@xensource.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.