similar to: [PATCH 00/18] rvh-upload: Various fixes and cleanups

Displaying 20 results from an estimated 3000 matches similar to: "[PATCH 00/18] rvh-upload: Various fixes and cleanups"

2019 Nov 18
15
[PATCH v2 00/11] rvh-upload: Various fixes and cleanups
This series extract oVirt SDK and imageio code to make it eaiser to follow the code and improve error handing in open() and close(). Tested with virt-v2v master. Changes since v1: - Rebase on merged patches from v1 - Fix regression introduced by "rhv-upload: Fix cleanup after errors" - Remove "rhv-upload: Try to remove disk on timeout" since it cannot succeed - Add more
2018 Jun 22
4
v2v: -o rhv-upload: Use Unix domain socket to access imageio (RHBZ#1588088).
v1 was here: https://www.redhat.com/archives/libguestfs/2018-June/msg00099.html v2: - Just fixes the two problems noted in the review of the previous version. Rich.
2018 Jun 21
6
v2v: -o rhv-upload: Use Unix domain socket to access imageio (RHBZ#1588088).
These two patches add support for using a Unix domain socket to directly access imageio in the case where imageio is running on the conversion host (usually that means virt-v2v is running on the RHV node and something else -- eg. CFME scripts -- arranges that the RHV node is the same one running imageio). Conversions in the normal case are not affected - they happen over TCP as usual. This was
2018 Apr 05
2
[PATCH v8] v2v: Add -o rhv-upload output mode (RHBZ#1557273).
v7 was here: https://www.redhat.com/archives/libguestfs/2018-March/msg00143.html Since then: - Earlier patches are now upstream. - The to-do list is moved from the commit message to the TODO file. - This version forces -of raw + -oa sparse and gives an error in any other mode. We intend to lift these restrictions later. - Tested against latest imageio which supports longer timeouts,
2018 Apr 10
2
[PATCH v9] v2v: Add -o rhv-upload output mode (RHBZ#1557273).
v8 was here: https://www.redhat.com/archives/libguestfs/2018-April/msg00022.html v8 -> v9: - Addresses the only feedback from Tomáš. Rich.
2019 Nov 19
5
[PATCH 0/2] rhv-upload: Complete refactoring
Fix NameError introduced by inocomplete change to extract create_transfer() by extracting cancel_transfer() function. Finally extract finallize_transfer() function, dealing with the poorly documented and over complicated oVirt SDK. Tested with: libguestfs-1.40.2-4.fc30.x86_64 nbdkit-1.12.8-1.fc30.x86_64 Tested flows: - Successful import - Error in close() - by injecting long sleep in vdsm
2018 Mar 21
2
[PATCH v6] v2v: Add -o rhv-upload output mode.
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
2018 Jun 26
2
[PATCH v3] v2v: -o rhv-upload: Use Unix domain socket to access imageio (RHBZ#1588088).
v2 was here: https://www.redhat.com/archives/libguestfs/2018-June/msg00109.html v3: - Added/fixed all suggestions from Nir in previous review. Q: I wasn't sure if we still need the "UnsupportedError" class so I left it in. Q: Does the Unix socket always have the same name? What happens if there's more than one transfer happening? I tested this both ways, and it worked both
2018 Mar 06
5
[PATCH v4 0/3] v2v: Add -o rhv-upload output mode.
Previous versions: v3: https://www.redhat.com/archives/libguestfs/2018-March/msg00000.html v2: https://www.redhat.com/archives/libguestfs/2018-February/msg00177.html v1: https://www.redhat.com/archives/libguestfs/2018-February/msg00139.html This completely rethinks the approach taken by the previous patches. Instead of trying to involve qemu's curl driver, this uses a small Python 3
2018 Mar 08
6
[PATCH v5 0/4] v2v: Add -o rhv-upload output mode.
Mainly minor fixes and code cleanups over the v4 patch. There are still several problems with this patch, but it is in a reviewable state, especially the Python code. Rich.
2018 Jun 26
2
Re: [PATCH v3] v2v: -o rhv-upload: Use Unix domain socket to access imageio (RHBZ#1588088).
On Tue, Jun 26, 2018 at 4:25 PM Richard W.M. Jones <rjones@redhat.com> wrote: > In the case where virt-v2v runs on the same server as the imageio > daemon that we are talking to, it may be possible to optimize access > using a Unix domain socket. > > This is only an optimization. If it fails or if we're not running on > the same server it will fall back to the usual
2020 Jan 10
7
[v2v PATCH 0/6] Various Python pycodestyle fixes
Fixes the majority of the pycodestyle issues in the Python scripts, and fix the existing test-v2v-python-syntax.sh to use pycodestyle to actually perform style checks. Pino Toscano (6): PEP 8: adapt whitespaces in lines PEP 8: move imports at the top PEP 8: adapt empty lines tests: find all the Python scripts for syntax checks -o rhv-upload: remove unused Python imports Revamp check
2018 Jun 29
2
[PATCH] v2v: rhv-upload-plugin: Remove unneeded auth
Old imageio proxy was using Authorization header for GET and PUT requests. Remove unneeded authorization when sending OPTIONS request. Remove unneeded duplicated comments about authorization for old imageio, and replace them with a comment when we set needs_auth. --- v2v/rhv-upload-plugin.py | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/v2v/rhv-upload-plugin.py
2018 Feb 27
5
[PATCH v2 0/3] v2v: Add -o rhv-upload output mode.
This patch set is still for discussion only. See 3/3 for the current list of problems. However this will upload an image to an oVirt or RHV server, although you must have absolutely the latest snapshot version of 4.2 for it to work. Rich.
2018 Mar 08
2
Re: [PATCH v5 4/4] v2v: Add -o rhv-upload output mode.
On Thu, Mar 8, 2018 at 11:37 AM Richard W.M. Jones <rjones@redhat.com> wrote: > PROBLEMS: > - Target cluster defaults to "Default". > - Using Insecure = True, is that bad? > - -of qcow2 does not work, with multiple problems > - Need to attach disks to VMs somehow > > This adds a new output mode to virt-v2v. virt-v2v -o rhv-upload > streams images
2018 Mar 24
4
Re: [PATCH v7 6/6] v2v: Add -o rhv-upload output mode (RHBZ#1557273).
On Thu, Mar 22, 2018 at 5:25 PM Richard W.M. Jones <rjones@redhat.com> wrote: > PROBLEMS: > - -of qcow2 does not work, with multiple problems > * needs to set NBD size to something larger than virtual size > How is this related to the actual file size specified when you create a disk? In block storage, qcow2 image is always on a thin provisioned disk, which in oVirt is a
2018 Mar 22
12
[PATCH v7 0/6] v2v: Add -o rhv-upload output mode (RHBZ#1557273).
v6 was here: https://www.redhat.com/archives/libguestfs/2018-March/msg00126.html This makes a number of significant changes: - Input and output options now use a uniform set of -io and -oo parameters. - For -o rhv-upload, we use ‘-oo rhv-cafile=/tmp/ca.pem’ etc. The ‘--rhv*’ options have been dropped. - Rearranges the documentation. - As before includes (untested) support for zero,
2018 Feb 22
11
[PATCH 0/5] v2v: Add -o rhv-upload output mode.
The first four patches are straightforward. The final patch adds the -o rhv-upload output mode. It is still spooling into a temporary file because I've had some trouble getting streaming conversions working. There are other problems as outlined in the commit message, so this patch is not ready for upstream but is good for discussion. Also I hit this, which I'm assuming for now will be
2018 Mar 01
7
[PATCH v3 0/6] v2v: Add -o rhv-upload output mode.
v2 -> v3: - Lots of code cleanups. - Documentation. However this is still spooling the file into a temporary before the upload. It turns out that fixing this is going to require a small change to qemu. Rich.
2019 Nov 21
1
Re: [PATCH 1/2] rhv-upload: Extract cancel_transfer() function
On Wed, Nov 20, 2019 at 1:19 AM Nir Soffer <nirsof@gmail.com> wrote: > > Extract a cancel_transfer() function, so we can cancel a transfer in > plugin handlers without keeping the transfer_service around. > > Fixes a NameError when starting a transfer fails: > > During handling of the above exception, another exception occurred: > > Traceback (most recent