I think the response above is only valid when the VM had never been started. If the VM was ever made active it would have been assigned an IP. As a client of DNS i should not be dependent on the VM run state. In fact, nova still reports the IP for the VM regardless of the state. for example: root@gngsvm009d:/opt/contrail/utils# nova show 0cb1d9ab-573a-47a2-9a15-80aa91f274c5 +--------------------------------------+--------------------------------------------------------------------------------------------------+ | Property | Value | +--------------------------------------+--------------------------------------------------------------------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | nova | | OS-EXT-SRV-ATTR:host | gngsvc018d | | OS-EXT-SRV-ATTR:hypervisor_hostname | gngsvc018d | | OS-EXT-SRV-ATTR:instance_name | instance-00000f25 | | OS-EXT-STS:power_state | 4 | | OS-EXT-STS:task_state | - | | OS-EXT-STS:vm_state | stopped | | OS-SRV-USG:launched_at | 2014-12-09T01:39:26.000000 | | OS-SRV-USG:terminated_at | - | | accessIPv4 | | | accessIPv6 | | | config_drive | | | created | 2014-12-09T01:39:13Z | | flavor | jbm-std (097059e7-d6ce-4c23-9fce-4504816771e4) | | hostId | 155ee1eb84b05b3d1ecb5387856122bb664d2b83a74c8fea6c557d00 | | id | 0cb1d9ab-573a-47a2-9a15-80aa91f274c5 | | image | JBM-Primary-Snap (416c6e33-fb6c-4a96-a700-f2a1de22f0cd) | | key_name | - | | metadata | {"delivered_to": "XXX"} | | name | jbm-contrail-vm003 | | os-extended-volumes:volumes_attached | [{"id": "143fb12d-d624-4982-b427-7c51c169c742"}, {"id": "c7aa6705-0e7b-430b-9f27-b33b267dc789"}] | | performance_net network | 192.168.1.8, 10.163.0.8 | | security_groups | default | | status | SHUTOFF | | tenant_id | 2aeeb862495944289c64601f1bd218ca | | updated | 2015-01-25T04:41:48Z | | user_id | 7bb36e4bf9ec4009b706a66fed020dc1 | +--------------------------------------+--------------------------------------------------------------------------------------------------+ also, as a side comment dynamic DNS follows the DHCP lease lifecycle, not a server activity lifecycle. Just because the current implementation has tied these 2 concepts together does not justify the behavior. Further, a floating IP assignment is essentially a static binding and should be valid for the lifetime of the association regardless of the VM activity. This stickiness is very important for clients that exist outside the virtual environment.