openstack常见11种错误总结

以下主要为安装部署过程中遇到的一些问题，因为openstack版本问题，带来的组件差异导致不同的版本安装的方法也完全不一样。经过测试，目前已可成 功部署Essex和Grizzly两个版本，其中间还有个版本是Folsom,这个版本没有部署成功，也没有花太多时间去研究，因为Folsom版本中使 用的quantum组件还不成熟，对于网络连通性还有很多问题，网上也很少有成功的案例，大多数人使用的还是folsom+nova-network模 式。

到了Grizzly版本，quantum组件才比较稳定，可以正常使用，自己也花了很多时间研究，现在已可以成功部署多节点环境。以下是部署过程中遇到的 一些问题，包括Essex和Grizzly两个版本。国内网上关于这方面的资料很少，很多资料也都是国外网站上看到的。而且很多情况下日志错误信息相同， 但导致错误的原因却不尽相同，这时候就需要仔细分析其中的原理，才能准确定位。遇到错误并不可怕，我们可以通过对错误的排查加深对系统的理解，这样也是好 事。

关于安装部署，网上有一些自动化的部署工具，如devstack和onestack，一键式部署。如果你是初学者，并不建议你使用这些工具，很明显，这样 你学不到任何东西，不会有任何收获。如果没有问题可以暂时恭喜你一下，一旦中间环节出现错误信息，你可能一头雾水，根本不知道是哪里错了，加之后期的维护 也是相当困难的。你可能需要花更多的时间去排查故障。因为你根本不了解中间经过了哪些环节，需要做哪些配置！这些工具大多数是为了快速部署开发环境所用， 正真生产环境还需要我们一步一步来操作。这样有问题也可快速定位排查错误。

本文仅是针对部署过程中的一些错误信息进行总结梳理，并给予解决办法，这些情况是在我的环境里遇到的，并成功解决的，可能会因为环境的不同而有所差异，仅供参考。

1、检查服务是否正常

1. root@control:~# nova-manage service list
   
2. 
   
3. Binary           Host                                 Zone             Status     State Updated_At
   
4. 
   
5. nova-cert        control                              internal         enabled    :-)   2013-04-26 02:29:44
   
6. 
   
7. nova-conductor   control                              internal         enabled    :-)   2013-04-26 02:29:42
   
8. 
   
9. nova-consoleauth control                              internal         enabled    :-)   2013-04-26 02:29:44
   
10. 
    
11. nova-scheduler   control                              internal         enabled    :-)   2013-04-26 02:29:47
    
12. 
    
13. nova-compute     node-01                              nova             enabled    :-)   2013-04-26 02:29:46
    
14. 
    
15. nova-compute     node-02                              nova             enabled    :-)   2013-04-26 02:29:46
    
16. 
    
17. nova-compute     node-03                              nova             enabled    :-)   2013-04-26 02:29:42
    

复制代码

如果看到都是笑脸状态，说明nova的服务属于正常状态，如果出现XXX，请查看该服务的相关日志信息，在/var/log/nova/下查看，通过日志一般可以分析出错误的原因。

 

2、libvirt错误

1. python2.7/dist-packages/nova/virt/libvirt/connection.py”, line 338, in _connect
   
2. 2013-03-0917:05:42 TRACE nova return libvirt.openAuth(uri, auth, 0)
   
3. 2013-03-09 17:05:42 TRACE nova File “/usr/lib/python2.7/dist-packages/libvirt.py”, line 102, in openAuth
   
4. 2013-03-09 17:05:42 TRACE nova if ret is None:raise libvirtError(‘virConnectOpenAuth() failed’)
   
5. 2013-03-09 17:05:42 TRACE nova libvirtError: Failed to connect socket to ‘/var/run/libvirt/libvirt-sock’: No such file or directory
   
6. 2013-03-09 22:05:41.909+0000: 12466: info : libvirt version: 0.9.8
   
