您的位置:首页 > 运维架构

openstanc juno 配置迁移过程及碰到的问题

2015-05-04 18:28 288 查看
配置迁移过程:参照:http://blog.csdn.net/xtdxhw/article/details/9040201

1、确保主机名:IP之间能过互相ping通

2、配置NFS共享文件

apt-get install nfs-kernel-server  

mkdir -p /var/nfs-storage  

编辑/etc/exports文件 /var/nfs-storage  *(insecure,rw,sync,no_root_squash)

service nfs-kernel-server 

3、挂载NFS目录到/var/lib/nova/instances下

apt-get install nfs-common

mount 192.168.100.51:/var/nfs-storage /var/lib/nova/instances

修改/etc/fstab 添加开机挂载

192.168.100.51:/var/nfs-storage /var/lib/nova/instances   nfs   defaults   0    0 

4、修改计算节点下nova用户的UID,nova组的GID,让各计算节点的UID和GID保持一致

(1)修改nova UID和GID 

vim /etc/passwd /bin/false -> /bin/bash or /bin/sh

vim /etc/group 

由于各个计算节点nova用户创建时可能会获取不同的UID和GID所以需要修改成一致的

否则有可能出现权限问题

(2)设置nova用户的密码 root下 passwd nova  

(3)切换到nova用户下,设置各compute节点之间免密码ssh登录

ssh-keygen

cd /var/lib/nova/.ssh  (/var/lib/nova/为/etc/passwd中nova的目录)

scp id_rsa.pub nova@192.168.100.57:~/.ssh/authorized_keys 

5、 配置libvirt相关文件

修改每个计算节点

(1)修改/etc/libvirt/libvirtd.conf文件

改前 : #listen_tls = 0  

改后 : listen_tls = 0  

改前 : #listen_tcp = 1  

改后 : listen_tcp = 1  

添加(有了的话,不需要添加): auth_tcp = "none"

(2)修改/etc/init/libvirt-bin.conf文件:

改前 : env libvirtd_opts="-d "  

改后 :env libvirtd_opts="-d -l"    

(3)修改/etc/default/libvirt-bin:

改前 :libvirtd_opts=" -d"  

改后 :libvirtd_opts=" -d -l"  

(4)用uuidgen产生一个uuid号

root@g-compute3:/var/lib/nova# uuidgen   

f4ef4243-1ad4-4818-a4cf-abfc1979a7ce 

(5)复制常生的uuid号,并修改/etc/libvirt/libvirtd.conf文档,

将上面的host_uuid 改成刚刚产生的那个号,并把注释去掉。

(6)重新启动libvirt-bin:

service libvirt-bin restart  

6、修改nova.conf文件(添加)

live_migration_bandwidth=0  

live_migration_retry_count=30  

live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE  

7、重启nova-compute 服务

碰到的问题以及解决办法:

1、热迁移过程要求必须配置共享存储,现在NFS形式的测试成功

2、迁移故障排除故障过程

(1)首先查看控制节点/var/log/nova-api.log,会展示出迁移执行前准备过程的故障.

a、目标节点资源不足(内存不足)导致无法迁移的问题,由于使用的是4G内存,只能清其他虚拟机

b、目标节点nova-compute服务不可用,检查目标节点nova-compute服务状态排除故障,使用nova service-list服务均为up状态即为可用

c、Live Migration failure: Invalid value '1,3,5,7,9,11,13,15' for 'cpuset.cpus': Invalid argument CPU型号不一致会导致迁移失败,更换CPU后,改报错消失

(2)查看源节点/var/log/nova/nova-compute.log

a、Live Migration failure: operation failed: Failed to connect to remote libvirt URI qemu+tcp://ztb5/system: unable to connect to server at 'ztb5:16509': Connection refused

即 目标节点16905端口拒绝被访问

目标节点 执行 netstat -nlp|grep libvirt 

tcp6       0      0 :::16509                :::*                    LISTEN      3091/libvirtd

对比源节点发现缺少

tcp        0      0 0.0.0.0:16509           0.0.0.0:*               LISTEN      3091/libvirtd 

重启 service libvirtd-bin restart 后该端口被监听

b

(3) 查看目标节点 /var/log/nova/nova-compute.log 发现报无权限修改 libvirtd.xml文件,导致实例一直处于迁移中状态,判断应该是权限问题

初始解决办法是chmod -R 777 /var/lib/nova/instances,但新建实例后还是迁移出现权限问题

后分析主要由于 修改/etc/passwd 中nova的UID和GID不一致导致,将计算节点nova的UID和GID修改一致,不再出现权限问题

由修改nova的UID和GID导致的问题:由于参照源节点的UID和GID修改目标节点,而UID和GID已经被占用,导致新建的虚拟机和配置文件日志文件均属于其他用户或者显示数值如 118:127形式

后修改时需要注意所以与nova相关文件均需修改:如: /etc/nova  /var/lib/nova  /var/log/nova 这里需参照源节点修改不可以暴力使用 chmod nova:nova /xx/xx形式 因为有些文件可能是归属于root
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息