Description of problem: imageio daemon and proxy do not support ipv6. We need to support setup when engine and hosts have only ipv6 address. Known issues: - daemon and proxy listen only to ipv4 - sending request to daemon using ipv6 url fails in requests library - NBD ipv6 URLs are not supported in the daemon - There are no tests using ipv6, so we don't know yet what needs to change
as per discussion with Nir, the behavior should be as follows: Remote port - accessed by users - Listen on "::" by default (like vdsm). Supports both ipv4 and ipv6 in the same time. - Admin can override the address to ipv4 or ipv6 address. In this case listen to the requested address (does not support both ipv6 and ipv4) - Users should resolve host and connect to the first address that works (like socket.create_connection()) Control socket - accessed only by engine - Listen to the first interface resolved for "localhost". Can be ipv6 or ipv4 based on system configuration - Client need to connect the first working address reported by getaddrinfo() (like socket.create_connection())
(In reply to Vojtech Juranek from comment #2) Peter, can you ack the solution described in comment 2?
Moving bug to 4.4. We need to clone to 4.3 if we really need to add this also in 4.3.
Hi Vojtech, Can you please provide a clear verification scenario?
(In reply to Avihai from comment #7) > Hi Vojtech, > > Can you please provide a clear verification scenario? upload and download image on IPv4 and/or dual stack environment (to verify there's no regression) and same on IPv6-only environment to verify image upload/download works with IPv6 only.
To sum up: IPv6 upload/download via SDK does not work due to bug 1856085 which seems like an SDK issue. This bug cannot be verified fully until the SDK issue is fixed and is neither a regression nor a blocker bug it will not be fixed in 4.4.1(4.4 GA). Retargeting this bug to 4.4.2 for now (feel free to change it if you think it will be fixed sooner)
Created attachment 1700736 [details] Logs
I'm not sure this bug depends on bug 1856085. imageio can be installed on engine and hosts using ipv4, dual-stack, and ipv6 only, and Vojta already tested upload and download in the environment provided by network team. We don't know what is issue in bug 1856085. It may be some configuration issue on the host, or issue in ovirt-engine-sdk, but this does not prevent users from using imageio API. The upload_disk.py/download_disk.py are just convenience, users do not have to use the SDK. I think we can verify this bug since we have a bug for the sdk issue.
bug 1856085 is not a bug, the tested environment cannot work. We don't have any requirements in this RFE, and the testing instructions in comment 8 are not very detailed. If I understand correctly this feature, this should be tested like this: Setup needs at least 3 hosts: 1. external host - this host is not part of the RHV setup. run upload_disk.py/download_disk.py here to test remote image transfer (use case: backup/restore) 2. engine 3. hypervisor - run upload_disk.py/download_disk.py here to test local image transfer (use case: virt-v2v). We have 3 test cases: 1. ipv4/dual-stack system: all hosts use ipv4 address. hypervisor is added to engine using its ipv4 address or DNS name resolving to ipv4 address. The purpose of the tests is to make sure there are no regressions. 2. ipv6/dual-stack system: all hosts use ipv6 address. hypervisor is added to engine using its ipv6 address or DNS name resolving to ipv6 address. The purpose of this test is to test new functionality. 3. ipv6 only system: all hosts use ipv6 address. hypervisor is added to engine using its ipv6 address or DNS name resolving to ipv6 address. The purpose of this test is to test new functionality. For each test case we need to tests: - remote upload and download (running on external host) - local upload and download (running on hypervisor) - upload/download from UI (running a browser in the same network) Note: do not test image transfer over the web. This is not the intended use case. image transfers should be used in the same LAN. Please consult the network team on how to setup the environment, or maybe used a pre-configured environment that network team already have.
Current status: * Tested with NFS only. * ipv4/dual-stack system - UI + sdk from hypervisor - upload and download work as expected. * One IPv6 only hypervisor - UI + sdk from this hypervisor - upload and download work as expected.
After talking to Vojtech, decided on the following verification steps: 1) Dual Stack One dual host up (spm) Another dual host and IPv6-only host are in maintenance. Local Transfer - Connect only dual stack host to the engine to make sure this will be the serving the image. - Test download/upload image from this host using python-sdk. ---> Download & Upload are working as expected. Remote Transfer - Same as in Local Transfer but download/upload is initiated from another dual stack host. ---> Download & Upload are working as expected. 2) IPv6 only One IPV6 only host up (spm) Other two hosts, which are dual, are in maintenance. Local Transfer - Connect only IPv6-only host to the engine to make sure this will be serving the image. - Test download/upload image from this host. ---> Download & Upload are working as expected. Remote transfer - Same as in Local Transfer, but download/upload is initiated from another IPv6-only host. ---> Download & Upload are working as expected. Verified on ovirt-imageio-2.0.9-1.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (RHV Engine and Host Common Packages 4.4.z [ovirt-4.4.2]), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:3820