cloud-init fails to initialize with virtual router

Bug #1881806 reported by Imtiaz Chowdhury
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Cloud-init fails to initialize with RHEL8.1 and CentOS8.1 (RPM cloud-init-18.5-7.el8_1.1.noarch) when routing to the VMs are provider by virtual router (vrouter). In this scenario, we are spawning a VM on OpenStack using Contrail as the network provider. With cloud-init-18.5 version, we see the following exception during the VM boot phase causing init and final stages of cloud-init to fail.

Impact: cloud-init fails to inject ssh-keys, grow root partition and other critical functions.

Version cloud-init-18.2-6.el8.noarch of cloud-init did not have this issue.

Reproducibility: always

2020-06-02 19:17:15,641 -[WARNING]: failed stage init
failed run of stage init
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/cloudinit/cmd/", line 652, in status_wrapper
    ret = functor(name, args)
  File "/usr/lib/python3.6/site-packages/cloudinit/cmd/", line 362, in main_init
    init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
  File "/usr/lib/python3.6/site-packages/cloudinit/", line 649, in apply_network_config
    netcfg, src = self._find_networking_config()
  File "/usr/lib/python3.6/site-packages/cloudinit/", line 636, in _find_networking_config
    if self.datasource and hasattr(self.datasource, 'network_config'):
  File "/usr/lib/python3.6/site-packages/cloudinit/sources/", line 115, in network_config
    self.network_json, known_macs=None)
  File "/usr/lib/python3.6/site-packages/cloudinit/sources/helpers/", line 645, in convert_net_json
    'Unknown network_data link type: %s' % link['type'])
ValueError: Unknown network_data link type: vrouter

The error seems to be coming from cloudinit/sources/helpers/ file which only expects 'link' type to 'vlan' only.

        elif link['type'] in ['vlan']:
            name = "%s.%s" % (link['vlan_link'], link['vlan_id'])
                'name': name,
                'vlan_id': link['vlan_id'],
                'mac_address': link['vlan_mac_address'],
            link_updates.append((cfg, 'vlan_link', '%s',
            link_updates.append((cfg, 'name', "%%s.%s" % link['vlan_id'],
            curinfo.update({'mac': link['vlan_mac_address'],
                            'name': name})
            raise ValueError(
                'Unknown network_data link type: %s' % link['type'])

However, with Contrail, the network_config object that gets passed to the method convert_net_json looks something like the following object:

  "services": [],
  "networks": [
      "network_id": "f42c8806-c128-4ef8-af9e-d4a3856dde23",
      "type": "ipv4",
      "netmask": "",
      "link": "tap722bcc7f-5a",
      "routes": [
          "netmask": "",
          "network": "",
          "gateway": ""
      "ip_address": "",
      "id": "network0"
  "links": [
      "type": "vrouter", <------------------ NOTE: The link type
      "vif_id": "722bcc7f-5ae5-4564-ad43-ff9a5357dd36",
      "ethernet_mac_address": "02:72:2b:cc:7f:5a",
      "id": "tap722bcc7f-5a",
      "mtu": null

description: updated
Revision history for this message
Ryan Harper (raharper) wrote :

This issue has already been fixed in upstream cloud-init, see:


For downstream, you'll need RedHat/Centos to cherry pick this commit.

If possible, you can test with our daily rpm build for Centos8 using this COPR repo:

Changed in cloud-init:
status: New → Invalid
description: updated
Revision history for this message
Imtiaz Chowdhury (chowdhury-imtiaz) wrote :

Thanks Ryan. The issue seems to be indeed resolved in the new version of the package. I tested it with cloud-init-20.2+41.g1211ab44-1.el8.noarch

Revision history for this message
Ryan Harper (raharper) wrote :

Thank you for verifying!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.