WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] XenU installs

Hi Tim,

I'll leave discussion of your ideas for other mails, but I just wanted to 
clarify what I was thinking of:

> As for strapping guests "ready to rock with LAMP" , debootstrap does the
> best job on the most different platforms in my experience. rpmstrap is
> broken (or was last I checked) because nobody has updated the rpm list
> since centos 3 / fc *2* I believe?
>
> If you really want to be able to configure any os from any os for a
> paravirt guest, you need some kind of meta package ' Rosetta stone '. I
> can't say that one doesn't exist, but I've yet to find one that includes
> all popular distros.

Well, the Rosetta Stone package is exactly the kind of thing I'd like to 
eliminate here.  Obviously for legacy guests that are already out there it 
might be nice to have something like this.  However, it doesn't seem scalable 
for the dom0 system to always understand what we're installing in guests.

A nice simple way to get this working would be for everyone to supply a 
grub.conf that pygrub can grok, then folks can just choose the "install Xen" 
option from the menu.  However, not everybody uses grub, and possibly it 
doesn't suit their needs.  Lets take the idea of a CD-ROM config file a bit 
further, then...

I guess what I'm proposing is _logically_ a "package format" for encapsulating 
an OS distribution installer.  A kind of "Xen package format".  This doesn't 
have to literally involve a new kind of package, but the kind of simplicity 
I'd be looking for is: any distro that has a Xenified kernel can support the 
XenInstall Spec and will easy to install, in a uniform way on any Xen host.

To me the obvious way to accomplish this would be to have some sort 
of "xen-metainfo.xml" file that compliant install CDs feature at a well-known 
path such as "xen/xen-metainfo.xml".  This file would specify the location of 
a Xenified kernel, and an initrd that can load the installer proper.  This 
would support the mode of installation current RH guests support - if you can 
*find* the Xen install kernel and initrd, then anaconda will appear for you 
and make the install friendly.

More generally, such a metadata file could also specify:
* boot time options that need to be passed to the kernel
<bootargs>
        <arg>install</arg>
        <arg>initrd</arg>
</bootargs>

* user configurable boot time options
<user-bootargs>
        <arg values="framebuffer|vnc|text|auto">installmode</arg>
        <arg>installserver</arg>
</user-bootargs>

* different kernel "modes" available (e.g. are kernels available for install 
on x86_32, x86_32p, x86_64) so that Xen can start the right one in order to 
kick off the install
<kernels>
        <kernel>
                <name>Linux 2.6.18 32-bit/PAE domU</name>
                <path>path/to/image</path>
                <capable>x86_32p</capable>
                <capable>SMP</capable>
        </kernel>
</kernels>

* how the distro expects devices to be setup (e.g. does this install require a 
network device, can it do DHCP?)
<devices>
        <required>
                ...
        </required>
        <supported>
                ...
        </supported>
</devices>


A config file like this would facilitate an install process more like:

---
# xm guest-install ~/debian-install.iso
Looking for Xen/x86_32p kernel... found
Select installation mode "[framebuffer/vnc/text/auto]": _
Starting guest operating system...
---

This way nobody has to have a detailed understanding of how other 
distributions structure their install CDs.  The key point is that the CDs 
would be *self describing*.  Everyone can still use their own preferred 
installation methods, so long as they supply enough information to tell Xen 
how to get started.

This same information could be leveraged by the Xen Enterprise tools, 
virt-manager, Yast, etc.  In general, perhaps it would be possible to have 
a "virt-info.xml" that contains details of lguest support, KVM paravirtual 
support etc.

I wonder if there would be any distributor interest in something like this...?  
If so, I'd be happy to put together a more detailed proposal we could argue 
about on xen-devel.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

<Prev in Thread] Current Thread [Next in Thread>