7. 2013-03-09 22:05:41.909+0000: 12466: error : virNetServerMDNSStart:460 : internal error Failed to create mDNS client: Daemon not running
   

复制代码

解决方案：

出现这种错误首先要查看/var/log/libvirt/libvirtd.log日志信息，日志里会显示：libvirt-bin service will not start without dbus installed.

我们再查看ps –ea|grep dbus，确认dbus is running，然后执行apt-get install lxc

 

3、Failed to add image

1. Error：
   
2. Failed to add image. Got error:
The request returned 500 Internal Server Error
   

复制代码

 

解决方案：

环境变量问题，配置环境变量，在/etc/profile文件中新增：

 

1. OS_AUTH_KEY=”openstack”
   
2. OS_AUTH_URL=”http://localhost:5000/v2.0/”
   
3. OS_PASSWORD=”openstack”
   
4. OS_TENANT_NAME=”admin”
   
5. OS_USERNAME=”admin”
   

复制代码

然后执行source  /etc/profile即可！当然你也可以不在profile里配置环境变量，但是只能临时生效，重启服务器就很麻烦，所以建议你还是写在profile里，这样会省很多麻烦。

 

4、僵尸实例的产生

僵尸实例一般是非法的关闭nova或者底层虚拟机，又或者在实例错误时删除不了的错误，注意用virsh list检查底层虚拟机是否还在运行，有的话停掉，然后直接进入数据库删除。

1. Nova instance not found
   
2. 
   
3. Local file storage of the image files.
   
4. 
   
5. Error:
   
6. 2013-03-09 17:58:08 TRACE nova raise exception.InstanceNotFound(instance_id=instance_name)
   
7. 2013-03-09 17:58:08 TRACE nova InstanceNotFound: Instance instance-00000002 could not be found.
   
8. 2013-03-09 17:58:08 TRACE nova
   

复制代码

解决方案：

删除数据库中的僵尸实例或将数据库删除重新创建：

a、删除数据库：

1. $mysql –u root –p
   
2. DROP DATABASE nova;
   
3. 
   
4. Recreate the DB:
   
5. CREATE DATABASE nova; (strip formatting if you copy and paste any of this)
   
6. GRANT ALL PRIVILEGES ON nova.* TO ‘novadbadmin’@'%’ IDENTIFIED BY ‘<password>’;
   
7. Quit
   
8. 
   
9. Resync DB
   

复制代码

b、删除数据库中的实例：

1. #!/bin/bash
   
2. 
   
3. mysql -uroot -pmysql << _ESXU_
   
4. 
   
5. use nova;
   
6. 
   
7. DELETE a FROM nova.security_group_instance_association
   
8. 
   
9. AS a INNER JOIN nova.instances AS b
   
10. 
    
11. ON a.instance_uuid=b.id where b.uuid='$1';
    
12. 
    
13. DELETE FROM nova.instance_info_caches WHERE instance_uuid='$1';
    
14. 
    
15. DELETE FROM nova.instances WHERE uuid='$1';
    
16. 
    
17. _ESXU_
    

复制代码

将以上文件写入delete_insrance.sh中，然后执行sh delete_instrance.sh insrance_id;

其中instrance_id可以通过nova list 查看。

 

5、Keystone NoHandlers

1. Error  
   
2. root@openstack-dev-r910:/home/brent/openstack# ./keystone_data.sh  
   
3. No handlers could be found for logger “keystoneclient.client”  
   
4. Unable to authorize user  
   
5. No handlers could be found for logger “keystoneclient.client”  
   
6. Unable to authorize user  
   
7. No handlers could be found for logger “keystoneclient.client”  
   
8. Unable to authorize user  

复制代码

 

解决方案：

出现这种错误是大多数是由于keystone_data.sh有误，其中

admin_token必须与/etc/keystone/keystone.conf中相同。然后确认keystone.conf中有如下配置：

driver = keystone.catalog.backends.templated.TemplatedCatalog template_file = /etc/keystone/default_catalog.templates

 

