废话开头：

之前参考这位同学的博客http://www.cnblogs.com/awy-blog/p/3447176.html，同时综合OpenStack的ubuntu的官方安装文档，在修改了一些小错误之后，成功地用三台普通的物理PC机搭了一个OpenStack的环境，各项服务、功能都测试了一遍，感觉还可以。不过后来，由于其中的一台物理机被别人拿走之后，于是乎没继续使用测试了，转而去研究代码了。

后来，由于某种需求，又要开重新搭建这个环境。没有够多的物理机，于是乎开始使用楼下的一台刀片服务器来完了，12核24线程、40多G的大内存，4块500G的硬盘，够给力了，跑三个虚拟机来搭OpenStack的环境也绰绰有余了。但是，搭完之后，问题就来了，发现无法向虚机注入密钥，也就是用ssh密钥登录虚机了。这对那些必须需要使用密钥登录的镜像来说还是有很大的不便。

下面开始步入正题：

在node4上面架设三个kvm的虚机，分别跑controller、network、compter，现在已经成功把openstack跑起来了，可以运行实例，neutron组网没问题，虚机内外网都能ping通，但是当我想用ssh密钥登录时发现：先前导入的密钥对，无法将公钥导入到虚机中，以至于没法实现密钥登录。
 

虚机起来后，查看日志/var/log/nova/nova-api.log ：

2014-03-08 15:36:02.347 16855 INFO nova.metadata.wsgi.server [-] (16855) accepted ('192.168.122.3', 55466)

2014-03-08 15:36:02.349 16855 WARNING nova.api.metadata.handler [-] X-Instance-ID-Signature: ed0c9bbac98384bb1d4f2b0923e33488af7ac2fbbaac0aef6fe2b80257cded79 does not match the expected value: 93008c9f8f5a8ddda5a9fd48fb29b53db2e2ef1c76684ef4f6e5152fc951885d for id: c011b486-3cfd-4e33-8fb8-526abe1e51fb. Request From: 10.50.50.2

2014-03-08 15:36:02.350 16855 INFO nova.api.ec2 [-] 0.1089s 192.168.122.3 GET /2009-04-04/meta-data/public-hostname None:None 403 [Python-httplib2/0.7.2 (gzip)] text/plain text/plain

2014-03-08 15:36:02.350 16855 INFO nova.metadata.wsgi.server [-] 10.50.50.2,192.168.122.3 "GET /2009-04-04/meta-data/public-hostname HTTP/1.1" status: 403len: 176 time: 0.0018518

2014-03-08 15:36:02.865 16855 WARNING nova.api.metadata.handler [-] X-Instance-ID-Signature: ed0c9bbac98384bb1d4f2b0923e33488af7ac2fbbaac0aef6fe2b80257cded79 does not match the expected value: 93008c9f8f5a8ddda5a9fd48fb29b53db2e2ef1c76684ef4f6e5152fc951885d for id: c011b486-3cfd-4e33-8fb8-526abe1e51fb. Request From: 10.50.50.2

2014-03-08 15:36:02.867 16855 INFO nova.api.ec2 [-] 0.1279s 192.168.122.3 GET /2009-04-04/meta-data/placement/availability-zone None:None 403 [Python-httplib2/0.7.2 (gzip)] text/plain text/plain

2014-03-08 15:36:02.868 16855 INFO nova.metadata.wsgi.server [-] 10.50.50.2,192.168.122.3 "GET /2009-04-04/meta-data/placement/availability-zone HTTP/1.1" status: 403len: 176 time: 0.0024281

在dashboard的界面里面，查看虚机的日志中提示错误：

checking http://169.254.169.254/2009-04-04/instance-id
failed 1/20: up 10.44. iid had '<html>
<head>
<title>500 Internal Server Error</title>
</head>
<body>
<h1>500 Internal Server Error</h1>
An unknown error has occurred. Please try your request again.<br /><br />

而当我登录虚拟，查看里面的~/.ssh/authorized_keys里面内容不是要注入的公钥，正是上面出错的html页面代码！

在虚机中运行curl检测如下：

$ curl -I http://169.254.169.254/2009-04-04/meta-data/instance-id

HTTP/1.1 500 Internal Server Error

Content-Type: text/html; charset=UTF-8

Content-Length: 0

