Control: tags -1 + wontfix Hi Gioele,
On Wed, Feb 01, 2023 at 11:07:25PM +0100, Gioele Barabucci wrote: > The current output of `debvm-create` is a file containing an ext4 partition. > In order to run the VM a tool like `debvm-run` is needed. > > It would be nice if there were a tool in the `debvm` family that could turn > that partition into a complete disk (with a bootloader, etc) stored in a > `qcow2` image, so that it could be run with a simple: > > kvm vm.qcow2 As much as I'd like that kind of ease of use. I don't think this is feasible in a sane way. Quite fundamentally, just running kvm requires a bootloader to be installed inside the image. Bootloaders are quite architecture-specific, so debvm avoids them and leverages qemu as bootloader. An image created by debvm does not contain a bootloader nor partition table. Adding them retroactively is not a simple affair - much less architecture-generic. > (If the output of `debvm-create` were a tarball, creating an full-disk image > would be as easy as following the guestfish-based instructions in the > manpage of mmdebstrap.) guestfish is not a light-weight dependency and comes with a lot of non-trivial requirements. One of these requirements is being native-only as inherited from supermin. I think you are looking for a different tool here. For full disk images, the added complexity by mkosi or vagrant probably makes sense. I acknowledge that the image format used by debvm is not generic. That is part of its design compromise. In fact, the format is quite specific and thus documented in README.md. Also note that adding a mode where debvm would construct a tarball is not that helpful either. For instance, the image created parses the TERM variable from the kernel command line and inserts it into the serial console shell. This only works, because debvm-run passes TERM along. This is something a direct kvm invocation cannot do. There is a reason that debvm wraps both mmdebstrap and qemu rather than just one of them. Helmut
