[Libguestfs] building a supermin appliance with febootstrap...

[Kashyap Chamarthy]

On 08/17/2011 05:32 PM, Richard W.M. Jones wrote:
> On Wed, Aug 17, 2011 at 04:50:17PM +0530, Kashyap Chamarthy wrote:
>> Ok, so , If I have to build appliance which has a bunch of %post,
>> %preun, %postun, %pre operations in it's RPM SPEC file, I need to
>> pull all of those into a custom init script(like the one for
>> libguestfs[1]), so that the guest kernel can detect this(run it as
>> PID 1) and sanely bring up the rest of the system ?
>
> Yes, you're gonna need an /init file anyway.
>
> Another unfortunate thing about Fedora is that the base RPMs like
> "filesystem-*.rpm" don't contain all the base files.  If you look at
> the source for mock, anaconda and so on, you'll see some code to
> create the base system.  For example:
>
> https://fedorahosted.org/mock/browser/py/mock/backend.py#L385
>
> Naturally this duplicated code is slightly different in each program
> where it appears.
>
> So your /init file should probably create some basic filesystem and
> device nodes as in the mock example above, then include any bits from
> the %pre/%post scripts that look important, and then jump to whichever
> init system you want (eg. /sbin/init which in newer Fedora is a link
> to systemd).

Thanks Rich, for this great detail. I haven't played much with mock, apart from building a 
couple of packages(I understand that everything is done in 'chroot'). I need to take a 
closer look at mock source and play around more a little bit.
>
>> And then I need to invoke 'febootstrap-supermin-helper' like below to build the appliance.
>>
>> # febootstrap-supermin-helper -f ext2 supermin.d x86_64 kernel initrd appliance.
>>
>> Where appliance is the file system.  As of now, other file systems
>> like ext3/ext4(maybe btrfs in future) are not yet available ?
>
> It would be very simple to modify febootstrap to support ext3 and/or
> ext4.  (btrfs would definitely NOT be a simple change).  In libguestfs
> the appliance is added read-only with a disposable overlay on top.
> Thus journals (a data integrity feature) don't make any sense for us.

If it's trivial to add newest ext* fs, that's nice. For projects we'd like to build 
appliances, there will be decent I/O ( maybe the newest available journaling FS may help..)
>
> http://git.annexia.org/?p=libguestfs.git;a=blob;f=src/launch.c;h=e58add54362b7933ab28e023bff492462d8ceee0;hb=HEAD#l632
>
>> Question: After I build and boot the appliance, how about networking
>> inside it? Any pointers to that?
>
> You just need to pass the right parameters to qemu.  Assuming you are
> using a real init system, the network will be brought up automatically
> inside the guest when it detects the virtual hardware.

Ah, that makes sense, so using all the regular networking parameters to qemu would do the 
trick
>
> http://git.annexia.org/?p=libguestfs.git;a=blob;f=src/launch.c;h=e58add54362b7933ab28e023bff492462d8ceee0;hb=HEAD#l596
> Note also that you can overlay any extra files (eg. config files,
> programs) that you need in the appliance by dropping cpio files into
> the supermin.d directory.  Again, take a look at how libguestfs does it:
>
> http://git.annexia.org/?p=libguestfs.git;a=tree;f=appliance;hb=HEAD

Thanks again for all the detail.
>
> Rich.
>


-- 
/kashyap