OpenStack升级之Nova-volume升级和迁移问题
前面一段时间已经完成了nova-volume从essex到folsom的升级和从nova-volume到cinder的迁移，虽然在升级过程中看上去没什么问题，但是在迁移到cinder时， 原来在essex版nova-volume下创建的卷就有问题了（folsom版下创建的卷能平稳的迁移的到cinder无任何问题），主要表现在以下几个方面：
1.实例中无法访问已经挂载的卷；
2.实例挂载的卷可以卸载，但是再挂载到某个实例的时候报错；
3.通过horizon或nova命令重启实例的时候会因为报卷方面的错误而启动失败（类似：Cannot reboot instance: cannot read header '/dev/disk/by-path/ip-10.61.2.15:3260-iscsi-iqn.2010-10.org.openstack:volume-0000002a-lun-1': Input/output error）。
问题原因
出现这些问题的根本原因是在folsom版的nova-volume和cinder中的volume采用了uuid替换了essex版中表示volume的整形id。在升级nova的时候， 基本上已经把所有的与volume id相关的内容替换成uuid了，但是仍然有两个地方被忽略了：
一是nova数据库中block_device_mapping中的connection_info字段没有更新；
二是做为volume实际存储后端的相应的lvm中的逻辑卷的命名没有更新。
在folsom版的nova-volume中这还没有什么问题，因此它会生成新旧两个版本的tgt配置文件：
[root@store3 ~]# ll /var/lib/nova/volumes/ 总用量 72 -rw-r--r-- 1 nova nova 158 11月 19 22:41 volume-00000006 -rw-r--r-- 1 nova nova 158 11月 19 22:41 volume-0000000b -rw-r--r-- 1 nova nova 158 11月 19 22:41 volume-00000019 -rw-r--r-- 1 nova nova 158 11月 19 22:41 volume-0000001d -rw-r--r-- 1 nova nova 158 11月 19 22:41 volume-00000026 -rw-r--r-- 1 nova nova 158 11月 19 22:41 volume-00000027 -rw-r--r-- 1 nova nova 158 11月 19 22:41 volume-0000002a -rw-r--r-- 1 nova nova 158 11月 19 22:41 volume-0000002d -rw-r--r-- 1 nova nova 214 12月 16 11:31 volume-032f0be8-ec6d-49be-ba44-4b455ad6d54c -rw-r--r-- 1 nova nova 214 12月 16 11:31 volume-57b5633f-d2e3-46dc-852a-c3685ca386c8 -rw-r--r-- 1 nova nova 214 12月 16 11:31 volume-580ef03c-7ced-4b22-9803-0592ebb0c449 -rw-r--r-- 1 nova nova 214 12月 16 11:31 volume-759e09fc-4f86-4648-a2ed-ab77fe53c4b7 -rw-r--r-- 1 nova nova 214 12月 16 11:31 volume-a92be614-4805-41a0-b24d-2d2aee74aede -rw-r--r-- 1 nova nova 214 12月 16 11:31 volume-abb16cd5-700b-46ce-a4a1-1515dd83b4e4 -rw-r--r-- 1 nova nova 214 12月 16 11:31 volume-d04bc03c-b095-478a-8b45-6257bed84afb -rw-r--r-- 1 nova nova 214 12月 16 11:31 volume-d70c9f6c-9883-4ba3-b029-f09fc6411906 -rw-r--r-- 1 nova nova 214 12月 16 11:31 volume-e3427bc5-8f64-41ea-9b2d-96bf8b8a9abd -rw-r--r-- 1 nova nova 214 12月 16 11:31 volume-f4227ba6-6719-4585-848e-68b2a65ae989
这些配置文件内容都形如如下：
[root@store3 ~]# cat /var/lib/nova/volumes/volume-00000006
<target iqn.2010-10.org.openstack:volume-00000006>
backing-store /dev/nova-volumes/volume-00000006
</target>
[root@store3 ~]# cat /var/lib/nova/volumes/volume-032f0be8-ec6d-49be-ba44-4b455ad6d54c
<target iqn.2010-10.org.openstack:volume-032f0be8-ec6d-49be-ba44-4b455ad6d54c>
backing-store /dev/nova-volumes/volume-032f0be8-ec6d-49be-ba44-4b455ad6d54c
</target>
这里最重要的就是这个backing-store配置，它告诉tgt创建iscsi target时把逻辑 LUN1映射到哪个后端的lvm逻辑卷，如果这个对应的lvm逻辑卷不存在的话就只会建立LUN0控制器了， 不会创建LUN1了。而这个lvm逻辑卷是在我们创建volume的时候同时创建的，nova-volume在升级时只会创建新旧的tgt配置文件，而lvm逻辑卷还是用的原来的形如 /dev/nova-volumes/volume-00000006而没有重命名，这样在folsom版中的nova-volume中可以正常使用旧的卷，但是如果从实例上卸载再想重新挂载的话估计也是不可能的。 而在迁移到cinder后就只生成新的tgt配置文件了，但是对应的lvm逻辑卷又没有重命名过来。于是就出现了以上问题。
解决办法
这里我采用比较笨的办法，就是从nova数据库的block_device_mapping表中找出旧的volume-%08x到新的volume-uuid的映射，重命名旧的lvm中的对应的逻辑卷，然后通过horizon 重新挂载相关实例的卷（如果detach卷时报libvirtError: invalid argument: no target device vdc，先reboot下实例即可，detach完成后再reboot实例）。为此我写了个小脚本来帮助找到这种映射关系，并生成重命名lvm逻辑卷的脚本lvrename.sh和恢复脚本re-lvrename.sh。在各个存储节点运行lvrename.sh 然后在Horizon中重新挂载就好了。
[ugyn@ugyn-fedora fix-volume]$ cat volume.sh
#!/usr/bin/env bash
MYSQL_NOVA_HOST=10.61.2.12
MYSQL_NOVA_USER=nova
MYSQL_NOVA_PASSWORD=nova
mysql -h $MYSQL_NOVA_HOST -u $MYSQL_NOVA_USER -p$MYSQL_NOVA_PASSWORD nova \
-e "select volume_id, connection_info from block_device_mapping where deleted = 0" \
| awk '/volume-000000\w\w/ {match($0, /volume-000000\w\w/);print substr($0, RSTART, RLENGTH), "volume-" $1}' \
| sort -u \
| cat > volume-map
cat volume-map \
| awk '{print "lvrename nova-volumes " $0}' \
| cat > lvrename.sh
cat volume-map \
| awk '{print "lvrename nova-volumes " $2, $1}' \
| cat > re-lvrename.sh
chmod u+x *.sh
遗憾的是CentOS6.2测试发现awk不识别/(volume-000000\w{2})/这个正则表达式，我是在F17运行并生成相关文件的。
把/(volume-000000\w{2})/改成/(volume-000000\w\w)/就能在CentOS下正常工作了。
另外不知道awk有没有直接将前面过滤所用的正则表达式匹配的内容输出的方法？？？
北方工业大学 | 云计算研究中心 | 姜永