废话开头：

之前参考这位同学的博客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. 打印出不同顺序的字符串&单引号和双引号的差异

    发现一个很好玩的打印顺序 package com.liaojianya.chapter1; /** * This program demonstrates the string. * @author ...

  2. yii下多条件多表组合查询以及自写ajax分页

    多条件组合查询主要用到yii的CDbCriteria,这个类很多oem框架都有,非常好用. 前台表单 前台查询表单效果是这样的,多个条件组,每个组里放多个input,name为数组.当任何一个复选框被 ...

  3. [网络编程] TCP、UDP区别以及TCP传输原理、拥塞避免、连接建立、连接释放总结

    TCP.UDP都是属于运输层的协议,提供端到端的进程之间的逻辑通信,而IP协议(网络层)是提供主机间的逻辑通信,应用层规定应用进程在通信时所遵循的协议.一.UDP主要特点:传输的是用户数据报协议.1. ...

  4. 结合使用 Oracle Database 11g 和 Python

    结合使用 Oracle Database 11g 和 Python 本教程介绍如何结合使用 Python 和 Oracle Database 11g. 所需时间 大约 1 个小时 概述 Python ...

  5. 【python】【转】Python生成随机数的方法

    如果你对在Python生成随机数与random模块中最常用的几个函数的关系与不懂之处,下面的文章就是对Python生成随机数与random模块中最常用的几个函数的关系,希望你会有所收获,以下就是这篇文 ...

  6. QFTP走了以后QNetworkAccessManager出现了

    QNetworkAccessManager Class Header:    #include <QNetworkAccessManager>qmake:     QT += networ ...

  7. JS面向对象思想（OOP）

    直接看js好了,模拟创建一个奥运会 function 奥运会Class(主题) { // 删除主题 // delete this.主题; this.主题 = 主题; this.开幕时间; this.闭 ...

  8. WPF扩展标记

    标记扩展和 WPF XAML,标记扩展是 XAML 语言以及 XAML 服务的 .NET 实现的常规功能 XAML 处理器和标记扩展 XAML 分析器可将特性值解释为可转换成基元的文本字符串,或可通过 ...

  9. WPF Window对象

    户通过窗口与 Windows Presentation Foundation (WPF) 独立应用程序进行交互.窗口的主要用途是承载可视化数据并使用户可以与数据进行交互的内容.独立 WPF 应用程序使 ...

  10. MVC简单分页（未实现无刷新分页）

    分页Html辅助方法 using System.Text; using System.Web: using System.Web.Mvc; namespace System.Web.Mvc { pub ...