Description of problem: The cloud-init version shipped with RHEL6 (0.7.5 - cloud-init-0.7.5-8.el6_9.2) does not parse network_data.json. In RHV 4.2, along with support for the Openstack Metadata Protocol, the network config is now dumped into network_data.json file. This was done alltogether via this change: https://gerrit.ovirt.org/#/c/81760/ Specifically here: backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/vdsbroker/CloudInitHandler.java .... if (isOpenstackMetadataProtocol() && !StringUtils.isEmpty(networkDataStr)) { files.put("openstack/latest/network_data.json", networkDataStr.getBytes("UTF-8")); } ... This assumes every cloud-init version that supports OMP will read network_data.json. Apparently this is only true after 0.7.7. I see some discussions between Eitan and Arik around this possibly breaking older OSes. It doesn't look like RHEL6 needs to revert to ENI (which from what I can see is still supported on the code, but not visible to the user to set it, its always OPENSTACK_METADATA). But it seems it needs to check if the configured Guest OS is EL6 and then dump the networking configuration to meta_data.json instead of network_data.json. From a user perspective, this broke when upgrading RHV-M from 4.1 to 4.2, his RHEL6 templates no longer work with cloud-init. Version-Release number of selected component (if applicable): ovirt-engine-4.2.4.5-0.1.el7_3.noarch How reproducible: 100% Steps to Reproduce: 1. Configure network via cloud-init for a RHEL6 guest. Actual results: Network configs are ignored Expected results: Compatibility with RHEL6 guests.
Miroslav, can Red Hat build and release a newer version of cloud-init (18.2?) on RHEL-6?
(In reply to Dan Kenigsberg from comment #1) > Miroslav, can Red Hat build and release a newer version of cloud-init > (18.2?) on RHEL-6? Not sure in this moment but not likely due to late RHEL 6 cycle. However, we can try to request permission to rebase to 18.2.
Miroslav, where did you make this request for a rebase? Karen, maybe you can help RHV (and I suppose OSP too) to have a modern cloud-init in RHEL 6?
(In reply to Dan Kenigsberg from comment #4) > Miroslav, where did you make this request for a rebase? > > Karen, maybe you can help RHV (and I suppose OSP too) to have a modern > cloud-init in RHEL 6? As initial point, create a BZ with rebase keyword that will be used for negotiating the rebase.
RHV-Engine can reintroduce ENI code and use it based on the guest type, or an explicit request by the user. I dislike this idea, since ENI had multiple bugs which would never be fixed for el6. However, it is doable.
I think it is terribly wrong to solve this only on RHV, but without agreement from RHEL6, I'm taking the bug back to RHV-4.3.
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ] For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ] For more info please contact: rhv-devops
The manual tests on 4.3.0-0.8.master.20190122121624.git9a8a519.el7 passed but the automation tests failed because of https://bugzilla.redhat.com/show_bug.cgi?id=1671281.
Verified on: ovirt-engine-4.3.0.5-0.0.master.20190214203537.git92a2f86.el7.noarch Guest: OS: RHEL6.10 and RHEL6.9 cloud-init-0.7.5-8.el6_9.2.x86_64 Steps: 1. Create a sealed VM from a template with RHEL < 7 2. Edit the VM, Initial run. 3. Enable Cloud-init/sysprep, Use ENI protocol, add 2 NICs and DNS configuration: Select Cloud-Init Network Protocol: ENI First NIC - IPv4 set static, add IPv4 Address, IPv4 Netmask, IPv4 Gateway, name it for example eth1. Second NIC - IPv4 set DHCP, name it for example eth2. Add DNS Server, DNS search domain (for example 1.2.3.4 for DNS server and foo.test.com for DNS search). 4. Run the VM 5. Connect to the VM, check the VM's network configuration: Check the ifcfg-eth1 and ifcfg-eth2 in /etc/sysconfig/network-scripts. IPADDR, GATEWAY, NETMASK, BOOTPROTO all suppose to set as step 3(in DHCP there are less configurations). 6. Check DNS is set under /etc/resolv.conf Results: The configuration was loaded successfully to the guest. The network setting were set accordingly.
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, 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-2019:1085