Date: Sat, 08 Mar 2014 09:45:57 GMT

 
我知道应该是nova-api-metadata的问题， 但这个该怎么解决呢？
 
      开始，我也觉得是网络的问题，总感觉169.254.169.254很奇怪，后来一搜才知道是为了兼容 amazon 的 EC2 ，才把获取metadata的ip也写死成这个，不过在openstack里面，通过iptables映射成controller的ip并对应8775端口。从nova-api.log的日志分析，显然在computer的虚机10.50.50.2的请求，是已经被在controller的nova-api-metadata的服务获取到了。但是 “WARNING nova.api.metadata.handler [-] X-Instance-ID-Signature”，这说明X-Instance-ID-Signature 验证不通过，导致metadata server 拒绝请求，从而引发了：10.50.50.2,192.168.122.3 "GET /2009-04-04/meta-data/public-hostname HTTP/1.1" status: 403 len: 176 time: 0.0018518，即服务端返回403的错误代码，而在虚机中则得到了HTTP 500的错误响应。
 
    后来问题搞定了，当我去分别查找Network node 上面的nova/api/metadata/handler.py ，以及在网络节点的neutron/agent/metadata/agent.py 去比较如何处理X-Instance-ID-Signature的时候，发现如下：
 
         if resp.status == 200:

             LOG.debug(str(resp))

             return content

         elif resp.status == 403:

             msg = _(

                 'The remote metadata server responded with Forbidden. This'

                 'response usually occurs when shared secrets do not match.'

            )

             LOG.warn(msg)

             return webob.exc.HTTPForbidden()

         elif resp.status == 404:

             return webob.exc.HTTPNotFound()

         elif resp.status == 409:

             return webob.exc.HTTPConflict()

         elif resp.status == 500:

             msg = _(

                 'Remote metadata server experienced an internal server error.'

             )

             LOG.warn(msg)

             return webob.exc.HTTPInternalServerError(explanation=unicode(msg))

         else:

             raise Exception(_('Unexpected response code: %s') % resp.status)

显然提示403出错的代码，是因为“The remote metadata server responded with Forbidden. This response usually occurs when shared secrets do not match.”，即提示 share secrets 不匹配。这个我很早就注意到了，网上的提示的方法也是这么说的。我当时很确定地把nova.conf 的service_neutron_metadata_proxy 设为true，并且neutron_metadata_proxy_shared_secret 跟neutron里面的metadata_agent.ini一样都是helloOpenStack，这个是我反复检查过的。可是，让我万万没想到的是。。。。。。。
 
当我vim查看metadata_agent.ini的文件时，无意间看到一句comment：
 
# When proxying metadata requests, Neutron signs the Instance-ID header with a
# shared secret to prevent spoofing. You may select any string for a secret,
# but it must match here and in the configuration used by the Nova Metadata
# Server. NOTE: Nova uses a different key: neutron_metadata_proxy_shared_secret
 
 
我靠！nova.conf与metadata_agent.ini里面关于share secret 的字段名是不一样的！！！一个是neutron_metadata_proxy_shared_secret,而另一个却是metadata_proxy_shared_secret
 
    天杀的，好大一个坑。。。。。。。。。
    
 
关于metadata的注入流程分析，可以参考贤哥的两篇文章：

【OpenStack】metadata在OpenStack中的使用：

http://blog.csdn.net/lynn_kong/article/details/9115033

　　　　　　　　　　　　　　　　　　　　　　　　   http://lingxiankong.github.io/blog/2014/03/25/metadata/
 
 
　　　　　　　　　　

