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

Thu Feb 21 01:57:08 UTC 2008

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:
> > On Tue, Feb 19, 2008 at 01:58:46PM -0500, Jeremy Katz wrote:
> > > On Sun, 2008-02-17 at 02:14 +0000, Daniel P. Berrange wrote:
> > > > This patch adds support for another installation variant. The livecd-creator
> > > > produces ISO images which boot using syslinux. The image-creator creates a
> > > > single file containing a filesystem in which the OS is installated. This patch
> > > > adds a new disk-creator, which creates a single file containing a partitioned
> > > > disk with potentially many filesystems in which the OS is installed. Furthermore
> > > > it installs grub in the boot sector, so this image is immediately bootable in
> > > > a virtual machine.
> > > 
> > > Seems reasonable enough and it's something I had started looking at.  My
> > > biggest concerns end up being scope... the next thing someone will want
> > > to add is RAID.  Or LVM.  Or dm-crypt.  And I sort of wonder where it
> > > ends.  I already gets bugs on one copy of code like that and it's called
> > > anaconda ;-)
> > 
> > Where to draw the line is an interesting question. If you consider the created
> > appliance as primary serving for deployment in virtual machines, then I'd
> > argue that RAID / crypt is out of scope. They would be a site-specific deployment
> > question. If an admin wants encryption they can set it up in the host directly.
> > Likewise RAID can be done in the host already so its redundant for guests.
> 
> The admin of the virtual machine isn't necessarily the admin of the
> host, though.  At which point encryption, at least, becomes relevant.
> 
> > LVM would be useful if only to make adding storage to the appliance easier.
> > 
> > So I'd declare that scope is limited to plain partitions + LVM.
> 
> Others could well argue differently, though, is my point.  And
> especially when you're already saying that LVM is desirable, I start to
> lean towards really think that this is the wrong approach.

Sure, you can say the same thing about the liveCD creator too, saying it ought
to support X, Y & Z. One could argue that the live CD creator should just be
a regular anaconda install in a VM, with a simple shell script to turn the 
resulting installed VM disk image into an ISO. We can say the scope of the 
live-creator is to only ever install an ext3 FS inside a squashfs inside an ISO.
Similarly we can say the scope of this tool is to do a partitioned disk + LVM.
Any more complex disk setup can be done in the host, or re-configured post
install.   Or they can use the live CD creator APIs to create custom subclasses
to implement whatever setup they desire.

> > > > I've used this tool to create an instance of the oVirt web management appliance
> > > > 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.

> > > > With the background information out of the way, here's some info about the
> > > > changes in this patch...
> > > 
> > > Ob-side-note: your patch doesn't seem to be against master or at least,
> > > is missing some bits as it doesn't want to apply.  
> > 
> > I used a fresh git checkout from saturday for doing all the work against
> > and don't see any changes since then.
> 
> Are you sure it's diff'd against master and not something earlier of
> yours?  As it doesn't include all of imgcreate/disk.py and you created
> it.

I'll re-post it tomorrow - I've split the refactoring out from the new code to
make it clearer to understand.

> > > > Aside from partitioning, DiskImageCreator will setup an fstab file containing
> > > > entries for all the filesystems and swap space. It will add the grub device
> > > > map file, and create a grub.cfg based off the installed kernel. It is able
> > > > to cope with a layout where grub config is on /, or a separate /boot partition.
> > > > We can't use grub-install since it doesn't understand loopdevices, so to do
> > > > the MBR install we invoke grub manually.
> > > 
> > > Yeah, and this can be tricky.  At least historically, there have been
> > > cases which setup wasn't sufficient for and we had to do the full
> > > install invocation.  Which is why that's what anaconda does.
> > 
> > On the flip side anaconda has a much broader use case than we have to worry
> > about for creating appliances. Looking at the final grub commands that
> > grub-install actually runs, there's nothing magic we can't do directly. The
> > problem with grub-install is all the 'sanity' checking & probing it does 
> > before actually running grub, which simply doesn't apply to loop devices.
> 
> By install, I didn't mean grub-install, I meant running the
> (lower-level) install command from the grub shell.  We really should be
> sure to have as much consistency as we can here

Ah ok - there's a mis-communication here - it doesn't use the lower level
'install' command - it uses the high level 'setup' command. Explicitly the
commands run are:

   device (hd0) /dev/loop0
   root (hd0,0)
   setup --stage2=/path/to/chroot/boot/grub/stage2 --prefix=/boot/grub (hd0)

Which is identical to the set of commands that grub-install would run if
it were clever enough to deal with loop devices.

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  -=| 