[Libguestfs] Plans for changing libguestfs appliance building

[Richard W.M. Jones]

On Mon, Aug 16, 2010 at 07:21:12PM +0800, Jin Xin Zheng wrote:
> On 08/16/2010 06:40 PM, Richard W.M. Jones wrote:
> >On Mon, Aug 16, 2010 at 10:17:30AM +0800, Jin Xin Zheng wrote:
> >>The virtual cdrom device in qemu will be readonly (is that right?).
> >>
> >>Then how are you going to tune the boot process as I know it would
> >>require writing to the filesystem.
> >I'm not aware of us needing to write to the root filesystem during
> >boot (well, there is one place where we do 'mkdir -p /sysroot' but
> >that can be fixed).
> >
> >However there is an issue that we modify configuration files in the
> >daemon, in particular /etc/lvm/lvm.conf, which would require either
> >making this directory a tmpfs or using some other method to make root
> >writable.
> >
> >Rich.
> >
> Are you sure all the binary utils inside the appliance will not write
> logging files when running?

I guess we can mount /tmp, /var and maybe a few other things as tmpfs?

> In fact when I saw this the first thing came up to my head was that our
> modified source for doing gcov -- we could collect the .gcda files in
> the build directory after libguestfs was invoked. But the guestfsd which
> runs inside the appliance produces the .gcda files in the temp ramfs.
> We have made a pretty lot of effort in order to tar-out these files
> before the subprocess was killed.
> 
> If the filesystem is readonly then I'll have to do more to allow guestfsd
> to write debugging coverage info into a writable place. However this is
> not a problem for libguestfs, it's just a problem for me...

The alternative is to use a regular drive (not a CD), and attach it
using:

 -drive file=isofile,snapshot=on

Since this will be one of the drives, it has two disadvantages: we
need to work a little bit harder to hide this drive from users, and it
reduces the number of drives available to users from 26 to 25
(assuming drives can only be named /dev/[hsv]d[a-z], which is true of a
lot of daemon code at the moment).

Live CDs use another method: They create a device mapper writable
snapshot over the filesystem, allowing you to write to the normally
read-only CD.  I don't think this will work for us since we have to be
extra careful not to use device mapper names, LVs etc which might
conflict with any on the user drives.  Although I've not thought this
through very much, so perhaps there is some way.

I think it's fair to say also that we're not switching away from
initrd because we want to.  It's because we are forced to ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora