Additional fixed ip address assigned to vm after nova-network restart

Bug #1003934 reported by Mitchell Broome
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Won't Fix
Low
Unassigned

Bug Description

So I'm runing into a problem when I restart nova-network on a compute node in a multi_host setup. Each time I
restart nova-network on one of the compute hosts, multiple guests on the other host are allocated additional
fixed ip addresses in addition to the one they already have and a stack trace is thrown in network.log. The
nova-br100.conf is updated to include both addresses on the same mac/hostname. I'm still able to access the
vm just fine on thier original ip address.

Recreating the problem is very consistent:
1) From a fresh install, bring up 3 virtual machines and take down the first one that came up (typically
   instance_id 1 in the networks table).

2) Stop nova-network on either of the compute hosts. This will produce a stack trace in the network.log on
   the other compute node complaining about 'InstanceNotFound: Instance 1 could not be found'

3) Look at horizon, dnsmasq's config (nova-br100.conf) or the networks table in the database and you will
   see an additional ip address allocated to the vm that was running on the host that did not have nova-network
   taken down. The ec2 compatibility api only reports the new ip address for the instance.

My setup:
I'm running 2 hosts for testing, one is the compute host running nova-api, nova-compute and nova-network. The
other is the controller running nova-api, nova-compute, nova-network as well as the other needed services
(keystone, glance, scheduler). I'm running a fixed network only (192.168.97.0/24), no floating, in a multi_host
setup with the routing handled by an external router (setup with dhcp flags for dnsmasq) with eth1 being the vm
network. Basically nova-network and nova-api are there only for dhcp and meta-data.

I'm using essex packages from EPEL on Centos 6.2. On the compute nodes:
python-novaclient-2012.1-1.el6.noarch
python-nova-2012.1-4.el6.noarch
openstack-nova-2012.1-4.el6.noarch

dhcp-options.conf (flags for dnsmasq):
dhcp-option-force=3,192.168.97.254
#dhcp-option-force=6,192.168.95.10,192.168.95.11
dhcp-option-force=15,openstack.internal

nova-br100.conf after the problem:
fa:16:3e:32:80:69,server-2.openstack.internal,192.168.97.4
fa:16:3e:32:80:69,server-2.openstack.internal,192.168.97.6

View of the networks table before the problem:
http://pastebin.com/KSDgxAkk

View of the networks table after the problem:
http://pastebin.com/mxQWLb7q

My nova.conf (it's the same on both hosts except for my_ip and the console addresses):
http://pastebin.com/Xt7fyim9

Revision history for this message
Mitchell Broome (mitchell-broome) wrote :
Revision history for this message
Dan Prince (dan-prince) wrote :

I'm wondering if this happens because you set force_dhcp_release=False.

I think setting it to True will make what you describe here go away.

Revision history for this message
Dan Prince (dan-prince) wrote :

I'm checking upstream to see if we might possibly change the default value for the force_dhcp_release flag to True if you are using a DHCP capable network manager.

Changed in nova:
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Joe Gordon (jogo) wrote :

essex has been end of lifed a while ago, is this still valid?

Changed in nova:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

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