6、nova-compute挂掉与时间同步的关系

很多时候发现nova-compute挂掉，或者不正常了，通过nova-manage查看状态是XXX了。

往往是nova-compute的主机时间和controller的主机时间不一致。 nova-compute是定时地往数据库中services这个表update时间的，这个时间是nova-compute的主机时间。

controller校验nova-compute的存活性是以controller的时间减去nova-compute的update时间，如果大于多少秒（具体数值代码里面有，好像是15秒）就判断nova-compute异常。

这 个时候你用nova-manage查看nova-compute状态是XXX，如果创建虚拟机，查看nova-scheduler.log 就是提示找不到有效的host 其他服务节点类同，这是nova心跳机制问题。所以讲nova环境中各节点时间同步很重要。一定要确保时间同步！！

如果在dashboard上看nova-compute状态，可能一会儿变红，一会儿变绿。那就严格同步时间，或者找到代码，把上面的那个15秒改大一点。

 

7、noVNC不能连接到实例

novnc的问题比较多，网上也有关于这方面的很多配置介绍，其实配置不复杂，只有四个参数，配置正确基本上没什么大问题，但是装的过程中还是遇到了不少的问题。

a、提示“Connection Refuesd”

可能是控制节点在收到vnc请求的时候，无法解析计算节点的主机名，从而无法和计算节点上的实例建立连接。

另外可能是，当前浏览器不支持或者不能访问，将计算节点的ip和主机名的对应关系加入到控制节点的/etc/hosts文件中。

b、提示“failed connect to server”

出 现这种错误的情况比较多，有可能是配置文件的错误，我们的环境中遇到这个错误是因为网络源有更新，导致安装版本不一致，使组件无法正常使用，解决方法就是 使用本地源。另外需要特别说明的是使用novnc的功能需要浏览器支持Web Socket和HTML5.推荐使用谷歌。

 

8、Unable to attach cinder volume to VM

     在测试openstack中的volume服务时把lvm挂载到虚拟机实例时失败，这其实不是cinder的错误，是iscsi挂载的问题。

以下是计算节点nova-compute.log 的错误日志：

1. 2012-07-24 14:33:08 TRACE nova.rpc.amqp ProcessExecutionError: Unexpected error while running command.
   
2. 2012-07-24 14:33:08 TRACE nova.rpc.amqp Command: sudo nova-rootwrap iscsiadm -m node -T iqn.2010-10.org.openstack:volume-00000011 -p 192.168.0.23:3260 –rescan
   
3. 2012-07-24 14:33:08 TRACE nova.rpc.amqp Exit code: 255
   
4. 2012-07-24 14:33:08 TRACE nova.rpc.amqp Stdout: ”
   
5. 2012-07-24 14:33:08 TRACE nova.rpc.amqp Stderr: ‘iscsiadm: No portal found.\n’

复制代码

以上错误是没有找到iscsi服务端共享出的存储，查找了很多openstack 资料说要添加以下两个参数：

iscsi_ip_prefix=192.168.80 #openstack环境内网段

iscsi_ip_address=192.168.80.22 # volume机器内网IP

可是问题依然无法解决，后来发现只要在nova.conf配置文件中添加参数iscsi_helper=tgtadm 就挂载失败。

根据这个情况进行了测试查看日志才发现：如果使用参数 ：iscsi_helper=tgtadm 时就必须使用 tgt 服务，反之使用iscsitarget服务再添加参数iscsi_helper=ietadm。

我 测试环境的问题是tgt和iscsitarget服务都已安装并运行着（在安装nova-common时会把tgt服务也安装上，这个不小心还真不会发 现），在nova.conf配置中添加参数iscsi_helper=tgtadm ，查看端口3260 发现是iscsitarget服务占用，所以导致挂载失败，我们可以根据情况来使用哪个共享存储服务！！将tgt 和iscsi_helper=tgtadm、iscsitarget和iscsi_helper=ietadm保留一个即可。

 

9、glance index报错：

