Bug 1495441

Does this happen with the API? If so please provide an example of the API requests that you are sending.

Are there additional patches needed here, or can this bug move to MODIFIED state?

No additional devel work is expected.

Testing on 4.2.0-0.0.master.20171112130303.git8bc889c.el7.centos

Running cmd:
curl -v -u "$user@$domain:$password" -H "Content-type: application/xml" --insecure -X POST https://$engine/ovirt-engine/api/vms/$vm_id/start -d "<action><use_cloud_init>true</use_cloud_init><vm><initialization><nic_configurations><nic_configuration><name>ahoj</name><on_boot>true</on_boot><boot_protocol>static</boot_protocol><ip><address>$address</address><gateway>$gateway</gateway><netmask>$netmask</netmask><version>v4</version></ip><ipv6_boot_protocol>dhcp</ipv6_boot_protocol></nic_configuration></nic_configurations></initialization></vm></action>"

results in new interface having bootproto=dhcp for ipv4 address (and ipv6 is not mentioned anywhere in that new interface)

same happens with values entered from UI, so most likely there is an underlying bug in cloud-init

> so most likely there is an underlying bug in cloud-init

you're probably seeing bug 1492726. Please install cloud-init-0.7.9-14.el7 in or downgrade to rhel-7.3.z version of cloud-init to verify the ovirt bug.

I have the same results as in comment#4 with cloud-init-0.7.9-14.el7.x86_64

The above test does not test ovrit-engine but rather how cloud-init interprets engine network configuration.

This bug fixes a problem in the engine which used to put ipv4 params into ipv6 config, in the engine network configuration file (which is then consumed by cloud-init).

Please test the engine raw output of the network config: on the host holding the vm, mount the image and look at the contents of the engine config file to cloud-init:

mount /var/run/vdsm/payload/<image id> /mnt
/mnt/openstack/latest/network_data.json

with the cloud-init config that was posted to the engine above this file would be:

A. before the fix:
{
  "links" : [ {
    ...
  }, {
    "link" : "ahoj",
    "id" : "ahoj",
    "type" : "ipv4"
  } ]
}

B. after the fix:
{
  "links" : [ {
    ...
  }, {
    "link" : "ahoj",
    "id" : "ahoj",
    "type" : "dhcp6"
  } ]
}

I believe that what you have seen is a cloud-init bug, which seems to ignore the IPv6 settings if IPv4 settings are present.

To verify this specific bug, you could keep IPv4 unset. However, what you report is most important - please file a cloud-init bug about it and make it block this bug.

Hi Ryan,
During the verification of this bug we came across the following:
ovirt-engine sends the following network_data.json to cloud-init:

{
  "links" : [ {
    "name" : "ahoj",
    "id" : "ahoj",
    "type" : "vif"
  } ],
  "networks" : [ {
    "netmask" : "255.255.255.0",
    "link" : "ahoj",
    "id" : "ahoj",
    "ip_address" : "192.168.122.201",
    "type" : "ipv4",
    "gateway" : "192.168.122.1"
  }, {
    "link" : "ahoj",
    "id" : "ahoj",
    "type" : "dhcp6"
  } ]
}

and cloud-init-0.7.9-14.el7.x86_64 creates the following ifcfg:

# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=dhcp
DEVICE=ahoj
GATEWAY=192.168.122.1
IPADDR=192.168.122.201
NETMASK=255.255.255.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no


is the network_data.json OK? is the ifcfg OK?

thanks

