Bug 1658638 - Engine should alert if hosts at the cluster are not using the same IP stack
Summary: Engine should alert if hosts at the cluster are not using the same IP stack
Keywords:
Status: NEW
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: 4.3.0
Hardware: x86_64
OS: Linux
high
medium vote
Target Milestone: ovirt-4.4.0
: ---
Assignee: Dan Kenigsberg
QA Contact: Michael Burman
URL:
Whiteboard:
: 1658639 (view as bug list)
Depends On:
Blocks: 1658661
TreeView+ depends on / blocked
 
Reported: 2018-12-12 15:17 UTC by Roni
Modified: 2020-01-14 14:32 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
oVirt Team: Network
dholler: needinfo-
dholler: needinfo-
rule-engine: ovirt-4.4+
mtessun: Triaged+
mtessun: planning_ack+


Attachments (Terms of Use)
migrate ipv6 to ipv4 logs (8.06 MB, application/gzip)
2018-12-12 15:17 UTC, Roni
no flags Details

Description Roni 2018-12-12 15:17:37 UTC
Created attachment 1513702 [details]
migrate ipv6 to ipv4 logs

Description of problem:
Communication between hosts with a different IP stack (only IPv4, only IPv6 or both enabled) can fails.
for example during VM migration


Version-Release number of selected component (if applicable):
4.3.0-0.6.alpha2.el7

How reproducible:
100%

Steps to Reproduce:
1. In host-1 go to: Compute | Hosts | Network Interfaces | Setup Host Networks
2. Edit 'ovirtmgmt' attached to NIC
3. Enable IPv6 and IPv4
4. In host-2 go to the same place and enable only IPv4, IPv6 is disabled
5. At the DNS, make sure both hosts are resolved to both IPv4 & IPv6
6. Run VM on host-1
7. Try to migrate VM from host-1 to host-2

Actual results:
Migration fails

Expected results:
Migration should success or
The system should alert about the mismatch

Additional info:
1. Migration from host-2 to host-1 is working
2. The error at the log is: "No route to host"
3. It found that it is a dual-stack issue, the host that supports both, Ipv4 and IPv6 is trying to open an IPv6 connection to the host that support only IPv4, and fails
4. If FQDN of target host will be resolved to IPv4 then migration will succeed

Comment 1 Dominik Holler 2018-12-18 11:07:59 UTC
*** Bug 1658639 has been marked as a duplicate of this bug. ***

Comment 2 Dominik Holler 2019-08-06 14:15:00 UTC
Is this documented as a limitation?

Comment 3 Dominik Holler 2019-08-06 14:25:39 UTC
Should we have an insights rule for this?

Comment 4 Michal Skrivanek 2019-11-27 09:17:56 UTC
(In reply to Dominik Holler from comment #3)
> Should we have an insights rule for this?

yes!

but it would only be possible if we have that IP stack information aggregated anywhere. Can we see that anywhere in engine db/API which stack a host is using?

Comment 5 Dominik Holler 2019-11-27 09:29:40 UTC
(In reply to Michal Skrivanek from comment #4)
> (In reply to Dominik Holler from comment #3)
> > Should we have an insights rule for this?
> 
> yes!
> 
> but it would only be possible if we have that IP stack information
> aggregated anywhere. Can we see that anywhere in engine db/API which stack a
> host is using?

Indirectly via the API.
A detailed approach could be something like:
For every cluster:
  For every network role:
    check if all hosts have only IPv4 address on attachment of the role's network or \
      check if all hosts have only IPv6 address on attachment of the role's network or \
      check if all hosts have IPv6 and IPv4 address on attachment of the role's network


Note You need to log in before you can comment on or make changes to this bug.