1. Authorization Failed: Unable to communicate with identity service: {"error": {"message": "An unexpected error prevented the server from fulfilling your request. Command 'openssl' returned non-zero exit status 3", "code": 500, "title": "Internal Server Error"}}. (HTTP 500)
   

复制代码

在 Grizzly 版，我测试 glance index 时候报错：

Authorization Failed: Unable to communicate with identity service: {"error": {"message": "An unexpected error prevented the server from fulfilling your request. Command 'openssl' returned non-zero exit status 3", "code": 500, "title": "Internal Server Error"}}. (HTTP 500)

错误信息指出：glance 没有通过keystone验证，查看了 keystone 日志，报错如下：

2677 2013-03-04 12:40:58    ERROR [keystone.common.cms] Signing error: Error opening signer certificate /etc/keystone/ssl/certs/signing_cert.pem2678 139803495638688:error:02001002:system library:fopen:No such file or directory:bss_file.c:398:fopen('/etc/keystone/ssl/certs/signing_cert.pem','r')2679 139803495638688:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:400:2680 unable to load certificate2682 2013-03-04 12:40:58    ERROR [root] Command 'openssl' returned non-zero exit status 32683 Traceback (most recent call last):2684   File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 231, in __call__2685     result = method(context, **params)2686   File "/usr/lib/python2.7/dist-packages/keystone/token/controllers.py", line 118, in authenticate2687     CONF.signing.keyfile)2688   File "/usr/lib/python2.7/dist-packages/keystone/common/cms.py", line 140, in cms_sign_token2689     output = cms_sign_text(text, signing_cert_file_name, signing_key_file_name)2690   File "/usr/lib/python2.7/dist-packages/keystone/common/cms.py", line 135, in cms_sign_text2691     raise subprocess.CalledProcessError(retcode, "openssl")2692 CalledProcessError: Command 'openssl' returned non-zero exit status 3

在Grizzly 版中，keystone 默认验证方式是 PKI , 需要签名证书，之前的版本都是用的 UUID，改 keystone.conf:

token_format = UUID

在试一次就没有错误了。

 

10、镜像制作

这里主要强调下windows的镜像制作，因为windows的涉及到加载驱动的问题，就比较麻烦。

下载virtio 驱动，因为win默认不支持virtio驱动，而通过openstack管理虚拟机是需要virtio驱动的。需要两个virtio驱动，一个是硬盘的， 一个是网卡的，即：virtio-win-0.1-30.iso和virtio-win-1.1.16.vfd。这里主要强调两个地方：

1、创建镜像：

1. kvm -m 512 -boot d –drive  
   
2.   
   
3. ile=win2003server.img,cache=writeback,if=virtio,boot=on -fda virtio-win-1.1.16.vfd -cdrom w

复制代码

2、引导系统 ：

1. kvm -m 1024 –drive file=win2003server.img,if=virtio,
   
2. 
   
3. boot=on -cdrom virtio-win-0.1-30.iso -net nic,model=virtio -net user -boot c -nographic -vnc 8
   

复制代码

这 里需要注意的地方是if=virtio,boot=on –fda virtio-win-1.1.16.vfd和引导系统时使用的virtio-win-0.1-30.iso 这两个驱动分别是硬盘和网卡驱动。如果不加载这两个驱动安装时会发现找不到硬盘，并且用制作好的镜像生成实例也会发现网卡找不到驱动，所以在这里安装镜像 生成后需要重新引导镜像安装更新网卡驱动为virtio。

11、删除僵尸volume


如果cinder服务不正常，我们在创建volume时会产生一些僵尸 volume，如果在horizon中无法删除的话，我们需要到服务器上去手动删除，命令：lvremove /dev/nova-volumes/volume-000002注意这里一定要写完整的路径，不然无法删除，如果删除提示：“Can't remove open logical volume“ 可尝试将相关服务stop掉，再尝试删除。删除完还需到数据库cinder的volumes表里清除相关记录。