On 3/26/25 12:41, Fiona Ebner wrote:
Am 26.03.25 um 11:47 schrieb Dominik Csapak:
On 3/26/25 11:37, Fiona Ebner wrote:
Am 25.03.25 um 16:14 schrieb Dominik Csapak:
most of the building blocks are already there:
* we can have qcow2 files in an import storage
* we can import qcow2 files via the api from such a storage

this series fills in the missing bits & pieces:
* allow uploading qcow2 files into an import storage via the webgui
* adding the possibility to select such a file when creating a vm/disk

We could maybe also allow this for raw/vmdk if we want to, but IMHO
we can start out with qcow2 and add the others as necssary.

(if wanted, I can of course also add the others in a next version or as
a follow up)


Yes, please! It would be nice to have all three at the same time. Or is
there any specific reason why you limit it to qcow2? Otherwise, users
will just ask why support for these is missing right away.

No specific reason, it was just easier/quicker to implement one first.
When we also allow raw files,
should we also allow other extensions than '.raw'? not sure if there is
one that
is often used (since I think '.raw' is more a PVE thing)


Right, raw is actually a bit of a headache because of that :P

We could either:

1) have a list of common extensions for raw: .raw/.img/etc

1b) also treat files without extension as raw?

2) have a list of known extensions that are not raw and treat everything
else as raw, while logging an informational message

I'd prefer 1), because we already require specific extensions for other
uploads.

And likely we want to rename after/during upload, so images that are raw
for us always have a ".raw" extension? Otherwise, we need to be careful
enough to enforce the very same rules when parsing the import volume
name and thus mostly also have them set in stone for the future. The
advantage of the latter would be for the use case where one wants to
manually make accessible their already existing image folders without
using the API.


I'd also use a list (e.g. for now '.raw', '.img')

renaming is a good idea, but how should we do that? e.g.

foo.img -> foo.img.raw ?

because if we'd do foo.img -> foo.raw i think it's more likely
to get a collision than when we keep the .img in the name

what do you think?

Side note (can be done later; or not) do we want to support compressed files?
(gz, xz, etc.?) just noticed that e.g. the home assistant disk image is a
qcow2.xz file


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

Reply via email to