similar to: Re: [ovirt-devel] [ARM64] Possiblity to support oVirt on ARM64

Hi, Any other comments for this topic? BR, Zhenyu On Mon, Jul 20, 2020 at 9:17 AM Zhenyu Zheng <zhengzhenyulixi@gmail.com> wrote: > Hi Nir, > > Thanks alot for the quick response and information, actually I also > worked a little bit on libvirt and other from our > team has experiences in qemu, those projects works OK on ARM platform, it > is just the capability might

Hi Nir, Thanks alot for the quick response and information, actually I also worked a little bit on libvirt and other from our team has experiences in qemu, those projects works OK on ARM platform, it is just the capability might be less when comparing to other platforms, for example, myself just added the getHost() capability for ARM64 in libvirt and now planning to work on compareCPU() API,

On Thu, Jul 9, 2020 at 4:12 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > On Thu, Jul 09, 2020 at 03:30:22PM +0300, Nir Soffer wrote: > > Testing with a real server is easy. I have incomplete patch using > > imageio server with some manual setup. > [...] > > For a certain definition of "easy" :-) > > Our QE team tests -o rhv-upload from time

This is mainly for testing the new parallel python threading model, but it also an example how to manage multiple connection from a plugin. I tested this with local imageio server, serving qcow2 image on local SSD. Start imageio server from imageio source: ./ovirt-imageio -c test Create test disk: qemu-img create -f qcow2 /var/tmp/disk.qcow2 6g Add ticket to accessing the image,

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

On Thu, Jul 9, 2020 at 10:53 AM Richard W.M. Jones <rjones@redhat.com> wrote: > > On Thu, Jul 09, 2020 at 01:51:44AM +0300, Nir Soffer wrote: > > We can use now ImageioClient to communicate with ovirt-imageio server > > on oVirt host. > > > > Using the client greatly simplifies the plugin, and enables new features > > like transparent proxy support. The

Add support for qcow2 disk format, enabled by imageio NBD backend in RHV 4.3. To use this feature manually, you can run virt-v2v with "-of qcow2". Here is example run: Source disk: $ qemu-img info /var/tmp/fedora-30.img image: /var/tmp/fedora-30.img file format: raw virtual size: 6 GiB (6442450944 bytes) disk size: 1.15 GiB virt-v2v: $ ./run virt-v2v \ -v \ -i disk

Hi Richard, We've added zero and flush functionality to imageio-daemon. You can download and test the latest build (for el7/fc) from: - http://jenkins.ovirt.org/job/ovirt-imageio_master_build-artifacts-el7-x86_64/200/artifact/exported-artifacts/ - http://jenkins.ovirt.org/job/ovirt-imageio_master_build-artifacts-fc27-x86_64/53/artifact/exported-artifacts/ -

Currently we handle only HTTP errors like getting unexpected response code from imageio server. However if we could not send the request, or some other error is raised, we failed to mark the handle as failed, and finalized the transfer in close(). This may fool virt-v2v to create a VM with an empty or partially uploaded disk. Decorate all the NBD hander functions with a @failing decorator,

On Tue, Aug 21, 2018 at 03:55:50PM +0300, Nir Soffer wrote: > On Tue, Aug 21, 2018 at 2:49 PM Richard W.M. Jones <rjones@redhat.com> > wrote: > > It seems more likely that whatever version of nbdkit being used does > > not include: > > > > > > https://github.com/libguestfs/nbdkit/commit/72c0d64a47db642cafa89884f2ee554bd0b8e822 > > > > This has

On Wed, Jul 22, 2020 at 04:29:15PM +0800, Zhenyu Zheng wrote: > Hi, > > Any other comments for this topic? libguestfs, nbdkit and virt-v2v have also worked (upstream) for years out of the box on aarch64, so there should be no problem there. If you're interested in RHV (ie. oVirt downstream on RHEL) then note we don't build virt-v2v for RHEL on aarch64. Virt-v2v is not very

These patches improve error handling when PUT request fail, including the error response from oVirt server. This will make it easier to debug issue when oVirt server logs have been rotated. Nir Soffer (2): v2v: rhv-upload-plugin: Handle send send failures v2v: rhv-upload-plugin: Fix error formatting v2v/rhv-upload-plugin.py | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7

This is actually not required, because ovirtsdk4 will use the system's global trust store if necessary. Therefore we can make it optional in all cases. --- docs/virt-v2v-output-rhv.pod | 5 ++++- v2v/output_rhv_upload.ml | 2 -- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/virt-v2v-output-rhv.pod b/docs/virt-v2v-output-rhv.pod index 04a894268..4520c9184 100644 ---

On Wed, Aug 05, 2020 at 04:49:04PM +0300, Nir Soffer wrote: > I see, can change the python plugin to support multiple connections to imageio > using SERIALIZE_REQUESTS? > > The GiL should not limit us since the GIL is released when you write to > imageio socket, and this is likely where the plugin spends most of the time. It's an interesting question and one I'd not really

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

http was missing in emulate_zero, so the code would fail with NameError. This can happen only when communicating with old imageio versions not supporting the "zero" feature. Testing with qemu-img 2.12 show that we never send emulated zero request because of the highestwrite mechanism, but it can break with older qemu-img-rhev used on RHEL. --- v2v/rhv-upload-plugin.py | 2 ++ 1 file

On Thu, Jun 14, 2018 at 09:24:48PM +0300, Nir Soffer wrote: > On Thu, Jun 14, 2018 at 9:16 PM Nir Soffer <nirsof@gmail.com> wrote: > > + headers = {"Content-Type": "application/json", > > + "Content-Length", str(len(buf))} There were a few Python syntax errors such as this one. They can be found by running: make -C v2v check

We can use now ImageioClient to communicate with ovirt-imageio server on oVirt host. Using the client greatly simplifies the plugin, and enables new features like transparent proxy support. The client will use transfer_url if possible, or fall back to proxy_url. Since the client implements the buffer protocol, move to version 2 of the API for more efficient pread(). Another advantage the client

We were not considering failures while initializing the transfer. In this case the transfer phase can change to PAUSED_SYSTEM or FINISHED_FAILURE, and transfer_url will be None, which failed the upload with a misleading error: RuntimeError: direct upload to host not supported, requires ovirt-engine >= 4.2 and only works when virt-v2v is run within the oVirt/RHV environment, eg. on

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