Description of problem: When creating image transfer, engine report both transfer_url and proxy_url. We recommend to use transfer_url for best performance, but sometimes user need to transfer an image from a machine on another network that can access ovit-engine, but cannot access the hosts. This issue is solved now in ovirt ansible collection by trying to connect to transfer_url and falling back to proxy_url if transfer_url is not accessible[1]. This is easier to use and more robust, but it has to be implemented by all users of imageio API. Provide this feature in the client library, so upload, download, and backup work from any host without writing low level socket code. How to test this feature: 1. Transfer image when both host and proxy are accessible: The image transfer should use the host directly. Verify that proxy was not used by looking in the /var/log/ovirt-imageio/daemon.log in engine host. Can be verified by stopping ovirt-imageio service after creating the transfer, before calling imageio client, and starting it after the data transfer was done. 2. Transfer image when host is not accessible Run transfer script on a host which can access ovirt-engine, but cannot access the host. If creating such network configuration is not possible, block access to the host on the machine running the transfer program. The image transfer should succeed, using the proxy. Verify by inspecting /var/log/ovirt-imageio/daemon.log on both engine and host. [1] https://github.com/oVirt/ovirt-ansible-collection/pull/35/commits/7c90057b85d937c9ca81eb1f78f59fdba49cb9f4
Hi Nir, this is not entirely clear to me. Could you please describe the map of resources for such testing? We need two hosts (A + B). A is a part of engine setup and used as vdsm host, while B is not part of engine environment? A can communicate with Engine, but can not communicate with B? B can communicate with engine, but CAN NOT communicate with A? (In reply to Nir Soffer from comment #0) > How to test this feature: > > 1. Transfer image when both host and proxy are accessible: Meaning execute download_disk.py from host A without --use-proxy arg? > > The image transfer should use the host directly. Verify that proxy was > not used by looking in the /var/log/ovirt-imageio/daemon.log in engine > host. In that case, we shouldnt see any activity on deamon.log of the engine? > > Can be verified by stopping ovirt-imageio service after creating the > transfer, before calling imageio client, and starting it after the data > transfer was done. Should stop ovirt-imageio on host A?. what is the expected result after starting the service again? > > 2. Transfer image when host is not accessible > > Run transfer script on a host which can access ovirt-engine, but cannot > access the host. Meaning execute download_disk.py from host B without --use-proxy arg? In that case, the engine should switch to 'proxy', therefore it will select host A as the host for making the transfer? > > If creating such network configuration is not possible, block access to > the host on the machine running the transfer program. > > The image transfer should succeed, using the proxy. Verify by inspecting > /var/log/ovirt-imageio/daemon.log on both engine and host.
(In reply to Ilan Zuckerman from comment #1) > Hi Nir, this is not entirely clear to me. > Could you please describe the map of resources for such testing? > We need two hosts (A + B). A is a part of engine setup and used as vdsm > host, while B is not part of engine environment? > A can communicate with Engine, but can not communicate with B? > B can communicate with engine, but CAN NOT communicate with A? Here is example setup that works (my local testing setup); - Transfer host: (IP: 192.168.122.1) - Engine (NDS: engine IP: 192.168.122.10) - Host (DNS: host1 IP: 192.168.122.20) Add host to engine using its DNS name (host1), not IP address. > (In reply to Nir Soffer from comment #0) > > How to test this feature: > > > > 1. Transfer image when both host and proxy are accessible: > > Meaning execute download_disk.py from host A without --use-proxy arg? Run {upload,download}_disk.py on Transfer host. --use-proxy is not needed for testing this flow. > > The image transfer should use the host directly. Verify that proxy was > > not used by looking in the /var/log/ovirt-imageio/daemon.log in engine > > host. > > In that case, we shouldnt see any activity on deamon.log of the engine? Right, except adding the ticket to the proxy. Engine cannot know how you are going to transfer the image, so it always add ticket to both host and proxy. > > Can be verified by stopping ovirt-imageio service after creating the > > transfer, before calling imageio client, and starting it after the data > > transfer was done. > > Should stop ovirt-imageio on host A?. what is the expected result after > starting the service again? On engine, this proves that the upload/download did not use the proxy. > > 2. Transfer image when host is not accessible > > > > Run transfer script on a host which can access ovirt-engine, but cannot > > access the host. > > Meaning execute download_disk.py from host B without --use-proxy arg? > In that case, the engine should switch to 'proxy', therefore it will select > host A as the host for making the transfer? Meaning, make host1 inaccessible on transfer host. A simple way is to remove the DNS entry for host1 in the transfer host, using /etc/hosts, or add an entry to 127.0.0.1, so connecting to host1 will fail. When connecting to host1 fails, imageio client try to use the proxy url. In my setup, engine and hosts DNS is managed by /etc/hosts file in engine, host1, and transfer host. Commenting or removing entries is easy way to make a host inaccessible. For example: $ cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 # oVirt setup 192.168.122.10 engine 192.168.122.20 host1 192.168.122.21 host2 192.168.122.30 nfs1 But you can also use iptables to make host1 inaccessible. The real setup a user may have is two networks: - engine network - accessible to client host - hosts network - not accessible to client host Client is running the transfer scripts locally, so accessing host is not possible.
Is this testable on rhv-release-4.4.1-5-001.noarch Taking in consideration this error? "Failed to add image ticket to ovirt-imageio-proxy" https://bugzilla.redhat.com/show_bug.cgi?id=1851707
This bugzilla is included in oVirt 4.4.1 release, published on July 8th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.