Hi, will dual-stack environments also be considered in this issue? Currently we have an environent which dual-stacked, but remote access to ovirt (over vpn) is limited to just IPv6; which means that, currently, I cannot access the VM's console (and, as mentioned here, I cannot change my display network to be only IPv6 as a workaround); however, when I'm on-site, I'd still like to be able to access this console over IPv4 as well.

(PS: hope I'm allowed to put these comments here, otherwise, if someone could point me in the right direction where these type of comments should go?)

The bug does not depend on gluster.

This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.

Verified on - 4.3.0.4-0.1.el7 and vdsm-4.30.7-1.el7ev

Display network and console is working over IPv6 only

I'm sorry, i verified this bug too soon. 

The only flow that is work is when adding host over IPv6 static and the display role is on ovirtmgmt.
But when trying to set another network(ipv6 only) with display role, engine still requires IPv4 
"Error while executing action: Cannot edit Network. IP address has to be set for the NIC that bears a role network. Network: display-net, Nic: em2.162 on host rose10.qa.lab.tlv.redhat.com violates that rule."


Based on that, this is failedQa

FailedQa

1. Open console over management network via IPv6 static address only - PASS
2. Switch display role from management network to a non-mgmt network(IPV6 static address) - PASS
3. Open console via the non-mgmt network IPv6 address - FAIL

It seems that even the xml is correct and graphics listening to the correct IPv6 address(non-mgmt network), engine still trying to open the console via the management network. The console.vv contains the wrong IPv6 address.

The third scenario fails because when the configuration of the display network is ipv6 on the host, vdsm does not report this network's displayIp in the VM.create verb, so engine defaults to try to connect the console on what vdsm reports as 'hostName' which is the ip by which the host was added to engine. since the display network is not on that ip, the connection fails.


steps to reproduce:
1. on engine create nic with ipv6 config on the host (static\dynamic)
2. connect a network to the nic and set the display role on it
3. create a vm with a vnic and connect the above network to it
4. start the vm and try to open the console
==> console cannot be opened with message "could not connect to <hostName>. connection refused"

to help demonstrate that this is the problem do:
5. while the vm is running, edit the host>console and gpu>override display address and set the static address from step 1 on it, save.
6. go to the vm and click console
==> console will open


vdsm-client VM getInfo vmID='...' for ipv4 config returns the relevant ipv4 addresses while
vdsm-client VM getInfo vmID='...' for ipv6 config returns "0" for the displayIp:

        {
            "device": "spice", 
            "port": "-1", 
            "specParams": {
                "copyPasteEnable": true, 
                "displayIp": "0", 
                "displayNetwork": "n23", 
                "fileTransferEnable": true
            }, 
            "tlsPort": "-1", 
            "type": "graphics"
        }, 
        {
            "device": "vnc", 
            "port": "-1", 
            "specParams": {
                "copyPasteEnable": true, 
                "displayIp": "0", 
                "displayNetwork": "n23", 
                "fileTransferEnable": true, 
                "keyMap": "en-us"
            }, 
            "type": "graphics"
        },

Verified on - vdsm-4.30.12-1.el7ev.x86_64 and rhvm-4.3.3.1-0.1.el7.noarch

Scenarios:

1. Open console over management network via IPv6 static address only - PASS
2. Switch display role from management network to a non-mgmt network(IPV6 static address) - PASS
3. Open console via the non-mgmt network IPv6 address - PASS

This bugzilla is included in oVirt 4.3.3 release, published on April 16th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.3 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.