Hi Benjamin,
This request comes up repeatedly and I keep turning it down. Consider
providing a PoC if you really want it.
The images created by debvm-create cannot be used for much beyond
passing them to debvm-run, because they do not contain a boot loader.
Thus the first step here would be making debvm-run support dealing with
qcow2 images. That in turn comes down to making debugfs (from e2fsprogs)
work with qcow2 images. That's beyond what I'm up to and I don't feel
like asking Ted Ts'o for implementing it. So as long as debugfs doesn't
do qcow2, I'll be turning down this kind of request.
Last time this came up, debefivm-create did not exist. That is different
now. Images created by debefivm-create can be run via debefivm-run, but
also have uses beyond. Still, I think that debefivm-run should be able
to handle images produced by debefivm-create and this comes down to
making fdisk work with qcow2 images. Again, I do not feell like asking
Karel Zak about implementing it. For that reason, I am also turning down
this one.
In both cases, there is a noticable performance penalty arising from the
conversion. debvm otherwise tries hard to minimize disk writes. Both
creation scripts create the image in-place and moving to qcow2 would be
a departure from that.
The lack of this feature also is not very problematic. You may just
invoke qemu-img after debvm. The loss of functionality is minimal here.
To the contrary, the explicit conversion makes it clear that the qcow2
image is not created in-place.
Bottom line, I am not going to work on this. The way to move this
forward is to provide ways around the fundamental issues listed here.
Helmut