[Libguestfs] Plans for changing libguestfs appliance building

[Daniel P. Berrange]

On Mon, Aug 16, 2010 at 01:46:13PM +0100, Richard W.M. Jones wrote:
> 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).

I don't know the internals of libguestfs that well, but is filtering
out a harddisk really more trouble than filtering out a CDROM ?
Any IDE/SATA CDROM device will appear as /dev/[hsv]d[a-z] too, even
if it has a /dev/cdrom link. So AFAICT you need todo the same kind
of filtering for either disks or cdroms, and you loose 1 drive letter
in both cases :-(

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|