FYI we're also hitting this on trusty/mitaka for what looks like incompletely deleted instances:
* still running at hypervisor, ie virsh dominfo UUID # shows it ok * deleted both at nova 'instances' and 'block_device_mapping' tables. Once certain it's still running at hypervisor, our workaround is to revive the instance at nova DB with something like: mysql> begin work; mysql> update instances set vm_state='active', deleted=0, deleted_at=NULL where uuid='<UUID>'; mysql> update block_device_mapping set deleted=0, deleted_at=NULL where instance_uuid='<UUID>'; mysql> commit work; Note also it has happened to us from failed migrations (ie instance shown at the 'wrong' host at nova DB), we've fixed those by adding to the 1st SQL host='<service_hostname>', node='<hypervisor_hostname>', with above hostname-s as: - <service_hostname> from nova service-list - <hypervisor_hostname> from nova hypervisor-list -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1602057 Title: [SRU] (libvirt) KeyError updating resources for some node, guest.uuid is not in BDM list To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1602057/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
