Re: [Libguestfs] Plans for changing libguestfs appliance building

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).