[pve-devel] [PATCH storage/qemu-server/pve-manager] implement ova/ovf import for directory type storages

[Fiona Ebner]

Am 18.04.24 um 13:10 schrieb Dominik Csapak:
> On 4/18/24 12:35, Fiona Ebner wrote:
>> Am 18.04.24 um 11:27 schrieb Dominik Csapak:
>>> ok after a bit of thinking and discussing off-list
>>> the plan to go forward from my side is this:
>>>
>>> (please tell if there is something obviously wrong with it or you'd
>>> strongly prefer something differently)
>>>
>>> extract on demand vs on upload:
>>>   i'd go with extract on demand because managing the extraction of the
>>> tarball + subdir etc is not really a win in my book, since we have to
>>> have most safeguards anyway and we have the same
>>> issue of where to store/map it etc. also it's not convenient for users
>>> that have already
>>> a bunch of ovas and want to store them in a central place, now they'd
>>> have to extract
>>> them just for us (and importing should be as small a hassle as it can
>>> be)
>>>
>>
>> The upside is that it would avoid all the extra cleanup handling and be
>> more efficient for users that want to import from a single OVA multiple
>> times. But you are right, the downside is also very big.
>>
>> I'm thinking now, is there no way to expose a file in an OVA/tar without
>> actually extracting it? I.e. something like
>>
>>> root at pve8a1 ~ # cat B
>>> secret
>>> root at pve8a1 ~ # tar cf arch.tar A B dir
>>> root at pve8a1 ~ # losetup --offset 1536 --sizelimit 512 --read-only
>>> --show -f arch.tar
>>> /dev/loop0
>>> root at pve8a1 ~ # cat /dev/loop0
>>> secret
>>
>> but that doesn't seem to work with sizelimit < 512. Not claiming losetup
>> is a good mechanism for that, just to illustrate the idea.
> 
> 
> AFAIU that only works for uncompressed tars and ova can by definition
> be compressed, so that won't work reliably
> 

Okay, I didn't know that. Then it's not going to be nice and easy of course.

> there is archivemount[0], which can fuse mount archives
> 
> i tested that, and it's *very* slow for randomly accessing the files inside
> (i guess because it must seek much further back to get the compression
> state correct)
> 

Yes, makes sense.

> i tested a qemu-img convert from such a file and it took >10 minutes
> for a file that would normally be extracted + converted in under a minute
> 
> 0: https://github.com/cybernoid/archivemount
>