问题描述
昨天fusion computer的一台CNA节点，突然挂掉了，重启之后也找不到引导，由于vrm管理平台的虚拟机也部署在那个节点上，vrm没做主备部署，导致了vrm管理平台也无法使用,后来重装了那个坏掉的节点和上面的vrm，虽然这个节点坏了，但另一个节点上的虚拟机还是可以用的，当我准备将原先正常的节点添加到新装的vrm的时候，上面的虚拟机突然都没了，使用virsh list --all查询显示为空，好在查看存储发现数据存储并没丢失
存储数据恢复
进入系统查询数据存储位置，发现数据存储在/POME/datastore_1/vol目录下，但是全是磁盘id，也不知道每个磁盘对应哪个虚拟机，不过我发现文件大小并不一样，我知道不同大小的文件对应的是哪种虚拟机，又数了下磁盘文件的数量发现正好与vrm上的虚拟机和虚拟机模板的数量正好相等
本来是想在当前节点创建同类型的虚拟机，将之前的磁盘文件的id修改为新创建的磁盘文件的id，然后覆盖新建虚拟机产生的磁盘文件，于是我就在vrm上添加这台机器，添加报错之后重启节点，服务器起来后网络就不通了，连同网段的主机都ping不通，因为华为fusion computer的分布式交换机底层用的是ovs,于是我对比正常CNA节点看了一下，发现这个节点少了一条output的流表，而且这个节点下的端口也少了两个
我对ovs并不熟，当时只想把数据尽快给恢复出来，就没管网络的事了，想着使用u盘或者移动硬盘把数据拷贝到正常的CNA节点上，结果插上之后不识别NTFS文件系统，需要安装NTFS的驱动，本地并没有NTFS的包，此时又不能联网，只能放弃，后来找了根交叉线直接怼到另一台服务器上，配置IP进行传输，华为的fusion computer对ssh安全的要求比较高，scp传输的时候会验证known_hosts里的key，我是第一次连接那台服务器，报了这个错误
No ECDSA host key is known for 192.168.1.1 and you have requested strict checking. Host key verification failed. lost connection
后来加了这个参数使文件正常传输
scp -o stricthostkeychecking=no /POME/datastore_1/vol/vol_fb5b2975-e6e8-41db-8675-10556bfa8df3/ 192.168.1.1:/home
后面我创建了一个虚拟机，将之前从坏的节点上拷贝的虚拟机磁盘文件名修改成与下面新创建的虚拟机磁盘id相同的文件名，然后覆盖，这个文件夹下有三个文件，一个就是磁盘id命名的img文件了，另一个是snapshot_list.cfg，这里面只写了磁盘id文件名，还有一个是Cnalockfile二进制文件， 我发现当虚拟机从没有开过机的时候是没有这个文件的，那么就可以断定没有Cnalockfile文件的磁盘文件夹就是自己导入的虚拟机模板，有这个文件的就是创建的虚拟机了，拷贝完成后打开虚拟机正常开机，并且是原来的系统
总结经验
- vrm配置主备模式，避免单点故障。
- 当时拷贝在新节点拷贝旧节点的文件时发现，同一个分区拷贝40G的虚拟机的文件花了2个多小时的时间，可能是磁盘坏了，事后更换磁盘
- 遇到事情先来一波冷静分析，理清问题出在什么地方，事后总结问题，从事故中吸取教训
