On Fri, 2026-06-26 at 06:29 +0200, Helmut Grohne wrote: > Control: tags -1 + wontfix > > Hi Benjamin, > > On Fri, Jun 26, 2026 at 12:43:34AM +0200, Benjamin Drung wrote: > > It would be nice if debefivm-create and debvm-create could create qcow2 > > images in addition to raw images, e.g. by calling > > > > qemu-img convert "$raw_image" -O qcow2 "$IMAGE" > > > > at the end. > > 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.
Thanks for the explanation. Since I am not the first one asking for it, how about extending the man page with that information (performance penalty, used tools would need to support it)? -- Benjamin Drung Debian & Ubuntu Developer

