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