Public bug reported:
Hello,
I uploaded
bionic-server-cloudimg-amd64.img
into glance. I started an Instance. The instance is reachable.
Next i shutdown the instance
openstack server stop <instance-id>
detach the interface
openstack server remove network <instance-id> <network>
afterwards I attach a new interface with the same IP as before
openstack server add fixed ip --fixed-ip-address <IP-address> <instance-id>
<network>
then start the instance and the instance is not reachable.
I can reproduce this behaviour with.
bionic-server-cloudimg-amd64.img
CentOS-7-x86_64-GenericCloud-1907.qcow2
This does not happen with :
CentOS-6-x86_64-GenericCloud-1907.qcow2
xenial-server-cloudimg-amd64-disk1.img
trusty-server-cloudimg-amd64-disk1.img
cirros-0.4.0-x86_64-disk.img
The images are unchanged.
I logged in via local console into ubuntu 18:04. The interface was down and I
could see the following logs:
Aug 26 08:38:17 os-steb-pa1 systemd[1]: Starting Apply the settings specified
in cloud-config...
Aug 26 08:38:17 os-steb-pa1 networkd-dispatcher[754]: No valid path found for
iwconfig
Aug 26 08:38:17 os-steb-pa1 networkd-dispatcher[754]: No valid path found for iw
A dhclient -v <interface> started the interface and the the instance got
an answer from dhcp and was reachable again.
I logged in via local console into CentOS 7. The interface was also down
and I could see the following logs:
Aug 26 09:05:37 os-steb-cl1 network: Bringing up interface eth0: ERROR :
[/etc/sysconfig/network-scripts/ifup-eth] Device eth0 has different MAC address
than expected, ignoring.
Aug 26 09:05:37 os-steb-cl1 /etc/sysconfig/network-scripts/ifup-eth: Device
eth0 has different MAC address than expected, ignoring.
Aug 26 09:05:37 os-steb-cl1 network: [FAILED]
Aug 26 09:05:37 os-steb-cl1 systemd: network.service: control process exited,
code=exited status=1
A dhclient -v <interface> started the interface and the the instance got
an answer from dhcp and was reachable again.
The problem is the old mac address in
ubuntu 18.04 /etc/netplan/50-cloud-init.yaml
centos 7 /etc/sysconfig/network-scripts/ifcfg-eth0
Manually changing the mac address in these files to the new one, solves
the problem and the instances are reachable again after reboots.
I don't know how the mechanism worked for the older operating systems to
establish a network connection after the interface changed via
openstack, but this seems to be broken with the newer operating systems.
Environment
===========================
1.
Rocky
ii nova-api 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - API frontend
ii nova-common 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - common files
ii nova-conductor 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - conductor service
ii nova-consoleauth 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - Console Authenticator
ii nova-novncproxy 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - NoVNC proxy
ii nova-placement-api 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - placement API frontend
ii nova-scheduler 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - virtual machine scheduler
ii python-nova 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute Python 2 libraries
2.
Libvirt + KVM
ii qemu-kvm 1:2.11+dfsg-1ubuntu7.17
amd64 QEMU Full virtualization on x86 hardware
ii libvirt-daemon 4.0.0-1ubuntu8.12
amd64 Virtualization daemon
ii libvirt-daemon-driver-storage-rbd 4.0.0-1ubuntu8.12
amd64 Virtualization daemon RBD storage driver
ii libvirt0:amd64 4.0.0-1ubuntu8.12
amd64 library for interfacing with different virtualization systems
ii python-libvirt 4.0.0-1
amd64 libvirt Python bindings
3.
Neutron with OpenVSwitch and dvr_snat
Greets
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1841582
Title:
Interface detach and attach does not work with CentOS 7 and Ubuntu
18.04 cloud images
Status in OpenStack Compute (nova):
New
Bug description:
Hello,
I uploaded
bionic-server-cloudimg-amd64.img
into glance. I started an Instance. The instance is reachable.
Next i shutdown the instance
openstack server stop <instance-id>
detach the interface
openstack server remove network <instance-id> <network>
afterwards I attach a new interface with the same IP as before
openstack server add fixed ip --fixed-ip-address <IP-address> <instance-id>
<network>
then start the instance and the instance is not reachable.
I can reproduce this behaviour with.
bionic-server-cloudimg-amd64.img
CentOS-7-x86_64-GenericCloud-1907.qcow2
This does not happen with :
CentOS-6-x86_64-GenericCloud-1907.qcow2
xenial-server-cloudimg-amd64-disk1.img
trusty-server-cloudimg-amd64-disk1.img
cirros-0.4.0-x86_64-disk.img
The images are unchanged.
I logged in via local console into ubuntu 18:04. The interface was down and I
could see the following logs:
Aug 26 08:38:17 os-steb-pa1 systemd[1]: Starting Apply the settings specified
in cloud-config...
Aug 26 08:38:17 os-steb-pa1 networkd-dispatcher[754]: No valid path found for
iwconfig
Aug 26 08:38:17 os-steb-pa1 networkd-dispatcher[754]: No valid path found for
iw
A dhclient -v <interface> started the interface and the the instance
got an answer from dhcp and was reachable again.
I logged in via local console into CentOS 7. The interface was also
down and I could see the following logs:
Aug 26 09:05:37 os-steb-cl1 network: Bringing up interface eth0: ERROR :
[/etc/sysconfig/network-scripts/ifup-eth] Device eth0 has different MAC address
than expected, ignoring.
Aug 26 09:05:37 os-steb-cl1 /etc/sysconfig/network-scripts/ifup-eth: Device
eth0 has different MAC address than expected, ignoring.
Aug 26 09:05:37 os-steb-cl1 network: [FAILED]
Aug 26 09:05:37 os-steb-cl1 systemd: network.service: control process exited,
code=exited status=1
A dhclient -v <interface> started the interface and the the instance
got an answer from dhcp and was reachable again.
The problem is the old mac address in
ubuntu 18.04 /etc/netplan/50-cloud-init.yaml
centos 7 /etc/sysconfig/network-scripts/ifcfg-eth0
Manually changing the mac address in these files to the new one,
solves the problem and the instances are reachable again after
reboots.
I don't know how the mechanism worked for the older operating systems
to establish a network connection after the interface changed via
openstack, but this seems to be broken with the newer operating
systems.
Environment
===========================
1.
Rocky
ii nova-api 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - API frontend
ii nova-common 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - common files
ii nova-conductor 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - conductor service
ii nova-consoleauth 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - Console Authenticator
ii nova-novncproxy 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - NoVNC proxy
ii nova-placement-api 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - placement API frontend
ii nova-scheduler 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute - virtual machine scheduler
ii python-nova 2:18.1.0-0ubuntu1~cloud0
all OpenStack Compute Python 2 libraries
2.
Libvirt + KVM
ii qemu-kvm 1:2.11+dfsg-1ubuntu7.17
amd64 QEMU Full virtualization on x86 hardware
ii libvirt-daemon 4.0.0-1ubuntu8.12
amd64 Virtualization daemon
ii libvirt-daemon-driver-storage-rbd 4.0.0-1ubuntu8.12
amd64 Virtualization daemon RBD storage driver
ii libvirt0:amd64 4.0.0-1ubuntu8.12
amd64 library for interfacing with different virtualization
systems
ii python-libvirt 4.0.0-1
amd64 libvirt Python bindings
3.
Neutron with OpenVSwitch and dvr_snat
Greets
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1841582/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
