Bug 2098501
| Summary: | [RHEL-9.1] IPv6 not workable when cloud-init configure network using NM keyfiles | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | xiachen | |
| Component: | cloud-init | Assignee: | Emanuele Giuseppe Esposito <eesposit> | |
| Status: | CLOSED ERRATA | QA Contact: | xiachen | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 9.1 | CC: | eesposit, eterrell, huzhao, jgreguske, lrintel, xiachen, xiliang, yacao, yuxisun | |
| Target Milestone: | rc | Keywords: | Regression, Triaged | |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | cloud-init-22.1-5.el9 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 2098624 (view as bug list) | Environment: | ||
| Last Closed: | 2022-11-15 10:13:40 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 2056964 | |||
| Bug Blocks: | ||||
|
Description
xiachen
2022-06-20 02:08:17 UTC
I Modified the keyfile "/etc/NetworkManager/system-connections/cloud-init-eth0.nmconnection", [ipv6] method=auto may-fail=false and then run below nmcli commands, IPv6 connection both works on OpenStack and Azure. nmcli conn reload nmcli conn up "cloud-init eth0" that changes are, on OpenStack VM instance, removing the line addr-gen-mode=stable-privacy on Azure VM instance, removing the line addr-gen-mode=stable-privacy, and changing ipv6 method=auto @Ludomir I would like to ask your opinion here: I see from logs that you introduced cloudinit/net/network_manager.py, is there a specific reason on why we have add-gen-mode set? It seems that other renderers like sysconfig do not set it. Also not sure why on Azure ipv6 method is dhcp and not auto. Thank you, Emanuele AWS instance has the same issue with Azure. /etc/NetworkManager/system-connections/cloud-init-eth0.nmconnection # Generated by cloud-init. Changes will be lost. ... [ipv6] method=dhcp may-fail=false addr-gen-mode=stable-privacy # ping6 2001:4860:4860::8888 -c 1 connect: Network is unreachable While below configuration IP connection works. [ipv6] method=auto may-fail=false # ping6 2001:4860:4860::8888 -c 1 PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes 64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=109 time=7.93 ms --- 2001:4860:4860::8888 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 7.928/7.928/7.928/0.000 ms I believe the add-gen-mode point is not a blocker and not intimately related to the solution (please correct me if I'm wrong here). We know for a fact that changing method from dhcp to auto fixes the problem. I think we can move forward with this solution. Raising priority as no network has a big impact. Should be solved on the current release. As this affects 9.1 (after rebase) I assume it also can be reproduced on 8.7. Please clone if necessary and set NEEDINFO on me to set zstream flag. Thanks! (In reply to Eduardo Otubo from comment #4) > I believe the add-gen-mode point is not a blocker and not intimately related > to the solution (please correct me if I'm wrong here). We know for a fact > that changing method from dhcp to auto fixes the problem. I think we can > move forward with this solution. I'm sorry I misinterpreted the tests. Since no other renderer uses add-gen-mode I assume it's not a crucial option and I believe we can remove it from the configuration from now *as well as* change ipv6.method to auto. 8.7 bug is BZ#2098624. I think we don't need zstream fix, because this problem was brought into 22.1 after this bug fix, it does not affect zstream.(Correct me if I'm wrong) Bug 2056964 - [RHEL-9]Rebase cloud-init from Fedora so it can configure networking using NM keyfiles (In reply to Eduardo Otubo from comment #5) > Raising priority as no network has a big impact. Should be solved on the > current release. As this affects 9.1 (after rebase) I assume it also can be > reproduced on 8.7. Please clone if necessary and set NEEDINFO on me to set > zstream flag. > > Thanks! (In reply to xiachen from comment #9) > 8.7 bug is BZ#2098624. > > I think we don't need zstream fix, because this problem was brought into > 22.1 after this bug fix, it does not affect zstream.(Correct me if I'm wrong) > Bug 2056964 - [RHEL-9]Rebase cloud-init from Fedora so it can configure > networking using NM keyfiles Thanks for the info, Amy! Also, if this solution fixes the problem, can you run some quick test on bz#2104393 with the same package? Wondering if it's the same root cause. > > > (In reply to Eduardo Otubo from comment #5) > > Raising priority as no network has a big impact. Should be solved on the > > current release. As this affects 9.1 (after rebase) I assume it also can be > > reproduced on 8.7. Please clone if necessary and set NEEDINFO on me to set > > zstream flag. > > > > Thanks! (In reply to Eduardo Otubo from comment #10) > > Also, if this solution fixes the problem, can you run some quick test on > bz#2104393 with the same package? Wondering if it's the same root cause. > Eduardo, the scratch build in comment 8 does NOT fix bz#2104393, I think the root cause of bz#2104393 is not same with this BZ. I added the root cause of bz#2104393 in the description: The default NM keyfile is active instead cloud-init generated keyfile, so the configurations in cloud-init-ens192.nmconnection can not take effect. Could I know why cloud-init set keyfile name as cloud-init-ens192.nmconnection instead of ens192.nmconnection? Thanks! # nmcli -f NAME,FILENAME,DBUS-PATH connection show NAME FILENAME DBUS-PATH ens192 /etc/NetworkManager/system-connections/ens192.nmconnection /org/freedesktop/NetworkManager/Settings/1 cloud-init ens192 /etc/NetworkManager/system-connections/cloud-init-ens192.nmconnection /org/freedesktop/NetworkManager/Settings/2 (In reply to Huijuan Zhao from comment #11) > (In reply to Eduardo Otubo from comment #10) > > > > Also, if this solution fixes the problem, can you run some quick test on > > bz#2104393 with the same package? Wondering if it's the same root cause. > > > > Eduardo, the scratch build in comment 8 does NOT fix bz#2104393, I think the > root cause of bz#2104393 is not same with this BZ. > > I added the root cause of bz#2104393 in the description: The default NM > keyfile is active instead cloud-init generated keyfile, so the > configurations in cloud-init-ens192.nmconnection can not take effect. > > Could I know why cloud-init set keyfile name as > cloud-init-ens192.nmconnection instead of ens192.nmconnection? Thanks! Thanks for looking into that! I don't know why that happens but I'll investigate. > > # nmcli -f NAME,FILENAME,DBUS-PATH connection show > NAME FILENAME > DBUS-PATH > ens192 > /etc/NetworkManager/system-connections/ens192.nmconnection > /org/freedesktop/NetworkManager/Settings/1 > cloud-init ens192 > /etc/NetworkManager/system-connections/cloud-init-ens192.nmconnection > /org/freedesktop/NetworkManager/Settings/2 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 (cloud-init bug fix and enhancement update), 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/RHEA-2022:8056 |