[mwcampbell]

As I get some pleasure out of writing scripts to build finely tuned minimal images like this, I found the article interesting. However, I think manipulating a qcow2 image directly via nbd is over-complicating it. I think it would be better to create a sparse file, mount that via a loopback device, work with that, and then convert it to a qcow2 image (or vmdk or whatever) at the end.

[elevation]

.qcow2 files have two main advantages when building system images compared to a loopback device.

First, when building a system image with make, it works best to have each step result in a separate image file so that make can rebuild your image when a dependency changes without having to completely start over. Using .qcow2 images means that only the diffs are stored in each image file, instead of having a dozen 4GB .bin files.

Second, because the loopback device requires root by default, you end up running "sudo make" as part of your build process. But with .vmdk or .qcow2 files, tools like libguestfs can mount the filesystem for manipulation without root. If you're planning to distribute your work, then "git clone && cd project && make" is more accessible directing your users to modify their user permissions or elevating to root.

[regularfry]

When I've done this sort of thing in the past, the ability to work with a set of staged partial images was a very mixed blessing. It ended up being over-complicated and rarely taken advantage of. I've settled on local package repositories and a single image build step which compiles everything together.

The latter problem you describe, that of needing to be root, goes away if you don't use a loopback device but instead use a mountable filesystem image. `truncate -d1G os.img && mkfs.ext3 os.img && mount os.img mountpoint/` doesn't need root at any point.

[eatonphil]

Aren't these images typically built on designated build machines anyway? Sure you've got to develop it locally. But the majority of developer-consumers will get it from some distributor fed from a build machine.

The diffing is still a great point. I did not know that about qcow2 images. Do you have any articles then on incremental builds with .qcow2 images?

[vidarh]

I'm not convinced that you're saving anything by avoiding nbd. You need to modprobe nbd and start qemu-nbd. Both single commands that you can cut and paste. What you gain is not having to convert an image at the end.

[eatonphil]

I am with mwcampbell. There's something to say for the minimalism/lack of dependencies - even if it is not much more complex to use nbd. You don't need qemu to create a sparse file, mount it as a loopback device and manipulate it as a new device from there. If someone needs a qcow2 file afterward, fine. But that doesn't /need/ to be involved in the build step.