uuid怎么获取_OpenStack虚拟机如何获取metadata

最新推荐文章于 2024-06-25 10:43:08 发布
最新推荐文章于 2024-06-25 10:43:08 发布
阅读量1.3k 收藏 2
点赞数
文章标签： uuid怎么获取 两个openstack网络互通 主机到虚拟机22端口不通 前端代码怎么获取本机ip发给后端 查看虚拟机ip 获取url本地地址
01

OpenStack metadata简介

OpenStack虚拟机通过cloud-init完成初始化配置，比如网卡配置、hostname、初始化密码以及密钥注入等。cloud-init是运行在虚拟机内部的一个进程，它通过datasources获取虚拟机的配置信息，即metadata。cloud-init支持从不同的数据源获取metadata，因而实现了不同的datasources驱动，不同的datasource实现原理不一样。比较常用的datasources主要有以下两种：

  • ConfigDriver: Nova把所有配置信息写入到本地的一个raw文件中，然后通过cdrom形式挂载到虚拟机中。此时在虚拟机内部可以看到类似/dev/sr0(注：sr代表 scsi + rom)的虚拟设备。cloud-init只需要读取/dev/sr0文件信息即可获取虚拟机配置信息。

  • Metadata: Nova在本地启动一个HTTP metadata服务，虚拟机通过HTTP访问该metadata服务获取相关的虚拟机配置信息。

ConfigDriver的实现原理比较简单，本文不再介绍。这里重点介绍Metadata，主要解决以下两个问题：

  1. Nova Metadata服务启动在nova-api控制节点上，虚拟机内部租户网络和宿主机的物理网络是不通的，虚拟机如何访问Nova的Metadata服务。

  2. 假设问题1已经解决，那么Nova Metadata服务如何知道是哪个虚拟机发起的请求。

02

Metadata服务配置

2.1 Nova配置

Nova的metadata服务名称为nova-api-metadata，不过通常会把服务与nova-api服务合在一起启动:

c290a624e9347c53e992225445c02c5a.png

另外虚拟机访问Nova的Metadata服务需要Neutron转发，原因后面讲，这里只需要注意在nova.conf配置:

3f7d9f6310bde3c8d1cdf640822874a9.png

2.2 Neutron配置

前面提到虚拟机访问Nova的Metadata服务需要Neutron转发，可以通过l3-agent转发，也可以通过dhcp-agent转发，如何选择需要根据实际情况：

  • 通过l3-agent转发，则虚拟机所在的网络必须关联了router。

  • 通过dhcp-agent转发，则虚拟机所在的网络必须开启dhcp功能。

Metadata默认是通过l3-agent转发的，不过由于在实际情况下，虚拟机的网络通常都会开启dhcp功能，但不一定需要router，因此我更倾向于选择通过dhcp-agent转发，配置如下:

257a2297037a2902f74d73a7d4d9b2f4.png

本文接下来的所有内容均基于以上配置环境。

03

虚拟机如何访问Metadata服务

3.1 从虚拟机访问Metadata服务说起

cloud-init访问metadata服务的URL地址是http://169.254.169.254，这个IP很特别，主要是效仿了AWS的Metadata服务地址，它的网段是169.254.0.0/16，这个IP段其实是保留的，即IPv4 Link Local Address，它和私有IP(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)类似，不能用于互联网路由，通常只用于直连网络。如Windows操作系统DHCP获取IP失败，就会自动配置为169.254.0.0/16网段的一个IP。

那AWS为什么选择169.254.169.254这个IP呢，这是因为选择Link Local IP可以避免与用户的IP冲突，至于为什么选择169.254.169.254这个IP而不是169.254.0.0/24的其它IP，大概是为了好记吧。

另外AWS还有几个很有趣的地址：

  • 169.254.169.253: DNS服务。

  • 169.254.169.123: NTP服务。

更多关于169.254.169.254信息，可以参考whats-special-about-169-254-169-254-ip-address-for-aws。

OpenStack虚拟机也是通过http://169.254.169.254获取虚拟机的初始化配置信息：

2b91a06e48e2f9edcccf7fca180914bd.png

从以上输出可见从metadata服务中我们获取了虚拟机的uuid、name、project id、availability_zone、hostname等。

虚拟机怎么通过访问169.254.169.254这个地址就可以获取Metadata信息呢，我们首先查看下虚拟机的路由表:

dffb019b9d2f0cc4cc1b9dbe1b813d61.png

我们可以看到169.254.169.254的下一跳为10.0.0.66。10.0.0.66这个IP是什么呢？我们通过Neutron的port信息查看下:

