今天需要对实验室 OpenStack 环境中一台虚拟机做实例快照，但是从 horizon 界面和 novaclient 都无法操作，错误提示：无法获取该实例的详情。参考上一篇博客，因为这台虚拟机在数据库中的记录被删除了，我称之为“消失”的虚拟机。最后我通过向数据库中插入该虚拟机的信息，“找回”了这台虚拟机，使得此虚拟机可以重新正常使用。特此记录。
前情回顾
之前误删了很多 nova_api 数据库里 instance_mappings 里的 instance，导致很多虚拟机在 horizon 界面上无法操作。提示如下：
recovery0.png
究其原因，说来话长。
简单来说，OpenStack 目前采用了 cell_v2 架构来管理不同集群的虚拟机。
（关于 cell 的知识参考https://www.jianshu.com/p/653e43a02ddc）
cell 的相关数据表在 nova_api 数据库中，三个数据表的关系如下图：
recovery1.png
当想要获取一个机器的详细信息时 :
1.nova-api 先从 instance_mappings 表拿到 instance 的 cell_id
2.再从 cell_mappings 表拿到所在 cell 的 DB connection
3.直接连接 cell 的 DB 拿到机器的详细信息
之前说虚拟机“消失”了，是因为在 nova_api 的 instance_mappings 表中删除了该虚拟机的记录，导致 nova-api 在响应对虚拟机的操作请求时，在上述第一步就出现了问题。虽然这台虚拟机的记录依然存在于nova数据库的相关表中，但目前已是不可用状态。
要让这台虚拟机恢复正常，变得“可操作”，必须从源头解决问题，即恢复该虚拟机在 instance_mappings 表中的记录。
操作过程
要在 instance_mappings 表中插入虚拟机记录，先看一下 instance_mappings 表：
recovery2.png
需要插入三个数据，instance_uuid、cell_id、project_id。
我们已经知道了虚拟机的 instance_uuid ，从错误提示里复制过来就行 359c8002-301c-4306-8d6b-d0a743cdcf38 ，从 nova 数据库的 instances 表里获得 project_id：
recovery3.png
从 nova_api 数据库的 cell_mappings 表中查看 cell_id：
recovery4.png
id为7。
最后，在 nova_api 数据库的 instance_mappings 表中插入记录：
recovery5.png
好了，怀着忐忑的心情，去 horizon 上操作一下，可以操作了。不出所料，恢复“消失”的虚拟机成功了。
网友评论