[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]