Description of problem:
I tried to boot instance with 2 interfaces (Tried with Cirros& Rhel images)
and it looks like ETH1 in not configured in the VM.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.openstack network create net-64-2
2.openstack subnet create --subnet-range 10.0.2.0/24 --network net-64-2 --dhcp subnet_4_2
3.openstack subnet create --subnet-range 2002::/64 --network net-64-2 --ipv6-address-mode slaac --ipv6-ra-mode slaac --ip-version 6 subnet_6_2
4.openstack network create net-64-1
5.openstack subnet create --subnet-range 10.0.1.0/24 --network net-64-1 --dhcp subnet_4_1
6.openstack subnet create --subnet-range 2001::/64 --network net-64-1 --ipv6-address-mode slaac --ipv6-ra-mode slaac --ip-version 6 subnet_6_1
7.openstack router create Router_eNet
8.openstack router add subnet Router_eNet subnet_4_2
9.openstack router add subnet Router_eNet subnet_4_1
10.openstack router add subnet Router_eNet subnet_6_1
11.openstack router add subnet Router_eNet subnet_6_2
12.openstack router set --external-gateway nova Router_eNet
13.openstack server create --flavor 2 --image cirros --nic net-id=net-64-2 --nic net-id=net-64-1 VM_2_interfaces
only 1 interface was configured
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast qlen 1000
link/ether fa:16:3e:a7:c6:13 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.14/24 brd 10.0.2.255 scope global eth0
inet6 2002::f816:3eff:fea7:c613/64 scope global dynamic
valid_lft 86373sec preferred_lft 14373sec
inet6 fe80::f816:3eff:fea7:c613/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether fa:16:3e:33:98:9d brd ff:ff:ff:ff:ff:ff
This has been the case since OSP 4 (and possibly earlier). As far as I know there is no code that (by default) scans the number of Neutron ports assigned to a VM and sets up the networking in it to match the Neutron ports, this functionality is just missing (in that sense, this RHBZ could be considered an RFE). It may be possible to implement this using cloud-init/metadata. I'll flip this to the Compute DFG and see what they have to say.
Just trying to work out what you're reporting here. Are you saying that DHCP doesn't work on eth1? Or are you saying that the guest OS doesn't bring up eth1 by default?
i.e. if you do this in the guest:
# dhclient eth1
do you get an IP address?
(In reply to Matthew Booth from comment #3)
> Just trying to work out what you're reporting here. Are you saying that DHCP
> doesn't work on eth1? Or are you saying that the guest OS doesn't bring up
> eth1 by default?
> i.e. if you do this in the guest:
> # dhclient eth1
> do you get an IP address?
I am saying that the guest OS doesn't bring up eth1 by default.
When I type "ip a" command I can see eth1 but in /etc/sysconfig/network-script/
there is no ifcfg file that created for eth1.
I don't get IP address when I do dhclient eth1.
Is the second port configured with an IP? Is the network it's on configured for DHCP?
AFAIK, cloud-init should be able to look at the interfaces piece of metadata to configure the second interface as either DHCP or static if assigned an address, but I'm not sure if this is expected to happen or not. Since Assaf says it's expected, I believe him.
I assume you're not reporting this as a regression right? Maybe we should ask a cloud-init person?
I think that would be helpful to get the console logs of the guest so we can see whether couldinit is doing its work correctly.
Possibly a dup of https://bugzilla.redhat.com/show_bug.cgi?id=1236219
Relevant code in cloud init AFAICT - https://github.com/openstack/cloud-init/blob/0.7.x/cloudinit/distros/rhel.py#L66
(In reply to Ollie Walsh from comment #9)
> Possibly a dup of https://bugzilla.redhat.com/show_bug.cgi?id=1236219
Yeah, it does seem like duplicate of the above bug (which is not yet resolved).
Talking to Lars on IRC, he mentioned Eduardo Otubo (firstname.lastname@example.org) is the maintainer. Eduardo, do you have time to look at this?
(In reply to Kashyap Chamarthy from comment #11)
> (In reply to Ollie Walsh from comment #9)
> > Possibly a dup of https://bugzilla.redhat.com/show_bug.cgi?id=1236219
> Yeah, it does seem like duplicate of the above bug (which is not yet
> Talking to Lars on IRC, he mentioned Eduardo Otubo (email@example.com) is
> the maintainer. Eduardo, do you have time to look at this?
I'm not the maintainer, but I can look at that.
We are running into the same issue. With config-drive both interfaces are configured but without config-drive only the first interface is configured
According to comment 25, give qa_ack+.
We only have openstack PSI testing ENV which only have 1 interface, and we have no permission to setup 2 interfaces. So we will try to test this on Azure later.
Tested cloud-init-19.4-7.el7.x86_64 with RHEL7.9 latest version on openstack, the issue has gone.
cloud-init created ifcfg file for both eth0 and eth1, so the problem described in this bug report should be resolved.
Close it as fixed in currentrelease.
If the solution does not work for you, open a new bug report.