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表里清除相關記錄。