Implement option vmtype to select between raw or qcow2 #182
Conversation
qcow2 is a growable format not taking so much space from the beginning.
Instead of creating a raw image and converting it to qcow2 with
`qemu-img convert`
$ qemu-img convert -f raw -O qcow2 debian.img debian.qcow2
add a switch `--vmtype` allowing to specify the type of the virtual
machine file, which is used in `qemu-img create -f`.
It looks like though, installing the system into that file using NBD is
twice as slow.
$ sudo ~/src/grml-debootstrap/grml-debootstrap --arch amd64 --release sid --filesystem ext4 --vmfile
There was a problem hiding this comment.
I'm not yet convinced that we should support this from within grml-debootstrap, tbh. :)
You write:
It looks like though, installing the system into that file using NBD is twice as slow.
So what's the actual reason, to not install it into raw format as-is, and then convert to the format as needed?
Also all the qemu-nbd actions around /dev/nbd0 seem to ask for trouble AFAICS, what about e.g. if the device is used elsewhere already? :-/
(Not commenting on other code changes themselves yet)
I only came up with this, because on the “build machine” you do not always have 100 GB of free space for the raw image.
Yes, I have to figure out – the same with kpartx – how to get the correct device. |
| eend $? | ||
| else | ||
| einfo "Removing loopback mount of file ${ORIG_TARGET}." | ||
| qemu-nbd -d /dev/nbd0 | ||
| fi | ||
| eend $? | ||
| fi |
There was a problem hiding this comment.
@paulmenzel Just a quick question: you moved eend $?. Any reason for not keeping it at the end?
There was a problem hiding this comment.
Thank you. That’s an oversight no my part.
No description provided.