[ovirt-users] Re: [Qemu-block] Libvirt ERROR cannot access backing file after importing VM from OpenStack

On Wed, May 30, 2018 at 6:33 PM, Kevin Wolf <kwolf(a)redhat.com&gt; wrote: > I think the problem is that we're talking about two different things in > one thread. If I understand correctly, what oVirt does today is: > > 1. qemu-img convert to create a temporary qcow2 image that merges the > whole backing chain in a single file > > 2. tar to create an temporary OVA archive that contains, amongst others, > the temporary qcow2 image. This is a second temporary file. > > 3. Stream this temporary OVA archive over HTTP > Well, today we suggest users to mount a shared storage to multiple hosts that reside in different oVirt/RHV deployments so they could export VMs/templates as OVAs to that shared storage and import these OVAs from the shared storage to a destination deployment. This process involves only #1 and #2. The technique you proposed earlier for writing disks directly into an OVA, assuming that the target size can be retrieved with 'qemu-img measure', sounds like a nice approach to accelerate this process. I think we should really consider doing that if that's as easy as it sounds.

> You added another host into the mix, which just receives the image > content via NBD and then re-exports it as HTTP. Does this host actually > exist or is it the same host where the original images are located? > > Because if you stay local for this step, there is no need to use NBD at > all: > > $ ./qemu-img measure -O qcow2 ~/images/hd.img > required size: 67436544 > fully allocated size: 67436544 > $ ./qemu-img create -f file /tmp/test.qcow2 67436544 > Formatting '/tmp/test.qcow2', fmt=file size=67436544 > $ ./qemu-img convert -n --target-image-opts ~/images/hd.img > driver=raw,file.driver=file,file.filename=/tmp/test.qcow2,offset=65536 > > hexdump verifies that this does the expected thing.

But #3 is definitely something we are interested in because we expect the next step to be exporting the OVAs to a remote instance of Glance that serves as a shared repository for the different deployments. Being able to stream the collapsed form of a volume chain without writing anything to the storage device would be fantastic. I think that even at the expense of iterating the chain twice - once to map the structure of the jump tables (right?) and once to stream the whole data.