[xen-tools-dev] Status

Nathan O'Sullivan nathan at mammoth.com.au
Mon Jun 7 08:53:20 CEST 2010


Replying to list after checking with Dmitry he meant to email the list:

On 07/06/10 08:45, Dmitry Nedospasov wrote:
> On 6.6.10 23:36, Nathan O'Sullivan wrote:
>    
>> I've also committed some changes yesterday to support OpenSUSE 11.2
>> along with the xen-tools hook directory.  I guess one potential issue
>> with Kickstart is it seems Suse do not support it, and instead have
>> something called "AutoYaST" instead.
>>      
> Hmm, but atleast OpenSUSE/SLES provides xen images to install "domUs".
> Thats primarily the idea i had behind what I'm calling kickstart, as
> this is done via kickstart on RHEL/CentOS. Again the idea was to script
> unattended installations for systems for which we don't have something
> similar to debootstrap.
>
> One advantage I saw personally, is that many larger organizations run
> RHEL, and I think that xen-tools would appeal to them if it could
> install RHEL well and CentOS as its derivative.
>    
I guess that gets to the core of why someone wants to use xen-tools.

Personally, I started using it as a way to build minimal operating 
system images that I can archive and duplicate, and most the 
Xen-specific parts (like writing configuration files) are useless to me. 
I realise I'm in the minority though (surely?).

debootstrap / rinse + xen-tools is great for me because of the minimal 
images it makes.

>    
>> For those who aren't familiar with Rinse - its main problem is it
>> downloads and extracts a bunch of packages (from a list stored in a
>> rinse configuration) directly via rpm, which has two impacts:
>> - the yum database is unaware that any packages have been installed, and
>> - this download-and-extract process doesn't respect dependencies known
>> by yum either.
>>
>> Due to the dependency issue, each new OS release you have to update the
>> package list with maybe 5 new packages, to add any new library
>> dependencies of yum itself.
>>
>> The badness here is that you can/will end up with some packages that are
>> on-disk, but not known by yum to be "installed", so "yum update" will
>> not install new versions as they're released. This can be worked around
>> to some degree by installing a few common packages with yum (such as yum
>> itself), which will trigger quite large dependency chains and pull in a
>> good hundred or so basic packages.
>>      
> Hmm, thanks for this investigation, i might pull your branch and take a
> look... maybe using the techniques that febootstrap uses (its just a yum
> wrapper) to improve on the code that we already have.
>
> I still see a problem in lack of manpower to cover this... rinse needs
> atleast one active dev and I'm not sure that any of us are willing to be
> that dev atm.
>    

I guess that depends what we consider wrong with it. I will continue to 
patch it to work with new releases of Centos/fedora/opensuse for the 
forseeable future, but I cant see myself fixing much else.

> What really surprises me is that Steve didn't do (and what i plan to do
> when i have more time) is abstract xen-tools and rinse to a point where
> it can install KVM vms, or in my case QEMU guests.
>    
That would certainly be useful to me personally; at the moment when 
xen-create-image is finished I mount its disk.img, make a tarball of its 
contents, and then delete everything xen-create-image did.
> Do we have rinse in a git somewhere? I'd have to begin reading the
> mercurial manual before I'd be able to check anything out from hg ;)
>    
I've imported it into gitorious over the weekend - 
http://gitorious.org/rinse/rinse

Regards
Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://xen-tools.org/pipermail/xen-tools-dev/attachments/20100607/b2b2b468/attachment.htm>


More information about the xen-tools-dev mailing list