Comment 2 for bug 1970896

Hi,

In uvtool this is by design. It has to download the entire image before it can cryptographically verify it, and only then does it start injecting the image into libvirt. It does that using libvirt's socket API. Using that mechanism, I don't think it's possible to do a filesystem-level move to economize on disk usage.

I suppose it might be possible to do one of a couple of things:

1) Have some kind of "--insecure" flag and code that opportunistically skips the /tmp step in this case, streaming the download directly into libvirt. However this is more code to maintain for a very special case, and the error path cleanup at the libvirt of a failed download would also have to be checked and handled as needed.

2) Arrange to do a filesystem-level move instead of using libvirt's API. However this would break users who have more complicated setups, so there'd again have to be more code to maintain to special case the default case.

Since this behaviour is by design in uvtool, it isn't a bug per se, so I'll mark it accordingly. If you want to write and merge one of the above options, please could you explain why this is important for uvtool? Requiring twice the image size to be available in disk space seems reasonable to me.