search for: owns_disk

...ising behavior in the image transfer API - you create a disk, and start a transfer session with that disk. However once you started a the transfer, it owns the disk, and it will delete it in case of failures, so you don't need to delete it yourself. I guess you need something like h["owns_disk"] = True After creating the disk, and once the transfer was started, set it to False. In your cleanup flow, delete the disk only if you still own it. The other issue here is that the error during close is hiding the real error. This is a common problem in python 2, and the solution is typica...

On Mon, Mar 18, 2019 at 06:51:26PM +0200, Daniel Erez wrote: > After invoking transfer_service.finalize, check operation > status by examining DiskStatus. > This is done instead of failing after a predefined timeout > regardless the status. > > * not verified * > > Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1680361 > --- > v2v/rhv-upload-plugin.py | 19

...; + # Otherwise if we did fail then we should delete the disk. > + else: > + disk_service = h['disk_service'] > + disk_service.remove() > This should be done only if we created the disk - is this always the case? Maybe to make ths more robust, set a h["owns_disk"] flag when creating the disk, and delete only in this case? Nir > + > + connection.close() > diff --git a/v2v/rhv-upload-precheck.py b/v2v/rhv-upload-precheck.py > new file mode 100644 > index 000000000..e3fa65148 > --- /dev/null > +++ b/v2v/rhv-upload-precheck.py &...

v5 was here: https://www.redhat.com/archives/libguestfs/2018-March/msg00032.html There is only a single patch in this version because the other patches went upstream. This patch adds the virt-v2v -o rhv-upload mode (https://bugzilla.redhat.com/show_bug.cgi?id=1557273). Compared to v5, this adds the ability to make zero, trim and flush requests to the oVirt imageio server