Tag Archives: febootstrap
It depends on the number of other PCI devices that you are exporting to the guest. In the current implementation each virtio-blk disk is a separate PCI device (although Anthony pointed out that you can create multifunction PCI devices which let you break this limit in some narrow circumstances).
How many other PCI devices are you likely to have? Run
lspci in a guest to see. Probably you have a host bridge, an ISA bridge for all your legacy devices, a network card, a VGA adapter, a USB controller, an emulated PIIX4 and a memory balloon. That’s 7 devices, and we haven’t even got to disks yet.
PCI is limited to 32 devices in total. So 25 or so virtio block devices is the maximum you would be able to add to a real guest without accepting limitations on things like hotplugging which you would get if you used multifunction devices. (libguestfs is limited to 25 disks but for other reasons to do with limits in febootstrap).
Work is proceeding to remove this limit.
Firstly we create a supermin appliance containing a few packages and their dependencies. Note that I’m not minimizing this appliance so it’s a bit bigger (3.1MB!) than the ones we would generate in reality:
$ mkdir supermin.d $ febootstrap --names 'bash' 'coreutils' -o supermin.d febootstrap: warning: some host files are unreadable by non-root febootstrap: warning: get your distro to fix these files: /sbin/unix_update /usr/libexec/pt_chown /usr/sbin/build-locale-archive /usr/sbin/glibc_post_upgrade.x86_64 /usr/sbin/tzdata-update $ ls -lh supermin.d/ total 3.1M -rw-rw-r--. 1 rjones rjones 2.7M Dec 10 18:23 base.img -rw-rw-r--. 1 rjones rjones 462K Dec 10 18:23 hostfiles
The purpose of these two files is explained in the febootstrap documentation.
This won’t boot without a /init script, and we can easily provide one:
$ cat init #!/bin/bash - echo Welcome to my world bash -i $ chmod +x init $ echo init | cpio -o -H newc --quiet > supermin.d/init.img
The 3 files in supermin.d/ are a supermin appliance, and could be packaged up in a Fedora, Debian or Ubuntu package.
When you actually want to come and launch this appliance, you use febootstrap-supermin-helper to reconstruct the appliance:
$ febootstrap-supermin-helper -f ext2 supermin.d x86_64 \ kernel initrd root
(Note that “kernel”, “initrd” and “root” are output files in that command)
You’d usually arrange for those files to be cached, since febootstrap-supermin-helper takes a few seconds to run (8 seconds on my laptop) and by caching it you can get reconstruction time down to a fraction of a second.
Now to boot, run qemu or qemu-kvm like this:
$ qemu-kvm -kernel kernel -initrd initrd -hda root
After a few seconds you’ll get to the shell:
Up to date Debian packages (*.deb) for libguestfs are now available:
Please read the README file first.
$ time guestfish -a /dev/null run : supported augeas yes inotify yes linuxfsuuid yes linuxmodules yes linuxxattrs yes luks yes lvm2 yes mknod yes ntfs3g yes ntfsprogs yes realpath yes scrub yes selinux yes xz yes zerofree yes real 0m17.335s user 0m16.061s sys 0m0.608s
Note that time is running Debian inside a virtual machine. On native hardware with KVM that command should run much more quickly.
Note: This requires libguestfs ≥ 1.4
files/ is a directory containing some files, you can create a new disk image populated with those files using the command below (virt-make-fs can also be used for this):
$ guestfish -N fs:ext2:400M -m /dev/sda1 tar-in <(tar -C files/ -cf - .) /
guestfish -N fs:ext2:400Mcreates a prepared disk image which is 400MB in size with a single partition formatted as ext2. The new disk image is called
-m /dev/sda1mounts the new filesystem when guestfish starts up.
tar-in [...] /uploads and unpacks the tar file into the root directory of the mounted disk image.
<(tar -C files/ -cf - .)is a bash process substitution which runs the tar command and supplies the output (ie. the tar file) as the input on the command line.
This is a quick way to create “appliances” using febootstrap and libguestfs, although you should note that I don’t think these appliances would really work, I just use them for testing our virtualization management tools, like the ability to detect and manage disk images:
$ febootstrap -i fedora-release -i bash -i setup -i coreutils fedora-13 f13 $ echo '/dev/sda1 / ext2 defaults 1 1' > fstab $ febootstrap-install f13 fstab /etc 0644 root.root $ febootstrap-minimize f13 $ guestfish -N fs:ext2:40M -m /dev/sda1 tar-in <(tar -C f13 -cf - .) / $ guestfish --ro -i -a test1.img Welcome to guestfish, the libguestfs filesystem interactive shell for editing virtual machine filesystems. Type: 'help' for a list of commands 'man' to read the manual 'quit' to quit the shell Operating system: Fedora release 13 (Goddard) /dev/vda1 mounted on / ><fs> cat /etc/fstab /dev/sda1 / ext2 defaults 1 1
KageSenshi’s HOWTO use Linux Containers (LXC) on Fedora 12 with libvirt is interesting. I discovered that they’re using febootstrap (see earlier postings) to build the Fedora root filesystem for the containers.
Q: Can you fit a bootable Fedora distribution into 100 kilobytes?
A: You bet!*
* by cheating … read on.
Take an ordinary Fedora appliance as made by febootstrap or appliance-creator. The appliance image is big because it contains copies of programs (
/bin/bash) and libraries (
/lib/libc.so), the kernel and kernel modules. It needs to, to make it self-contained.
But a technique we’ve been using for a few months in libguestfs is to say: we’re booting this appliance on a Fedora host. Let’s strip out all those programs and libraries from the appliance, and we’ll add them back from the host just before we launch it.
I called such appliances “supermin appliances”, and now I’ve ported the functionality from libguestfs into febootstrap so everyone can use it.
A supermin appliance is really small:
-rw-rw-r-- 1 rjones rjones 14K 2009-10-22 12:43 hostfiles.txt -rw-rw-r-- 1 rjones rjones 87K 2009-10-22 12:43 supermin.img
yet it’s fully bootable, given the right sort of host:
It’s really easy to use the new febootstrap to make your own super-small supermin appliances.
We’ll start with this small shell script to make a supermin appliance:
#!/bin/sh - distro=rawhide febootstrap -i bash -i coreutils $distro fedora febootstrap-minimize fedora cat > init <<EOF #!/bin/sh echo Starting /init script ... PATH=/sbin:/usr/sbin:$PATH touch /etc/fstab mount -t proc /proc /proc mount -t sysfs /sys /sys exec bash -i EOF febootstrap-install fedora init /init 0755 root.root rm init # Create the supermin appliance. febootstrap-to-supermin fedora supermin.img hostfiles.txt # Create the ordinary appliance just for comparison. febootstrap-to-initramfs fedora > ordinary.img
You will need to use febootstrap >= 2.5, and set the
distro variable so it exactly matches your base Fedora system (eg. set
The script below can be used to boot the appliance, and it’s what I used to get the screenshot above.
#!/bin/sh - time febootstrap-supermin-helper \ supermin.img hostfiles.txt kernel initrd qemu-system-x86_64 -m 1024 -kernel kernel -initrd initrd
Nearly available anyway. It’s still being uploaded.
So now you can make Fedora filesystems, images, initramfs, appliances, virtual machines etc. on a Debian host.