d3fee384b7d5a9e3345eb4e9d4934b26.png

可看到10.0.0.66正好是网络2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a的dhcp地址，可以进一步验证:

0e0d9e563d854d980d55e8c699294fd5.png

由此，我们可以得出结论，OpenStack虚拟机访问169.254.169.254会路由到虚拟机所在网络的DHCP地址，DHCP地址与虚拟机IP肯定是可以互通的，从而解决了虚拟机内部到宿主机外部的通信问题。那DHCP又如何转发到Nova Metadata服务呢，下一节将介绍如何解决这个问题.

3.2 Metadata请求第一次转发

前面介绍了虚拟机访问Metadata服务地址169.254.169.254，然后转发到DHCP地址。我们知道Neutron的DHCP port被放到了namespace中，我们不妨进入到虚拟机所在网络的namespace:

16366196e0d2c5e727dac18ba010fb2e.png

首先查看该namespace的路由:

eb7ed65999eafac9deae2d64409fd678.png

从路由表中看出169.254.0.0/16是从网卡tap1332271e-0d发出去的，我们查看网卡地址信息:

ece193c294926dfdecf0080c44a6e480.png

我们发现，169.254.169.254其实是配在网卡tap1332271e-0d的一个虚拟IP。虚拟机能够访问169.254.169.254这个地址也就不足为奇了。需要注意的是，本文的metadata转发配置是通过dhcp-agent实现的，如果是l3-agent，则169.254.169.254是通过iptables转发。

我们能够访问curl http://169.254.169.254，说明这个地址肯定开放了80端口:

21f83a1e61f82bf2f8b48b8809cc38a9.png

从输出中看，所在的环境除了开启了DHCP服务(53端口)，确实监听了80端口，进程pid为11334/haproxy。

我们看到haproxy这个进程就可以猜测是负责请求的代理与转发，即OpenStack虚拟机首先会把请求转发到DHCP所在namespace haproxy监听的端口80。

问题又来了，DHCP所在的namespace网络仍然和Nova Metadata是不通的，那haproxy如何转发请求到Nova Metadata服务呢，我们下一节介绍。

3.3 Metadata请求第二次转发

前面我们介绍了OpenStack虚拟机访问http://169.254.169.254会被转发到DHCP所在namespace的haproxy监听的80端口中。但是，namespace中仍然无法访问Nova Metadata服务。

为了研究解决办法，我们首先看下这个haproxy进程信息:

b602d89258305161921814c4ed1fedb8.png

其中2c4b658c-f2a0-4a17-9ad2-c07e45e13a8a.conf配置文件部分内容如下:

2f46d9a5619e683fd5718428c492a8c9.png

我们发现haproxy绑定的端口为80，后端地址为一个文件/opt/stack/data/neutron/metadata_proxy。后端不是一个IP/TCP地址，那必然是一个UNIX Socket文件:

c32b063632b7a1443f0e8f0cafa2bcc9.png

因此我们得出结论，haproxy进程会把OpenStack虚拟机Metadata请求转发到本地的一个socket文件中。

NIX Domain Socket是在socket架构上发展起来的用于同一台主机的进程间通讯(IPC)，它不需要经过网络协议栈实现将应用层数据从一个进程拷贝到另一个进程，有点类似于Unix管道(pipeline)。

问题又来了:

  • 我们从haproxy配置看，监听的地址是0.0.0.0:80，那如果有多个网络同时都监听80端口岂不是会出现端口冲突吗？

  • socket只能用于同一主机的进程间通信，如果Nova Metadata服务与Neutron dhcp-agent不在同一个主机，则显然还是无法通信。

第一个问题其实前面已经解决了，haproxy是在虚拟机所在网络的DHCP namespace中启动的，不同的namespace网络栈相互隔离，因此不会存在端口冲突。我们可以验证:

0a8785ac72ad2dcd488708cd34cd4131.png

关于第二个问题，显然还需要一层转发，具体内容请看下一小节内容。

另外需要注意的是，新版本的OpenStack是直接使用haproxy代理转发的，在一些老版本中则使用neutron-ns-metadata-proxy进程负责转发，实现的代码位于neutron/agent/metadata/namespace_proxy.py：

d5238734e59d6106e87485bf2e8121d6.png

大家可能对请求URL为169.254.169.254有疑问，怎么转发给自己呢? 这是因为这是一个UNIX Domain Socket请求，其实这个URL只是个参数占位，填什么都无所谓，这个请求相当于:

ea1287a7464f5295ce103bb7bb072434.png