(In reply to eraviv from comment #10)
> Hi Ryan,
> During the verification of this bug we came across the following:
> ovirt-engine sends the following network_data.json to cloud-init:
> 
> {
>   "links" : [ {
>     "name" : "ahoj",
>     "id" : "ahoj",
>     "type" : "vif"
>   } ],
>   "networks" : [ {
>     "netmask" : "255.255.255.0",
>     "link" : "ahoj",
>     "id" : "ahoj",
>     "ip_address" : "192.168.122.201",
>     "type" : "ipv4",
>     "gateway" : "192.168.122.1"
>   }, {
>     "link" : "ahoj",
>     "id" : "ahoj",
>     "type" : "dhcp6"
>   } ]
> }
> 
> and cloud-init-0.7.9-14.el7.x86_64 creates the following ifcfg:
> 
> # Created by cloud-init on instance boot automatically, do not edit.
> #
> BOOTPROTO=dhcp
> DEVICE=ahoj
> GATEWAY=192.168.122.1
> IPADDR=192.168.122.201
> NETMASK=255.255.255.0
> ONBOOT=yes
> TYPE=Ethernet
> USERCTL=no
> 
> 
> is the network_data.json OK? is the ifcfg OK?
> 
> thanks

If the boot protocol is really supposed to be dhcp6, it looks like a bug in cloud-init that's also present in upstream's master git branch.

Is there a reason you want to use dhcpv6 with an ipv4-only host?

If this is something you need in cloud-init, please file a separate bz for it, and I'll try to get it fixed upstream. I have a small patch that fixes it that I'll propose there.

The intention here is to have to address on the "ahoj" link: a static ipv4 and a dhcp6-based ipv6. Ryan, is this something that is yet to be added to cloud-init?

(In reply to Dan Kenigsberg from comment #14)
> The intention here is to have to address on the "ahoj" link: a static ipv4
> and a dhcp6-based ipv6. Ryan, is this something that is yet to be added to
> cloud-init?

Ok, I see. It should support dual-stack hosts, but I don't have the ability to test it ATM. If I gave you a test package, would you be able to let me know if it works they way you intend?

(In reply to Ryan McCabe from comment #15)
> (In reply to Dan Kenigsberg from comment #14)
> > The intention here is to have to address on the "ahoj" link: a static ipv4
> > and a dhcp6-based ipv6. Ryan, is this something that is yet to be added to
> > cloud-init?
> 
> Ok, I see. It should support dual-stack hosts, but I don't have the ability
> to test it ATM. If I gave you a test package, would you be able to let me
> know if it works they way you intend?

yes we would gladly test it. thanks

Before I give you a test package, could you test which, if any, of these interface definition files (/etc/sysconfig/network-scripts/ifcfg-ahoj) does the right thing. I'm not sure of the syntax when you want static ipv4 and dhcp ipv6 on the same interface.

Not sure whether it should be:

BOOTPROTO=dhcp
DEFROUTE=yes
DEVICE=ahoj
DHCPV6C=yes
GATEWAY=192.168.122.1
IPADDR=192.168.122.201
IPV6INIT=yes
NETMASK=255.255.255.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

or

BOOTPROTO=none
DEFROUTE=yes
DEVICE=ahoj
DHCPV6C=yes
GATEWAY=192.168.122.1
IPADDR=192.168.122.201
IPV6INIT=yes
NETMASK=255.255.255.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

I think in the case of the former, you may get dhcp for ipv4, which you don't want. I'm not sure what will happen for v6 in the second, because I don't have a setup where I am able to test dhcpv6 right now.

Before I give you a test package, could you test which, if any, of these interface definition files (/etc/sysconfig/network-scripts/ifcfg-ahoj) does the right thing. I'm not sure of the syntax when you want static ipv4 and dhcp ipv6 on the same interface.

Not sure whether it should be:

BOOTPROTO=dhcp
DEFROUTE=yes
DEVICE=ahoj
DHCPV6C=yes
GATEWAY=192.168.122.1
IPADDR=192.168.122.201
IPV6INIT=yes
NETMASK=255.255.255.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

or

BOOTPROTO=none
DEFROUTE=yes
DEVICE=ahoj
DHCPV6C=yes
GATEWAY=192.168.122.1
IPADDR=192.168.122.201
IPV6INIT=yes
NETMASK=255.255.255.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

I think in the case of the former, you may get dhcp for ipv4, which you don't want. I'm not sure what will happen for v6 in the second, because I don't have a setup where I am able to test dhcpv6 right now.

Thomas,

Following the discussion above and Ryan's question, do you know which is the right sysconfig definition (see above) to enable a static ipv4 configuration alongside a dhcp ipv6 configuration on the same NIC?

Thanks

BOOTPROTO=dhcp means to enable DHCPv4.
A static-only IPv4 setting should set BOOTPROTO=none (or omit BOOTPROTO).

Ok, thank you. It looks like we need two patches for this one. I've proposed one to fix the absence of ipv6 config upstream. We need a second patch to change the BOOTPROTO rendering, but that looks specific to RHEL (suse has different behavior here).

Apparently openstack is sending "ipv6_dhcp" and not "dhcp6" (and "ipv4_dhcp" for ipv4) in its network_data.json. Would it be possible to stay consistent with that behavior, or is it too late?

It's not too late but this format contradicts the protocol i see in http://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html
(and also in version 1 of the above) which is the protocol we referred to in our latest fixes. In the open-stack configuration page (https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html) there is no mention of what they use according to my best understanding.

Let me know if you would like to leave the current protocol (dhcp4\dhcp6) or move to ipv4_dhcp\ipv6_dhcp

Maybe we should move this conversation to the cloud-init mailing list before deciding.

Thanks

That link is from the cloud-init yaml documentation. The network_data.json format is defined by openstack (nova I believe), and simply consumed by cloud-init. They're two different formats that cloud-init is able to use for network configuration.

It's hard to find full documentation of nova's network_data.json, but there's at least a mention of the dhcp6 stuff at: https://docs.openstack.org/releasenotes/nova/pike.html

I think the better route would be to would be to ask on the nova mailing list for the possible values.

There's this, too (see around line 271)

https://github.com/openstack/nova/blob/master/nova/virt/netutils.py

(In reply to Ryan McCabe from comment #25)
> There's this, too (see around line 271)
> 
> https://github.com/openstack/nova/blob/master/nova/virt/netutils.py

ok, we'll go along with the openstack "ipv6_dhcp" and "ipv4_dhcp". let me know when you have and rpm that we could test against.

I'm going to clone this against cloud-init to track the changes that need to be made there. I'll post a link to a test build there when I have one.

Verified on ovirt-engine-4.2.1.2-0.1.el7.noarch with cloud-init-0.7.9-22.el7.x86_64 on the VM

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.