Nova 无法向虚机注入密钥的更多相关文章

  1. Nova: 虚机的块设备总结 [Nova Instance Block Device]

    和物理机一样,虚拟机包括几个重要的部分:CPU.内存.磁盘设备.网络设备等.本文将简要总结虚机磁盘设备有关知识. 1. Nova boot CLI 中有关虚机块设备的几个参数 nova boot CL ...

  2. 转 Nova: 虚机的块设备总结 [Nova Instance Block Device]

    和物理机一样,虚拟机包括几个重要的部分:CPU.内存.磁盘设备.网络设备等.本文将简要总结虚机磁盘设备有关知识. 1. Nova boot CLI 中有关虚机块设备的几个参数 nova boot CL ...

  3. Nova 操作汇总（限 libvirt 虚机） [Nova Operations Summary]

    本文梳理一下 Nova 主要操作的流程. 0. Nova REST-CLI-Horizon 操作对照表 Nova 基本的 CRUD 操作和 extensions: # 类别 Nova V2 REST ...

  4. Openstack之Nova创建虚机流程分析

    前言        Openstack作为一个虚拟机管理平台,核心功能自然是虚拟机的生命周期的管理,而负责虚机管理的模块就是Nova. 本文就是openstack中Nova模块的分析,所以本文重点是以 ...

  5. openstack nova 虚机镜像后端提取

    参考链接:https://www.cnblogs.com/storymedia/p/4500186.html 1.nova 创建的虚机后端目录 其中的base是虚机基础镜像,创建虚机会根据这个基础镜像 ...

  6. nova start 虚机的代码流程分析

    nova start 虚机的代码流程分析,以ocata版本为分析基础1.nova api服务接受用户下发的 nova start启动虚机请求其对应的http restfull api接口为post / ...

  7. OpenStack 虚机网卡的创建过程

    原文链接:https://www.cnblogs.com/potato-chip/p/9127083.html OpenStack虚机网卡的创建过程 OpenStack最基本和常用的操作就是启动虚机. ...

  8. OpenStack虚机网卡的创建过程

    OpenStack虚机网卡的创建过程 OpenStack最基本和常用的操作就是启动虚机.虚机启动的过程中涉及很多内容,其中非常重要的一个环节就是创建并绑定虚机的虚拟网卡.虚机的创建和管理是Nova的任 ...

  9. openstack环境-解决windows虚机重启后比当前时间晚8小时问题

    背景: 生产环境下,发现windows虚机每次重启,时间都会倒退到虚机的格林威治时间(+8小时才是北京时间),也就是比当前时间晚8小时.测试发现,windows虚机所用的镜像,缺少了一个os_type ...

随机推荐

  1. 线程池ThreadPoolExecutor使用简介

    一.简介 线程池类为 java.util.concurrent.ThreadPoolExecutor,常用构造方法为: ThreadPoolExecutor(int corePoolSize, int ...

  2. 如何使用event 10049分析定位library cache lock and library cache pin

    Oracle Library Cache 的 lock 与 pin 说明 一. 相关的基本概念 之前整理了一篇blog,讲了Library Cache 的机制,参考: Oracle Library c ...

  3. Masonry等比缩放

    第一种: CGFloat width = CGRectGetWidth([[UIScreen mainScreen] bounds]);         CGFloat aspectRatio = 1 ...

  4. ios后台程序持续运行方法

    iOS系统的资源是有限的,应用程序在前台和在后台的状态是不一样的.在后台时,程序会受到系统的很多限制,这样可以提高电池的使用和用户体验.但是有很多社交类的软件,如果因为它在后台就不能刷新到新的数据的话 ...

  5. FXBlurView用法

    FXBlurView是UIView的子类,它实现毛玻璃效果的原理其实就是覆盖上一层FXBlurView的实例对象. - (void)viewDidLoad { [super viewDidLoad]; ...

  6. ACM HDU 1021 Fibonacci Again

    #include<iostream> using namespace std; int main() { int n; while(cin>>n) { if((n+1)%4== ...

  7. PHP实战开发教程

    对于PHP初学者来说,一上手就学习庞大的PHP语法无疑很打击自信心.其实即便是很熟练的程序员,也未必对所有的语法非常熟悉.通常熟练的程序员比普通的程序员的优势在于对基本语法的理解非常透彻,而且常用的一 ...

  8. fedora22 无法联网的情况下rpm安装gcc5.1

    前天发生件很不幸的事.我在给ubuntu14.04安装NVIDIA显卡驱动的时候,想清空下一个目录,什么目录我也忘了,当时我正好切到root身份(平常我很少切root的),命令格式如下 rm -fr ...

  9. IS脚本学习

    OnFirstUIBefore:函数块用于第一安装应用时安装部件前所要完成的任务.一般在这里进行下列设: 1. 设置屏蔽 2. 显示欢迎信息,软件协议书或关于软件安装的其他说明信息 3. 从用户处获取 ...

  10. 精通 Oracle+Python，第 3 部分：数据解析

    进行数据解析的理由不计其数,相关的工具和技巧也同样如此.但是,当您需要用这些数据做一些新的事情时,即使有“合适的”工具可能也是不够的.这一担心对于异类数据源的集成同样存在.用来做这项工作的合适工具迟早 ...