3.4 Metadata请求第三次转发

前面说到，haproxy会把Metadata请求转发到本地的一个socket文件中，那么，到底是哪个进程在监听/opt/stack/data/neutron/metadata_proxysocket文件呢？我们通过lsof查看下:

5212f36310c079cad030dab4e0b43056.png

可见neutron-metadata-agent监听了这个socket文件，相当于haproxy把Metadata服务通过socket文件转发给了neutron-metadata-agent服务。

neutron-metadata-agent初始化代码如下:

8f6d9ac646a1de0bc2e2c891f780942f.png

进一步验证了neutron-metadata-agent监听了/opt/stack/data/neutron/metadata_proxysocket文件。

由于neutron-metadata-agent是控制节点上的进程，因此和Nova Metadata服务肯定是通的, OpenStack虚拟机如何访问Nova Metadata服务问题基本就解决了。

66287e27d8f4df0ed3567b0a20d59573.png

即一共需要三次转发。

但是Nova Metadata服务如何知道是哪个虚拟机发送过来的请求呢？换句话说，如何获取该虚拟机的uuid，我们将在下一章介绍。

04

Metadata服务如何获取虚拟机信息

前一章介绍了OpenStack虚拟机如何通过169.254.169.254到达Nova Metadata服务，那到达之后如何判断是哪个虚拟机发送过来的呢？

其实OpenStack是通过neutron-metadata-agent获取虚拟机的uuid的。我们知道，在同一个Neutron network中，即使有多个subnet，也不允许IP重复，即通过IP地址能够唯一确定Neutron的port信息。而neutron port会设置device_id标识消费者信息，对于虚拟机来说，即虚拟机的uuid。

因此neutron-metadata-agent通过network uuid以及虚拟机ip即可获取虚拟机的uuid。

不知道大家是否还记得在haproxy配置文件中存在一条配置项:

0dad4d5af0f3ad9a481e9426be4a462e.png

即haproxy转发之前会把network id添加到请求头部中，而IP可以通过HTTP的头部X-Forwarded-For中获取。因此neutron-metadata-agent具备获取虚拟机的uuid以及project id(租户id)条件，我们可以查看neutron-metadata-agent获取虚拟机uuid以及project id实现，代码位于neutron/agent/metadata/agent.py:

262b976581b3b3ac50920b288896a33d.png

如果谁都可以伪造Metadata请求获取任何虚拟机的metadata信息，显然是不安全的，因此在转发给Nova Metadata服务之前，还需要发一个secret:

e6b2dd50427646f3149e384de625590a.png

metadata_proxy_shared_secret需要管理员配置，然后组合虚拟机的uuid生成一个随机的字符串作为key。

最终，neutron-metadata-agent会把虚拟机信息放到头部中，发送到Nova Metadata服务的头部信息如下：

e017f73d315399ee292bce72bf594949.png

此时Nova Metadata就可以通过虚拟机的uuid查询metadata信息了，代码位于nova/api/metadata/base.py:

d43451e951440230fd1b46d3f13db007.png

05

外部如何获取虚拟机metadata

前面已经介绍了OpenStack虚拟机从Nova Metadata服务获取metadata的过程。有时候我们可能需要调试虚拟机的metadata信息，验证传递的数据是否正确，而又嫌麻烦不希望进入虚拟机内部去调试。有什么方法能够直接调用nova-api-metadata服务获取虚拟机信息呢。

根据前面介绍的原理，我写了两个脚本实现:

第一个Python脚本sign_instance.py用于生成secret:

7cf87018072cb5f1b31e4a0a2665337a.png

第二个bash脚本get_metadata.py实现获取虚拟机metadata:

5a14aa8b635855c7ba036efb664cf63c.png

其中metadata_server为Nova Metadata服务地址。用法如下:

d0def13f7709965fc304222f19109af0.png

通过如上脚本就可以轻松在外部获取任一虚拟机的metadata，对于虚拟机cloud-init初始化失败时调试特别方便。

05

总结

最后通过一张工作流图总结整个过程如下：

8fc525038b26d90cdbbb62e4c6d81ca4.png
weixin_39955938
关注
dashboard疏散主机提示报错：无法疏散主机...处理方法、openstack虚拟机状态卡在重启处理方法、openstack在数据库修改虚拟机状态的方法
崔崇鑫的博客，你linux/云运维工作中的百科全书。
03-08 737
后面发现造成这个原因是因为该虚拟机所属的宿主机down机了。但是又因为上面虚拟机一直处于硬重启状态，所以这台虚拟机肯定是无法迁移或疏散出去的。所以疏散主机就会报下面错误咯。前提条件，有个虚拟机控制台刷不出来，以为虚拟机死机了，重启后发现一直卡在重启界面，并且host_status信息也获取不到了。疏散主机就提示，错误，无法疏散主机。
OpenStack 虚拟机冷/热迁移功能实践与流程分析
烟云的计算
03-15 5630
目录 文章目录目录迁移的应用场景迁移的类型冷迁移热迁移迁移时需要处理的数据类型迁移的运行场景 迁移的应用场景 当物理服务器发生故障修复时，或当物理服务器升级维护时，需要将物理服务器之上的虚拟机热迁移出去。 当某个物理服务器上的负载超出安全阈值，需要将其中一些虚拟机迁移出去，以此释放资源。 对一个区域中的物理服务器进行虚拟机负载均衡。 迁移的类型 冷迁移 冷、即冷冻，数据的冷冻，不存在动态数据的...
VMware Linux虚拟机无法获取uuid解决方式.docx
08-16
VMware Linux虚拟机无法获取uuid解决方式 VMware Linux虚拟机无法获取uuid解决方式
【VMware】VMware linux虚拟机无法获取uuid
热门推荐
badly9的专栏
08-26 1万+
解决方法挺简单，记录一下，如下： 1.在虚拟机关闭以后，进入虚拟机的目录 2、用文本编辑器修改vmx文件,在vmx文件中任意位置（通常在最后）添加如下行： disk.EnableUUID = "TRUE" 3、重新启动虚拟机，之后就可以正确获取SCSI ID # /sbin/scsi_id -g -u -s /block/sdb 36000c2987883511c7f440187ec8
openstack底层提取所有虚拟机IP和其uuid、openstack底层提取所有虚拟机的所在宿主机
崔崇鑫的博客，你linux/云运维工作中的百科全书。
05-13 2561
说明 需求 1、获取所有表的ip和期uuid【以底层为准】 2、获取所有IP的所在宿主机【以底层为准】 实现方式有2种 1、dashboard里面可以查看，然后一台一台的复制【使用少量虚拟机】 2、底层跑脚本获取【适合多虚拟机】 dashboard ip名称对应宿主机 登录dashboard进入到admin域，里面就可以看到虚拟机的宿主机。 虚拟机uuid 点击名称，进入到详细，里面的id就是虚拟机的uuid 底层命令获取 之前的脚本 我最开始获取这个的时候，用的是下面的脚本，获取这
Linux6虚拟机获取UUID
crcz16618的博客
02-15 2088
首先在虚拟机关机的状态下，在虚拟机系统目录里将.vmx的文件加入disk.EnableUUID="TRUE" 开机 运行下列命令获取uuid，如下所示： [root@node1 ~]# scsi_id --whiteli...
获取UUID方法
米枔的博客
06-25 865
安装完成后，点击桌面上图标，打开app即可获取手机uuid。打开 “手机设置”-》“VPN与设备管理”使用sari 打开网页。
openstack常用运维命令_openstack常用命令
weixin_30670745的博客
01-13 1042
本帖 * 后由 guofei 于 2018-3-28 22:26 编辑openstack常用命令一、nova1. 列出所有的虚拟机nova list2. 列出所有租户下的虚拟机nova list--all-tenant3. 查看虚拟机详细信息nova showuuid-or-server-name4. 查看所有的nova imagenova image-list5. 查看所有的...
OpenStack手动分布式部署Nova【Queens版】_openstack queen
2401_84182073的博客
04-28 898
nova组件是用来建虚拟机的（功能：负责响应虚拟机创建请求、调度、销毁云主机）(1).nova api service------安装在controller节点：接受和相应客户端发送的请求，nova-api负责接收和响应终端用户由管虚拟机和云硬盘的请求。就是说我想在openstack中创建个虚拟机(创建虚拟机最终在nova中完成)，我发出的请求就被nova-api接收并发送到nova中去，然后在进行下一步具体操作，nova-api是整个nova的入口。
UUID 生成（源代码编译）
weixin_34306676的博客
11-05 787
根据定义，UUID（Universally Unique IDentifier，也称GUID）在时间和空间都是唯一的。为保证空间的唯一性，每个UUID使用了一个48位的值来记录，一般是计算机的网卡地址。为保证时间上的唯一性，每个UUID具有一个60位的时间戳（timestamp）。这个时间戳表示自公元1582年（绝对不是1852，这是《COM技术内幕》，1999年3月第1版第89页中的一个错误）1...
UUID与secrets模块
weixin_54279427的博客
07-14 265
UUID是Universally Unique IDentifier(普遍唯一的标识)UUID代表通用唯一标识符，是一个128位的值，用于软件开发的唯一标识UUID的生成基于当前时间戳和生成UUID的工作站的唯一属性 uuid1 uuid4 uuid3 uuid5...
openstack如何通过ip查uuid和如何查看宿主机上的所有虚机、容器搭建的openstack中查看宿主机上运行的所有虚拟机
崔崇鑫的博客，你linux/云运维工作中的百科全书。
03-12 1万+
文章目录查看物理机状态说明通过ip 查uuid云平台查看命令行查看查询宿主机上所有虚机云平台查看命令查看 查看物理机状态 为扩展知识哈！！！！ nova computer servier list/openstack compute service list : 查看物理机是否宕机（控制节点source执行环境变量后执行该命令）不知道环境变量为啥样？ 就是一堆参数的脚本文件，然后source 文...
访问openstack 的169.254.169.254 得到什么
aalup的博客
08-15 2406
curl http://169.254.169.254 curl http://169.254.169.254 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 latest[root@block1 ~]# curl http://169.254.169.254/1.0 meta-data/ user-data[root@block1 ~]# cu.
深度解析 OpenStack metadata 服务架构
cpongo011702
01-17 431
启迪云-高级开发工程师 郭全前言下图是OpenStack虚拟机在启动过程中发出的一个请求，我们在里面可以看到cloud-init和169.254.169.254。那么它们分别是做什么用的呢，接下来我们将会做一个详细的介绍。众所周知，在创建虚拟机的时候，用户往往需要对虚拟机进行一些配置，比如：开启一些服务、安装某些包、添加SSH 秘钥、配置 hostname，修改密码等等。这里有两个问题，一个是谁负...
EC2的meta-data
aws0to1的博客
08-31 1895
在EC2实例中有一个魔法IP 169.254.169.254。 通过访问这个ip，能获得许多与这个实例相关的信息，这些信息被称为meta-data。 meta-data版本历史（最后一行的latest是最常用的） wget -q -O - http://169.254.169.254/ 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-
【Linux】Linux中获取UUID的方法
郭老二
08-14 2075
在Linux中获取UUID
openstack详解（二十三）——Neutron其他配置、数据库初始化与服务启动
永远是少年
06-09 1784
今天继续给大家介绍Linux运维相关知识，本文主要内容是Neutron其他配置、数据库初始化与服务启动。 一、Neutron元数据代理配置 二、Neutron网络服务配置 三、Neutron数据库初始化 四、Neutron服务启动.........
openstack-M版，学习笔记六
nova12315的博客
12-01 617
笔记为根据老男孩视频+官方文档学习，并记录，如有错漏，心情好的可以指出一下。 视频地址：https://www.bilibili.com/video/BV1LJ411Y7og?p=12 控制节点 各个组件： 1. neutron-server 端口（9696）api：接收和响应外部的网络管理请求 2. neutron-linuxbridge-agent： 负责创建桥接网卡 3. neutron-dhcp-agent： 负责分配IP 4. neutron-metadat...
Openstack Metadata 访问问题
独旅天涯
09-23 1984
使用cloudinit工具来完成虚拟机配置适应问题的时候，遇到了169.254.169.254无法访问的忧伤。 问题描述 安装的是OpenStack Havana版本，使用neutron提供网络功能，采用linuxbridge下的vlan网络模型，因为使用的是centos6.2，所以没使用ip namespace功能。 在主控节点上对metadata相关的关键配置如下： /etc/no...
uuid_to_bin
最新发布
10-08
UUID（Universally Unique Identifier，通用唯一识别符）是一个128位的数字，通常表示为36字符的字符串形式，包括字母和数字，用于唯一标识某个实体。而`uuid_to_bin`函数或方法的作用是从UUID字符串转换为二进制表示。这是因为计算机内部处理数据通常是以二进制形式存储和操作的，所以将UUID转换成二进制可以方便在网络传输、数据库存储等场景中直接操作。 例如，在Python中，你可以使用内置的`uuid`模块提供的`int`方法来完成这个转换，然后再转为字节串： ```python import uuid def uuid_to_bin(uuid_str): uuid_int = int(uuid.UUID(uuid_str), 16) # 将UUID字符串转换为整数，基数为16（十六进制） return uuid_int.to_bytes(16, byteorder='big') # 转换为16字节的大端字节序 # 使用示例 binary_uuid = uuid_to_bin('123e4567-e89b-12d3-a456-426655440000') ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值