> Dominik Csapak <d.csa...@proxmox.com> hat am 17.04.2024 16:07 CEST
> geschrieben:
> On 4/17/24 15:52, Fabian Grünbichler wrote:
> > On April 17, 2024 3:10 pm, Dominik Csapak wrote:
> >> On 4/17/24 14:45, Fabian Grünbichler wrote:
> >>> On April 16, 2024 3:18 pm, Dominik Csapak wrote:
> >>>> +sub cleanup_extracted_image {
> >>>
> >>> same for this?
> >>>
> >>>> + my ($source) = @_;
> >>>> +
> >>>> + if ($source =~ m|^(/.+/\.tmp_[0-9]+_[0-9]+)/[^/]+$|) {
> >>>> + my $tmpdir = $1;
> >>>> +
> >>>> + unlink $source or $! == ENOENT or die "removing image $source
> >>>> failed: $!\n";
> >>>> + rmdir $tmpdir or $! == ENOENT or die "removing tmpdir $tmpdir
> >>>> failed: $!\n";
> >>>> + } else {
> >>>> + die "invalid extraced image path '$source'\n";
> >>>
> >>> nit: typo
> >>>
> >>> these are also not discoverable if the error handling in qemu-server
> >>> failed for some reason.. might be a source of unwanted space
> >>> consumption..
> >>
> >> any suggestions for better handling that cleanup?
> >> we could put it at the beginning of each cleanup step, that should
> >> at least make sure we cleaned up the temporary images
> >
> > we could extract them into images/XXX/vm-XXX-disk-.. directly (or
> > rename/move them there after extraction), that way at least they could
> > be cleaned up via the storage API or rescan + delete (and via a regular
> > vdisk_free in qemu-server, instead of requiring a special helper).
> >
> > other than that, I don't think we have an easy way of
> > - exposing them in list & free_image
> > - while ensuring nobody deletes them while the import is still going on
> > (the target VM ownership checks ensure that at least via the UI if we
> > make it an owned volume)
> >
> > it would also allow skipping the conversion if the storage+format
> > already match the target spec as well..
>
> mhmm that could work, but what if the storage does not have
> the 'images' content type enabled? should we simply fail then?
right, that would make it a bit limiting. we could clear the tmpdir on reboots?
;)
it might also be nice (as a follow-up?) to make the tmpdir configurable and/or
see what limitations direct streaming actually has (other than live-import not
working) - because if the OVA is on NFS/.. right now we incur a lot of back and
forth copying..
I wonder if live-import even makes much sense here - if I have to copy/extract
the disks anyway before starting the live-import (which then does another
copy), I can just as well do a regular import and start the VM afterwards,
especially if that saves me one copy action?
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
