Re: [Xen-users] XenU installs

[Nico Kadel-Garcia <nkadel@xxxxxxxxx>]

Daniel P. Berrange wrote:
> On Tue, Jun 05, 2007 at 10:22:46PM +0100, Nico Kadel-Garcia wrote:
>   
> > Daniel P. Berrange wrote:
> >     
> > > On Tue, Jun 05, 2007 at 06:38:34PM +0100, Mark Williamson wrote:
> > >  
> > >       
> > > > It'd be kinda nice if there were a standardised spec for "how to boot an 
> > > > ISO in a paravirt VM".  This would require some kind of agreement between 
> > > > the distributors to do things in a uniform way, but it would move us 
> > > > closer to a "just works" type setup - surely a good thing.  It seems 
> > > > relatively unfortunate for the install procedure for each paravirt guest 
> > > > to be slightly different so that the user or tools has to understand 
> > > > those differences.
> > > >    
> > > >         
> > > Paravirt-ops may (eventually) help here because removing the need for a
> > > small xen kernel. Our goal in Fedora is to continue working to make 
> > > paravirt
> > > boot & install process be more closely aligned to fullyvirt & baremetal. 
> > > This is why we do Fedora guest installs by booting anaconda (+ optional
> > > kickstart) instead of chroot installs, and why we default to using pygrub
> > > and keeping kernels inside the guest image, etc. All the tools already
> > > expect things to work in this way with bare metal & fullvirt, so having
> > > paravirt be different is just complicating things. PXE boot of paravirt
> > > is another thing we'd like to have too...
> > >  
> > >       
> > Is there any chance of integrating support for doing virt-manager 
> > installs on top of an *existing* domain, making sure it's shut down, 
> > then allowing the network boot to do upgrade or rescue procedures on it?
> >     
> I've never really thought about that. In theory it could be doable, not
> sure how hairy an actual implementation would get though. A better approach
> may be just allowing more flexiblity in reconfiguring existing guest
> hardware in the UI. eg, allowing you to add a CDROM device to an existing
> guest & then changing the default BIOS boot device. We're sort of half
> way towards being able todo the latter at the moment.
>   
The para-virt installation procedure, at least on RHEL 5, does not use a 
local CDROM or DVD. It uses a network repository. Using a CD might be 
nice for a rescue operation, but the FC or RHEL style installation media 
support the very useful "rescue" option, which is my friend and would be 
useful for people like me, who sometimes have to seriously arrange 
system architectures..
I don't see a theoretical problem, just disabling the the safety check 
that stops the procedure  if the domain already has a config file: If an 
/etx/xen/[DOMNAME] file exists, instead of failing, simply provide the 
option of booting with the settings of the already existing file and set 
*NO* other options except those necessary for the network boot. I'm not 
sure if you would need to parse the existing domain file, or simply add 
options to do this: I don't understand libvirt well enough to say.
Does that make sense? If you point out the right bugzilla or Wiki to me, 
I'd be happy to put it in as a feature request.
The "linux rescue" option is really, really my friend, as is the "pre" 
option. I use it laying OS tarballs on top of existing hardware and 
chrooting into them to do updates, feature reconfigurations, etc. And 
I've deployed roughly...... 20,000 servers using that kind of tool, over 
the last 6 years.



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