问题一:Timeout wating on RPC response, topic:"network"

描述:

启动实例一直等待,然后变为error。查看日志,是 timeout waiting on rpc response, topic "network", method: "validate_networks", info:"<Unknown>":

Openstack Havana的两个排错过程-LMLPHP

排错思路:

  1. 查看rabbitmq是否连接,rabbit日志是否报错。这里我使用了web控制台登录进行查看,没有问题。
  2. 查看firewall设置是否正确, 这里满足文档中的设定,因此可以排除。
  3. 查看源码,compute api类调用了network rpc api,然后没有收到响应。这里的主题是network,在rabbitmq中没有发现topic是network的exchange,怀疑是因为network api设定为nova network,而不是neutron。
  4. nova命令行和neutron命令行都可以成功调用。因此,可能是Nova和neutron整合的部分出了问题,也就是nova.conf里面的配置。后来查看neutron的api设置对了,就是nova.network.neutronv2.API。
  5. 不得已将debug打开,发现根本没有正确读取neutron的配置。

Openstack Havana的两个排错过程-LMLPHP

原来是nova.conf中[database]导致的,设置了这个之后,下面的应该都作为database的配置进行读取,从而忽略了neutron的配置。

解决办法:调换位置,将neutron的配置放到[default]下面,然后将[database]放到最后。

问题二:无法使用ssh密钥登录

描述:在使用ubuntu cloud image启动的时候,选择了之前创建的一个密钥,但是启动之后可以ping通却无法ssh登录。

原因:密钥根本没有注入。

Openstack Havana的两个排错过程-LMLPHP

分析:

  1. 密钥注入采用启动时获取metadata的方式,即访问169.254.169.254的地址
  2. 首先虚拟机内部访问该地址,应该有个路由,将169.254.169.254转向网络节点。网络节点收到后,通过iptables的规则发送给metadata-agent,然后metadata-agent请求nova-api-metadata服务,nova返回响应。

排错思路:

  1. 确保网络节点metadata-agent服务启动,确保控制节点8775端口开启。
  2. 查看nova.conf文件,主要看几个东西:
    1. enable_apis里面有metadata这一项,否则,nova-api启动的时候就不会把nova-api-metadata随着启动
    2. service_neutron_metadata_proxy设置为true
    3. neutron_metadata_proxy_shared_secret设置正确,和neutron/metadata_agent.ini 里面配置的相同
  3. 网络节点和计算节点都要配置ip转发:
    net.ipv4.ip_forward=1
  4. 修改完配置后记得重启相应的服务

这时,发现配置没有问题之后,测试还是有错。

考虑到这里是用了flat模式,这样的话,就无法对接metadata-agent了。

因此在搜索neutron flat metadata时,http://developer.rackspace.com/blog/neutron-networking-simple-flat-network.html 里面说:

By specifying the --no_gateway flag and defining a default route manually, we’re able to provide instances with a default route as well as an automatic metadata route to the namespace IP.

因此,删除所有的实例,然后重新建立subnet且不指定gateway,以便于使用metadata:

neutron subnet-create --name sharenet1 --no-gateway --host-route destination=0.0.0.0/0,nexthop=10.109.253.1 --dns-nameserver 10.3.9.4 --allocation-pool start=10.109.253.108,end=10.109.253.150 flat-provider-network 10.109.253.0/24

有路由了:

Openstack Havana的两个排错过程-LMLPHP

这回变为500,查看metadata-agent的log,发现:

Openstack Havana的两个排错过程-LMLPHP

于是将auth_region从RegionOne改为regionOne(略坑).

Openstack Havana的两个排错过程-LMLPHP

成功登录。

参考资料:

什么是openstack的metadata

metadata在OpenStack中的使用(一)

SSH登录虚拟机出现"Read from socket failed: Connection reset by peer"问题的解决办法

04-13 16:55