View Issue Details

IDProjectCategoryView StatusLast Update
0016376CentOS-7Cloud-Imagespublic2019-09-03 10:36
Reporterstebujak 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version7.6.1810 
Target VersionFixed in Version 
Summary0016376: Openstack Interface detach and attach does not work with CentOS 7 cloud images
DescriptionHello,

  I uploaded

  CentOS-7-x86_64-GenericCloud-1907.qcow2

  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 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

  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
TagsNo tags attached.
abrt_hash
URL

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2019-09-03 10:36 stebujak New Issue