Am 26.03.25 um 12:57 schrieb Dominik Csapak: > 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. >> > > actually thinking of renaming, i don't think that's necessary to do in > the backend at all > since the client will provide a target filename, we can just rename it > in the ui > to '.raw' for the user? > > then we'd also not have to have a list of 'raw' formats on the backend > at all?
Sounds good to me :) _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
