Re: [pve-devel] [PATCH storage/qemu-server/pve-manager] implement ova/ovf import for directory type storages
On April 18, 2024 12:35 pm, 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@pve8a1 ~ # cat B >> secret >> root@pve8a1 ~ # tar cf arch.tar A B dir >> root@pve8a1 ~ # losetup --offset 1536 --sizelimit 512 --read-only --show -f >> arch.tar >> /dev/loop0 >> root@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. there are a few projects that basically offer "tar browsing via FUSE" in some fashion, not sure about their overhead and/or compat with various tar variants and features though.. ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH storage/qemu-server/pve-manager] implement ova/ovf import for directory type storages
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@pve8a1 ~ # cat B >>> secret >>> root@pve8a1 ~ # tar cf arch.tar A B dir >>> root@pve8a1 ~ # losetup --offset 1536 --sizelimit 512 --read-only >>> --show -f arch.tar >>> /dev/loop0 >>> root@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 > ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH storage/qemu-server/pve-manager] implement ova/ovf import for directory type storages
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@pve8a1 ~ # cat B secret root@pve8a1 ~ # tar cf arch.tar A B dir root@pve8a1 ~ # losetup --offset 1536 --sizelimit 512 --read-only --show -f arch.tar /dev/loop0 root@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 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) 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 ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH storage/qemu-server/pve-manager] implement ova/ovf import for directory type storages
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@pve8a1 ~ # cat B > secret > root@pve8a1 ~ # tar cf arch.tar A B dir > root@pve8a1 ~ # losetup --offset 1536 --sizelimit 512 --read-only --show -f > arch.tar > /dev/loop0 > root@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. ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH storage/qemu-server/pve-manager] implement ova/ovf import for directory type storages
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) for placing the extract code, i'd strongly prefer the (future) PVE::GuestImport namespace in pve-storage, as that does not pollute the plugin api with irrelevant stuff and is relatively far away from qemu-server (so we could reuse it later for other things if we need to) as for the extraction/cleanup step: i'll reuse the 'images' part of the storage to extract it there with a valid vm disk name. that way if the cleanup fails, it can be deleted from the ui at least if the storage does not have an images content type or the user does not have the relevant privileges, i'd force the user to provide (with a new parameter for creating) a file based storage with content type images. that can be shown in the gui only for ova imports. (and would default to the import storage if possible) i think that were all the "big" questions for this series, please do tell if i forgot something ;) if no one objects to these things (or has even better ideas to solve some of these), i'd get started on that ASAP ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH storage/qemu-server/pve-manager] implement ova/ovf import for directory type storages
> Dominik Csapak hat am 17.04.2024 15:19 CEST > geschrieben: > On 4/17/24 15:11, Fabian Grünbichler wrote: > > On April 16, 2024 3:18 pm, Dominik Csapak wrote: > >> This series enables importing ova/ovf from directory based storages, > >> inclusive upload/download via the webui (ova only). > >> > >> It also improves the ovf importer by parsing the ostype, nics, bootorder > >> (and firmware from vmware exported files). > >> > >> I currently opted to move the OVF.pm to pve-storage, since there is no > >> real other place where we could put it. Building a seperate package > >> from qemu-servers git repo would also not be ideal, since we still > >> have a cyclic dev dependency then > >> (If someone has a better idea how to handle that, please do tell, and > >> i can do that in a v2) > >> > >> There are surely some wrinkles left i did not think of, but all in all, > >> it should be pretty usable. E.g. i downloaded some ovas, uploaded them > >> on my cephfs in my virtual cluster, and successfully imported that with > >> live-import. > >> > >> The biggest caveat when importing from ovas is that we have to > >> temporarily extract the disk images. I opted for doing that into the > >> import storage, but if we have a better idea where to put that, i can > >> implement it in a v2 (or as a follow up). For example, we could add a > >> new 'tmpdir' parameter to the create call and use that for extractig. > > > > something is wrong with the permissions, since the import images are not > > added to check_volume_access, I can now upload an OVA, but not see it > > afterwards ;) > > > > I guess if a user has upload rights for improt images > > (Datastore.AllocateTemplate), they should also be able to see and use > > (and remove) import images? > > > > ah yes, i forgot to add it there. > > but FWICS isos can have the same problem? > upload only requires 'Datastore.AllocateTemplate' but seeing them requires > 'Datastore.AllocateSpace' or 'Datastore.Audit' > > is that a mistake? that's a slightly less problematic variant of a similar issue, yes. Datastore.AllocateSpace and Datastore.Audit are the "weaker cousins" of Datastore.AllocateTemplate, in most configurations if you have the latter you'll also have (one of) the former. IMHO it wouldn't hurt to allow Datastore.AllocateTemplate users access to iso files (and container templates), since they can upload them the behaviour is weird as it is. for the OVA files right now you'd need Datastore.Allocate, which is a higher privilege than those others. I guess treating OVA files like iso and templates w.r.t. ACLs kind of makes sense, even if they have a slightly bigger attack surface behind the scenes. this would also allow just giving trusted admins the option to upload new OVAs, while allowing users to create VMs based on that trusted set. ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH storage/qemu-server/pve-manager] implement ova/ovf import for directory type storages
On 4/17/24 15:11, Fabian Grünbichler wrote: On April 16, 2024 3:18 pm, Dominik Csapak wrote: This series enables importing ova/ovf from directory based storages, inclusive upload/download via the webui (ova only). It also improves the ovf importer by parsing the ostype, nics, bootorder (and firmware from vmware exported files). I currently opted to move the OVF.pm to pve-storage, since there is no real other place where we could put it. Building a seperate package from qemu-servers git repo would also not be ideal, since we still have a cyclic dev dependency then (If someone has a better idea how to handle that, please do tell, and i can do that in a v2) There are surely some wrinkles left i did not think of, but all in all, it should be pretty usable. E.g. i downloaded some ovas, uploaded them on my cephfs in my virtual cluster, and successfully imported that with live-import. The biggest caveat when importing from ovas is that we have to temporarily extract the disk images. I opted for doing that into the import storage, but if we have a better idea where to put that, i can implement it in a v2 (or as a follow up). For example, we could add a new 'tmpdir' parameter to the create call and use that for extractig. something is wrong with the permissions, since the import images are not added to check_volume_access, I can now upload an OVA, but not see it afterwards ;) I guess if a user has upload rights for improt images (Datastore.AllocateTemplate), they should also be able to see and use (and remove) import images? ah yes, i forgot to add it there. but FWICS isos can have the same problem? upload only requires 'Datastore.AllocateTemplate' but seeing them requires 'Datastore.AllocateSpace' or 'Datastore.Audit' is that a mistake? ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] [PATCH storage/qemu-server/pve-manager] implement ova/ovf import for directory type storages
On April 16, 2024 3:18 pm, Dominik Csapak wrote: > This series enables importing ova/ovf from directory based storages, > inclusive upload/download via the webui (ova only). > > It also improves the ovf importer by parsing the ostype, nics, bootorder > (and firmware from vmware exported files). > > I currently opted to move the OVF.pm to pve-storage, since there is no > real other place where we could put it. Building a seperate package > from qemu-servers git repo would also not be ideal, since we still > have a cyclic dev dependency then > (If someone has a better idea how to handle that, please do tell, and > i can do that in a v2) > > There are surely some wrinkles left i did not think of, but all in all, > it should be pretty usable. E.g. i downloaded some ovas, uploaded them > on my cephfs in my virtual cluster, and successfully imported that with > live-import. > > The biggest caveat when importing from ovas is that we have to > temporarily extract the disk images. I opted for doing that into the > import storage, but if we have a better idea where to put that, i can > implement it in a v2 (or as a follow up). For example, we could add a > new 'tmpdir' parameter to the create call and use that for extractig. something is wrong with the permissions, since the import images are not added to check_volume_access, I can now upload an OVA, but not see it afterwards ;) I guess if a user has upload rights for improt images (Datastore.AllocateTemplate), they should also be able to see and use (and remove) import images? ___ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
