OK!
Thanks for the info, we will discuss how to deal with this first (maybe just
bump the disk size)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1970896
Title:
uvt-simplestreams-libvirt in
Hi Po-Hsu Lin,
Sorry, there's also a decompression step. The relevant code is:
https://git.launchpad.net/uvtool/tree/uvtool/libvirt/__init__.py#n45
It's possible this could be optimized if libvirt's API has had any
enhancements since I wrote that code. It looks like I did it this way
because I
Hi Robie,
thanks for the reply,
It make sense to require twice of the image size as per the verification
requirement, however it looks like in this case it's using more than two
times of it.
The image is just around 600M, so it should be just 600M in /tmp and
600M more in libvirt after it's been
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
When you run this `uvt-simplestreams-libvirt sync` command, I noticed there
will be two files created in /tmp:
-rw--- 1 root root 575M Apr 29 09:23 tmpf17tglw6
-rw--- 1 root root 1.4G Apr 29 09:23 tmpi4lq8p24
After that, it will start writing image file in
** Also affects: uvtool (Ubuntu)
Importance: Undecided
Status: New
** Tags added: sru-20220418 ubuntu-kvm-smoke
** Tags removed: ubuntu-kvm-smoke
** Tags added: 5.15 aws jammy ubuntu-kvm-smoke-test
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
