[Fedora-livecd-list] PATCH: Disk (appliance) creator tool

[Daniel P. Berrange]

On Thu, Feb 21, 2008 at 01:57:08AM +0000, Daniel P. Berrange wrote:
> On Wed, Feb 20, 2008 at 08:01:32PM -0500, Jeremy Katz wrote:
> > On Tue, 2008-02-19 at 19:16 +0000, Daniel P. Berrange wrote:
> > > > > from its kickstart recipe.  Currently developers building the appliance have to
> > > > > boot a VM using the F8 boot.iso and run the kickstart script in the VM and so
> > > > > on. While this works, involves many steps with potential for failure. This new
> > > > > tool reduces the problem to simply
> > > > 
> > > > As opposed to virt-install --name ... ?  I'm not convinced there's a
> > > > huge gain in terms of number of places for failure :-/
> > > 
> > > You have to have a working virtualization stack & it takes more resource
> > > overhead than just doing the chroot'd build. Emprically the part of our
> > > build process doing the guest based installs has been less reliable than
> > > the livecd-creator part. Havinga  disk-creator will address that problem
> > 
> > You have to have a working virt stack to *use* virtualization or test
> > things.  I'm not sure that't eh argument to use.  And as far as
> > reliability, what bugs are you talking about?  livecd-creator has
> > managed to have lower numbers of bugs largely due to a) less
> > functionality and b) less users.  
> 
> The host you use virtualization on, is not neccessarily the same as the host
> you build your images on though. If people don't have hardware virt in their
> dev machine it can be beneficial to build images via this tool, in preference
> to use the very slow QEMU emulator. Even in they do have virtualization the
> CPU & particularly memory overhead of building in the host is reduced. One
> specific bug is that the disk image ends up with the hostname of the guest
> VM embedded in /etc/sysconfig/network & /etc/hosts. Another was that the user
> in question wanted to run the tool on a host without hardware virt support.

Some other examples of scenarios where you want to build appliance images but
do not have virtualization capabilities directly accessible.

 - Machines where the user's primary OS is running under an embedded hypervisor.
   QEMU is tolerable for booting an image to verify that it works, but building
   the image in QEMU is too slow to be practical.

 - Building images to deploy to a virtual machine hosted by an ISP, eg linode.com
   where you have either option of providing a pre-installed disk image, or using
   one the ISP built for you. 

 - The virtualization technology on your local machine may be different from the
   target machine. eg you can run VirtualBox on your deskop, but want to build
   Xen based images to deploy to Amazon's EC2 hosting environment.


Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|