Am 29.05.2018 um 11:27 hat Richard W.M. Jones geschrieben:
On Mon, May 28, 2018 at 01:27:21PM +0300, Arik Hadas wrote:
Let me demonstrate briefly the flow for OVA: Let's say that we have a VM that is based on a template and has one disk and one snapshot, so its volume-chain would be: T -> S -> V (V is the volume the VM writes to, S is the backing file of V and T is the backing file of S). When exporting that VM to an OVA file we want the produced tar file to be comprised of: (1) OVF configuration (2) single disk volume (preferably qcow).
So we need to collapse T, S, V into a single volume. Sure, we can do 'qemu-img convert'. That's what we do now in oVirt 4.2: (a) qemu-img convert produces a 'temporary' collapsed volume (b) make a tar file of the OVf configuration and that 'temporary' volume (c) delete the temporary volume
But the fact that we produce that 'temporary' volume obviously slows down the entire operation. It would be much better if we could "open" a stream that we can read from the 'collapsed' form of that chain and stream it directly into the appropriate tar file entry, without extra writes to the storage device.
A custom nbdkit plugin is possible here. In fact it's almost possible using the existing nbdkit-tar-plugin[1], except that it doesn't support resizing the tarball so you'd need a way to predict the size of the final qcow2 file.
I think you can predict the size with 'qemu-img measure'. But how do you create a tar archive that contains an empty file of the right size without actually processing and writing gigabytes of zero bytes? Is there an existing tool that can do that or would you have to write your own?
The main difficulty for modifying nbdkit-tar-plugin is working out how to resize tar files. If you can do that then it's likely just a few lines of code.
This sounds impossible to do when the tar archive needs to stay consistent at all times. Kevin