[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?