废话开头：

之前参考这位同学的博客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. SQL SERVER 高级编程 - 自定义函数 拾忆

    每个人都很忙,但是花10分钟复习下,总结下基础东西还是很有益处的. 背景: 总结一句,使用简便,还能递归,是的SQL更简洁,相对比一大堆的关联语句,而且关联一大堆还不一定实现特定功能.而且共用部分可以 ...

  2. Css 梯形图形 并添加文字

    HTML页面的代码: <body> <div style="width:500px;border:solid 1px #ccc;"> <div> ...

  3. UITabBar的隐藏

    方式一: // 重写导航控制器的push方法 - (void)pushViewController:(UIViewController *)viewController animated:(BOOL) ...

  4. LINQ 101——分区、Join、聚合

    一.Partitioning 分区 Take 例1:取前3个数 static void Linq1() { , , , , , , , , , }; ); Console.WriteLine(&quo ...

  5. (正则表达式应用) 替换自闭合标签（self-closing tag）的method

    var str = "<sup><div class=\"he's\"/></sup><span id=\"cs\&q ...

  6. 数据库（学习整理）----7--Oracle多表查询，三种join连接

    聚合函数:(都会忽略null数据) 常用的有5种:将字段中所有的数据聚合在一条中 .sum(字段名) :求总和 .avg(字段名) :求平均值 .max(字段名) :求最大值 .min(字段名) :求 ...

  7. java_设计模式_状态模式_State Pattern（2016-08-16）

    定义: 当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类. 类图: 状态模式所涉及到的角色有: ● 环境(Context)角色,也成上下文:定义客户端所感兴趣的接口,同时维护一个 ...

  8. [LeetCode OJ] Sort Colors

    Given an array with n objects colored red, white or blue, sort them so that objects of the same colo ...

  9. Google HTML/CSS/JS代码风格指南

    JS版本参见:http://www.zhangxinxu.com/wordpress/2012/07/google-html-css-javascript-style-guides/ HTML/CSS ...

  10. 我的接口框架---框架函数文件common.php

    <?php defined('JDHU') OR die('no allow access'); /** * 加载配置文件 */ function &get_config($replac ...