RE: [Xen-devel] [PATCH] Guest boot loader support [1/2]

[Jeremy Katz <katzj@xxxxxxxxxx>]

On Thu, 2005-04-14 at 20:21 +0100, Ian Pratt wrote:
> > > Yep, it would be much better if we could hide this all in xend. 
> > > Ideally, it should be possible to start a domain, then 
> > connect to its 
> > > console within the bootloader's timeout and be able to 
> > interact with it.
> > 
> > If the console code is changing around, though, hooking up to 
> > the current stuff might be more trouble than its worth.  
> > Would be better in the long run, though.
> 
> I think Rik may have volunteered to take a look at the console stuff :-)
> 
> I actually think this is worth implementing right now, as it sets a key
> requirement for the new console stuff -- it must be possible to steal a
> guest console and inject a bootloader session. We might want something
> similar in future for a gdb session too.

The problem is that implementing it on top of the current console stuff
is going to be a little bit grotesque.  As it stands right now, I don't
see any obvious way of doing it other than some sort of hijacking of the
TCP socket.
  
> > > > - need to be able to configure the kernel to boot in the 
> > domain config
> > > >    when not using a console.
> > > 
> > > This would certainly be nice.
> > 
> > Already there, just change your default in the config.
> 
> Just to make sure, you mean the VM config, not the grub config, right?
> Do you specify the label name, or the crappy grub menu number?

Ooooohhhh (light bulb goes off here).  Right now, the default comes from
the grub.conf in the domU.  If you want to change the default from the
vm config, it's easy enough to add.  It could even be flexible enough to
let you specify the label name or the menu number.  

But before doing it, what's the use case in mind?  In general, I don't
think that's something you want to hardcode in the VM config -- I guess
I could see specifying it on the xm create command line, but just am not
100% sure what that buys you over having the interface pop up.

Jeremy


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel