Hide Forgot
Created attachment 1242251 [details] vdsm log snippet Description of problem: During deployment iptable rules are being applied to enable incoming access to libvirt's migration ports. As these rules only apply to ipv4 iptables, ipv6 ports remain closed, resulting in inaccessibility. How reproducible: 100% Steps to Reproduce: 1) Create a VM network 2) Set a migration role to the network 3) Attach it to 2 hosts configured for static ipv6 addresses (ipv4 protocol set to none) 4) Migrate a VM from one of the hosts to the other one Actual results: Migration fails due to socket permission denied on the target host. Expected results: Migration succeeds.
Leon, the ovirt-host-deploy tool set iptables rules provided by the engine. Are the iptables6 rules sent by the engine to ovirt-host-deploy?
They are not, but iiuc it wouldn't matter as we don't have the infrastructure to set ip6table rules.
Allow me to elaborate: IIUC, currently, engine provides ipv4 rules that are written via OHD to a file that iptables is set to used. There are 2 problems with this in regards to ipv6; as you wrote, engine doesn't provide ipv6 rules; and more importantly, we don't have the infrastructure to write to a different file dedicated to ipv6, and to set ip6tables to use it -- iptables and ip6tables aren't meant to share the same rule set as they're not compatible with one another. Naively, I think we should add similar infrastructure to ipv6, writing to a separate file and setting ip6tables to use that file (and similarly provide the required ipv6 rules via engine)
I have been seeing a different outcome of ovirt-host-deploy. Once firewalld is disabled and replaced by iptables-services, 'ip6tables -L' shows that the rules are lost, leaving ports wide open: [root@lago-basic-suite-master-host0 ~]# ip6tables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination This allows IPv6 migration to work, but for a great cost of having a useless IPv6 firewall. You can use the same steps to reproduce, re-enabled in OST by https://gerrit.ovirt.org/#/c/74052/
ok, migration over ipv6 only migration network works ok vdsm-4.20.3-178.gitee07ec4.el7.centos.x86_64 ovirt-host-deploy-1.7.0-0.0.master.20170912090102.git1eeb5a2.el7.centos.noarch ovirt-engine-4.2.0-0.0.master.20171029154613.git19686f3.el7.centos.noarch with 'firewalld' fw type on cluster: * ok # firewall-cmd --list-all --zone=public public (active) target: default icmp-block-inversion: no interfaces: ovirtmgmt eth1 sources: services: dhcpv6-client ssh rpc-bind snmp cockpit libvirt-tls ovirt-vmconsole vdsm nfs ctdb ovirt-storageconsole nrpe samba ports: 22/tcp 54322/tcp 6081/udp 963/udp 965/tcp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: with 'iptables' fw type on cluster: * ok # ip6tables -nL Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.