1．消息队列 AMQP 是一种标准化的消息中间件协议，全称为高级消息队列协议（advanced message queuing protocol）。可以让不同语言、不同系统的应用互相通信，并提供一个简单统一的 模型和编程接口。这样，就可以采用各种语言和平台来实现自身的应用，当需要和其他系 统通信时，只要承认 AMQP 协议即可。 2．Rabbitmq 消息服务 RabbitMQ 是一个基于 AMQP 协议的高级消息中间件，它主要的技术特点是可用性，安全性，集群，多协议支持，可视化的客户端，活跃的社区。 1．了解消息队列 AMQP 消息队列 AMQP 服务架构，如图 4-1 所示。 AMQP 中有 3 个重要的角色，如图 4-2 所 示。 Publisher：消息的发出者。  Exchange：消息的传递者。  Consumer：消息的接收者。 用户可以模拟写信作为其工作的方式来说 明。为了传递给收件人，首先需要用信封把信 的内容装起来，然后在信封上写好收件人的信 息，再把信放到邮筒里；后面邮局会拿到信然 后根据信封上的收件人信息来看最终把信给谁。写信的人就是那个 Publisher，邮局就是 Exchange，收件人就是 Consumer。 不同的 Consumer 会创建不同的 Queue（消息队列），然后将对应的 Exchange 绑定到 Queue 上。在消息的传递过程中，Publisher 不会直接的把 Message 放到 Queue 中，也不管 Message 如何分发。Publisher 只管准备好消息，然后交给 Exchange，而 Exchange 做的事情 也很简单，一手从 Publisher 拿到消息，然后就把消息放入 Queue 中。 对于 Exchange，是放到某一个 Queue 中，还是放到多个 Queue？实际上，在 Publisher 发出消息的时候会附加一个条件，Exchange 会根据这个条件来决定发送的方法，这个条件 就是 routingkey。 2．了解 Rabbitmq 消息服务 通过上面这张应用相结合的结构图既能够清晰的看清楚整体的 send Message 到Receive Message 的一个大致的流程。 首先 Rabbitmq 有如下几种命令行工具。 ① rabbitmqctl：用来管理 RabbitMQ 中间件的命令行工具.它通过连接中间件节点来执 行所有操作。 ② rabbitmq-plugins：rabbitmq-plugins 是管理 RabbitMQ broker 插件的命令行。 3．OpenStack 的消息服务 OpenStack 采用 AMQP 作为它的消息传递技术。AMQP 的控制端（Broker），不管是 RabbitMQ 或者 Qpid，它的作用是允许任何两个相同组件以松散耦合的方式进行交流。更 准确地说，OpenStack 的组件均可以使用远程呼叫机制（RPC）进行彼此沟通。然而，这种 范式是建立在“publish/subscribe 模式”（订阅/发布模式，订阅发布模式定义了一种一对多 的依赖关系，让多个订阅者对象同时监听某一个主题对象。这个主题对象在自身状态变化 时，会通知所有订阅者对象，使它们能够自动更新自己的状态这样做 的好处如下。 （1）客户端和服务端之间的解耦（如客户端不需要知道服务引用）。 （2）客户机和服务之间不需要同时使用消息调用，只需要其中一端发送消息调用指令。 （3）随机平衡的远程调用会随机将运行的指令发送到一个节点。 下面以计算服务 Nova 为例，讲解 OpenStack 组件使用消息服务的原理和机制。Nova 中的每个组件都会连接消息服务器，一个组件可能是一个消息发送者（如 API、Scheduler）， 也可能是一个消息接收者（如 compute、volume、network）。   发送消息有 2 种方式：同步调用 rpc.call 和异步调用 rpc.cast。Nova 实现了 RPC（包括 请求+响应的 rpc.call 和只有请求的 rpc.cast），Nova 通过 AMQP 提供一个代理类，这个类 提供了函数调用的消息数据编码和数据解码，每个 Nova 服务（如计算）在初始化时创建 两 个 队 列 ， 一 个 接 受 消 息 路 由 的 关 键 节 点 类 型 产 生 对 应 的 节 点 编 号 ” （ 例 如 compute.hostname），另一个接受消息路由键返回的节点类型编号生成通用的“节点类型” （例如计算）。前者是专门用来当 Nova-API 需要重定向命令像 terminate（终止）一个实例 的在特定的节点，在这种情况下，只有主机的计算节点的虚拟机监控程才能杀死序正在运 行的虚拟机实例。API 作为消费者当 RPC 调用请求/响应，否则只是充当发布 4．Nova RPC 映射   当一个实例在 OpenStack 云部署和共享，每个组件在 Nova 连接到 messagebroker，根 据其个性，如计算节点或网络节点，可以使用队列作为调用者（如 API 或调度器）或一个 运行组件（如计算或网络）。调用器和组件不实际存在于 Nova 对象模型，但是在这个例子中使用它们作为一个抽象对象。一个调用程序是一个组件，使用 rpc 发送消息队列系统， 接收消息的队列系统，并相应地回复 rpc 调用操作 （1）Topic Publisher：该对象在进行 rpc.call 或 rpc.cast 调用时创建，每个对象都会连接 同一个 topic 类型的交换器，消息发送完毕后对象被回收。 （2）Direct Publisher：该对象在进行 rpc.call 调用时创建，用于向消息发送者返回响应。 该对象会根据接收到的消息属性连接一个 direct 类型的交换器。 （3）Direct Consumer：该对象在进行 rpc.call 调用时创建，用于接收响应消息。每一个 对象都会通过一个队列连接一个 direct 类型的交换器（队列和交换器以 UUID 命名）。 （4）Topic Consumer：该对象在内部服务初始化时创建，在服务过程中一直存在。用于 从队列中接收消息，调用消息属性中指定的函数。该对象通过一个共享队列或一个私有队 列连接一个 topic 类型的交换器。每一个内部服务都有两个 topic consumer，一个用于 rpc.cast 调用（此时连接的是 binding-key 为“topic”的共享队列）。另一个用于 rpc.call 调用（此 时连接的是 binding-key 为“topic.host”的私有队列） （5）Topic Exchange：topic 类型交换器，每一个消息代理节点只有一个 topic 类型的交 换器。 （6）Direct Exchange：direct 类型的交换器，存在于 rpc.call 调用过程中，对于每一个 rpc.call 的调用，都会产生该对象的一个实例。 （7）Queue Element：消息队列。可以共享也可以私有。routing-key 为“topic”的队列 会在相同类型的服务中共享（如多个 compute 节点共享一个 routing-key 为“topic”的队列）。 ** 学习镜像服务** 1．概述   Glance 镜像服务实现发现、注册、获取虚拟机镜像和镜像元数据，镜像数据支持存储 多种的存储系统，可以是简单文件系统、对象存储系统等。 2．Glance 服务架构   Glance 镜像服务是典型的 C/S 架构，Glance 架构包括 glance-CLIent、Glance 和 Glance Store。Glance 主要包括 REST API、数据库抽象层（DAL）、域控制器（glance domain controller）和注册层（registry layer），Glance 使用集中数据库（Glance DB）在 Glance 各 组件间直接共享数据。   所有的镜像文件操作都通过 glance_store 库完成，glance_store 库提供了通用接口，对 接后端外部不同存储 （1）客户端（CLient）：外部用于同 Glance 服务的交互和操作。 （2）glance-api：Glance 对外的 REST 接口。 （3）数据库抽闲层（DAL）：Glance 和数据库直接交互的编程接口。 （4）Glance 域控制器：中间件实现 Glance 的认证、通知、策略和数据链接等主要功能。 （5）注册层：可选层，用于管理域控制和数据库 DAL 层之间的安全通信。 （6）Glance DB：存储镜像的元数据，根据需要可以选择不同类型的数据库，目前采用 Mysql。 （7）Glance Store：Glance 对接不同数据存储的抽象层。 （8）后端存储：实际接入的存储系统。可以接入简单文件系统、Swift、Ceph 和 S3 云 存储等。当前框架选择存储在本地，目录在控制节点：/var/lib/glance/images/。   Glance 服务自带两个配置文件，在使用 Glance 镜像服务时需要配置 glance-api.conf 和 glance-registry.conf 两个服务模块。在添加镜像到 Glance 时，需要指定虚拟镜像的磁盘格式 （disk format）和容器格式（container format）。 镜像服务运行两个后台服务进程 Demon，如下。 （1）glance-api：对外接受并发布镜像、获取和存储的请求调用。 （2）glance-registry：存储、处理和获取镜像元数据，内部服务只有 Glance 内部使用， 不暴露给用户。 （3）glance-all：是对前两个进程的通用封装，操作方式和结果一直。 3．镜像文件格式   虚拟机镜像需要指定磁盘格式和容器格式。虚拟设备供应商将不同的格式布局的信息 存在一个虚拟机磁盘映像，虚拟机的磁盘镜像的格式基本有如下几种。 （1）raw：非结构化磁盘镜像格式。 （2）qcow2：QEMU 模拟器支持的可动态扩展、写时复制的磁盘格式，是 kvm 虚拟机 默认使用的磁盘文件格式。 （3）AMI/AKI/ARI：Amazon EC2 最初支持的镜像格式。 （4）UEC tarball：ubuntu enterprise cloud tarball 是一个 gzip 压缩后的 tar 文件，包含有 AMI、AKI 和 ARI 三种类型的文件。 （5）VHD ：microsoft virtual hard disk format（微软虚拟磁盘文件）的简称。 （6）VDI：VirtualBox 使用 VDI（virtual disk image）的镜像格式，OpenStack 没有提供 直接的支持，需要进行格式转换。 （7）VMDK：VMWare virtual machine disk format 是虚拟机 VMware 创建的虚拟机格式。 （8）OVF：open virtualization format，开放虚拟化格式，OVF 文件是一种开源的文件 规范，可用于虚拟机文件的打包。   容器格式是可以理解成虚拟机镜像添加元数据后重新打包的格式，目前有以下几种容器格式 （1）Bare：指定没有容器和元数据封装在镜像中，如果 Glance 和 OpenStack 的其他服 务没有使用容器格式的字符串，为了安全，建议设置 bare。 （2）ovf: ovf 的容器模式 This is the OVF container format。 （3）aki：存储在 Glance 中的是 Amazon 的内核镜像。 （4）ari：存储在 Glance 中的是 Amazon 的 ramdisk 镜像。 （5）ami：存储在 Glance 中的是 Amazon 的 machine 镜像。 （6）ova：存储在 Glance 中的是 OVA 的 tar 归档文件。 ** 4．镜像状态**   由于镜像文件都比较大，镜像从创建到成功上传到 Glance 文件系统中，是通过异步任 务的方式一步步完成的，状态包括 Queued（排队）、Saving（保存中）、Acive（有效）、 deactivated（无效）、Killed（错误）、Deleted（被删除）和 Pending_delete（等待删除） （1）Queued 排队：镜像 ID 已经创建 和注册，但是镜像数据还没有上传。 （2）Saving 保存中：镜像数据在上传中 （3）Active 有效：镜像成功创建，状 态有效可用。 （4）Deactivated 不活的：镜像成功创 建，镜像对非管理员用户不可用。 （5）Killed 错误：上传镜像数据出错 目前不可读取。 （6）Deleted 被删除：镜像不可用， 将被自动删除。 （7）Pending_delete 等待删除：镜像 不可用，等待将被自动删除。 1．镜像服务基本操作 查询 Glance 服务状态命令如下

glance-control all status

查询 glance-control 版本命令如下。

glance-control --version

下面的命令作用是启动相关服务，并设置为开机启动。

# systemctl start openstack-glance-api
# systemctl start openstack-glance-registry
# systemctl enable openstack-glance-api
# systemctl enable openstack-glance-registry

在 Dashboard 中以 admin 账户登录，查看镜像。下面，通过上传本地镜像文件和从网 站下载镜像文件的方式进行创建、查询、删除和修改镜像 （1）下载 CirrOS 镜像文件

# mkdir /tmp/images # cd /tmp/images/ 
# wget http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-disk.img

下载完成后，查看文件信息，命令如下。

file cirros-0.3.2-x86_64-disk.img

该命令执行结果如下所示。

cirros-0.3.2-x86_64-disk.img: QEMU QCOW Image (v2), 41126400 bytes

（2）使用命令行创建镜像

#openstack image create "cirros-0.3.2-x86_64" --file /tmp/images/cirros-0.3.2-x86_64-disk.img --disk-format qcow2 --container-format bare --public

创建成功后，可以登录界面，查看镜像信息 （3）查看镜像信息

openstack image list

然后通过 glance image-show 命令查看镜像的详细信息，其中参数可以是镜像 id 或者镜 像名称

openstack image show e14b5e35-5e04-4da2-823d-b5f6e3283ebd

（4）通过命令删除镜像 cirros-0.3.2-x86_64 操作如下

openstack image delete 6aec74a2-eb83-45b6-99df-5f4ce025640c
openstack image list

学习计算服务 1．概述   计算服务（Nova）表示云平台的工作负载的核心。如果有些云服务的工作中不包括计 算，那么 它们充其量只 代表静态存储 ，所有动态活 动都会涉及一 些计算元素。 OpenStackCompute 这个名称指的是一个特定的项目，该项目也被称为 Nova，OpenStack 的 其他组件依托 Nova，与 Nova 协同工作，组成了整个 OpenStack 云平台。   Nova，是 OpenStack 计算的弹性控制器。Nova 可以说是整个云平台最重要的组件，其 功能包括运行虚拟机实例，管理网络以及通过用户和项目来控制对云的访问。OpenStack 最基础的开源项目名字称为 Nova，它提供的软件可以控制基础设施即服务（IaaS）云计算 平台，与 AmazonEC2 和 Rackspace 云服务器有一定程度的相似。OpenStackCompute 没有 包含任何的虚拟化软件，相反，它定义和运行在主机操作系统上的虚拟化机制交互的驱动 程序，并通过基于 Web 的程序应用接口（API）来提供功能的使用。 2．架构介绍    Nova 服务包 含了 7 个子组 件，分别为 ：NovaAPI、 NovaCert、 NovaCompute、 NovaConductor 和 NovaScheduler、NovaConsoleauth 以及 NovaVncproxy （1）NovaAPI NovaAPI 这是一个 HTTP 服务，用于接收和处理客户端发送的 HTTP 请求；API 是整 个 Nova 组件的入口。它接受用户请求，将指令发送至消息队列（Queue），并由 Nova 服 务的子服务执行相应的操作。 （2）NovaCert 用于管理证书认证，提供兼容性保障，保证所有的应用程序都能在云上运行。 （3）NovaCompute NovaCompute 是 Nova 核心子组件，通过与 NovaClient 进行交互，实现了虚拟机管理 的功能。负责在计算节点上对虚拟机实例进行一系列操作，包括迁移、安全组策略和快照 管理等功能。 （4）NovaConductor NovaConductor 是 OpenStack 中的一个 RPC 服务，主要提供对数据库的查询和权限分 配操作。

（5）NovaScheduler 完成 Nova 的核心调度，包括虚拟机硬件资源调度、节点调度等。同时，NovaScheduler 决定了虚拟机创建的具体位置。 （6）NovaConsoleauth 实现对 Nova 控制台（VNC）的认证操作。 3．调度机制（scheduler） Scheduler 模块在 OpenStack 中的作用就是决策虚拟机创建在哪个主机上，目前（截至 Essex 版本），调度仅支持计算节点。 （1）主机过滤 ① AllHostsFilter：不做任何过滤，直接返回所有可用的主机列表。 ② AvailabilityZoneFilter：返回创建虚拟机参数指定的集群内的主机。 ③ ComputeFilter：根据创建虚拟机规格属性选择主机。 ④ CoreFilter：根据 CPU 数过滤主机。 ⑤ IsolatedHostsFilter：根据“image_isolated”和“host_isolated”标志选择主机。 ⑥ JsonFilter：根据简单的 JSON 字符串指定的规则选择主机。 ⑦ RamFilter：根据指定的 RAM 值选择资源足够的主机。 ⑧ SimpleCIDRAffinityFilter：选择在同一 IP 段内的主机。 ⑨ DifferentHostFilter：选择与一组虚拟机不同位置的主机。 ⑩ SameHostFilter：选择与一组虚拟机相同位置的主机。 （2）权值计算 经过主机过滤后，需要对主机进行权值的计算。根据策略选择相应的某一台主机（对 于每一个要创建的虚拟机而言）。尝试在一台不适合的主机上创建虚拟机的代价比在一台 合适主机上创建的代价要高，例如，在一台高性能主机上创建一台功能简单的普通虚拟机 的代价是高的。OpenStack 对权值的计算需要一个或多个（Weight 值代价函数）的组合， 然后对每一个经过过滤的主机调用代价函数进行计算，将得到的值与 Weight 值相乘，得到 最终的权值。OpenStack 将在权值最小的主机上创建一台虚拟机 （3）配置文件讲解 Nova 的安装与 Glance 组件的部署流程类似，Nova 的子服务更多，把 nova-compute 单 独部署在计算节点，Nova 的其他服务部署在控制节点。 为了实现计算节点的 Nova-compute 服务与控制节点上 Nova 其他的子服务通信，需要 在配置文件中配置 Rabbit 消息队列服务。

[root@controller ~]# vi /etc/nova/nova.conf

配置如下所示内容。

[DEFAULT] 
rpc_backend = rabbit

Nova 服务的数据存储在 MySQL 数据库中，需要在数据库中创建 Nova 数据库并给予 一定的权限，在 Nova 的配置文件中配置数据库连接，指向 MySQL 中的 Nova 数据库。

[api_database]
connection = mysql+pymysql://nova:000000@controller/nova_api 

mysql -uroot -p

执行如下所示的命令，赋予数据库权限。

mysql> CREATE DATABASE nova; //已有数据库
mysql>GRANT REPLICATION SLAVE ON *.* to 'nova'@'%' identified by '000000';

跟 Glance 组件一样，需要在 Keystone 创建 nova 用户

openstack user create --domain demo --password=NOVA_PASS --email=NOVA_EMAIL nova //已有此用户

赋予 nova 用户 admin 权限，并把 nova 用户规划到 service 项目下，同时在 Keystone 中 注册 Nova 服务，服务类型为 compute。

openstack role add --user=nova --project=service admin
openstack service create --name=nova222 --description="OpenStack Compute" compute

在 Keystone 中创建 Nova 计算服务的端点。

openstack service create --name nova --description "OpenStack Compute" compute
openstack endpoint create --region RegionOne compute public http://controller:8774/v2.1/%\(tenant_id\)s
openstack endpoint create --region RegionOne compute internal http://controller:8774/v2.1/%\(tenant_id\)s
openstack endpoint create --region RegionOne compute admin http://controller:8774/v2.1/%\(tenant_id\)s

为了实现 Nova 服务调用其他服务，需要在 Nova 的配置文件中配置其通过 Keystone 的认证。 （4）Nova 的主要操作命令 Nova 作为 OpenStack 的核心组件，拥有强大的功能、权限，可以对整个平台的资源（镜 像、网络和存储等）进行管理，下面来看一下 Nova 的主要操作命令。 ① Nova 对镜像进行管理。 功能：获取镜像的详细信息。  nova image-create

nova image-create [--show] [--poll] <server><name>

 nova image-show

nova image-list

nova image-show f7cac855-e4a1-4690-bd1b-f8d79f90286f

② Nova 管理安全组规则。 安全组，翻译成英文是 security group。安全组是一些规则的集合，用来对虚拟机的访 问流量加以限制，这反映到底层，就是使用 iptables，给虚拟机所在的宿主机添加 iptables 规则。可以定义 n 个安全组，每个安全组可以有 n 个规则，可以给每个实例绑定 n 个安全 组，Nova 中总是有一个 default 安全组，这个是不能被删除的。创建实例的时候，如果不 指定安全组，会默认使用这个 default 安全组。现在 Nova 中安全组应该会移到 Neutron 中， 并且会增加对虚拟机外出流量的控制。现在 Nova 中的安全组只是对进入虚拟机的流量加 以控制，对虚拟机外出流量没有加以限制。 常用的安全组命令如下。

nova secgroup-create

功能：创建安全组。

usage: nova secgroup-create <name><description>

nova secgroup-add-rule

功能：给安全组添加规则。

usage: nova secgroup-add-rule <secgroup><ip-proto><from-port><to-port> <cidr>

（5）Nova 管理虚拟机类型 虚拟机类型是在创建实例的时候分配给实例的资源情况，下面来看一下 Nova 对虚拟 机类型的管理。

nova flavor-create

功能：创建一个虚拟机类型。

nova flavor-create [--ephemeral <ephemeral>] [--swap <swap>]

（6）Nova 实例管理 Nova 可对云平台中的实例进行管理，包括创建实例、启动实例、删除实例和实例迁移等操作。

nova boot

功能：启动实例。

（7）Nova 对逻辑卷的管理 Nova 对逻辑卷的管理也是 Nova 的一个比较重要的功能，下面来看一下 Nova 对逻辑 卷管理的常用命令。

nova volume-create

功能：通过 Nova 创建逻辑卷。 创建一个名字为 test、大小为 2G 的云硬盘，

nova volume-create --display-name test 2

（8）Nova 的其他命令

nova bash-completion

（9）拓展延伸 ① Nova 组件的调用实现。 OpenStack 的各个服务之间通过统一的 REST 风格的 API 调用，实现系统的松耦合。 松耦合架构的好处是，各个组件的开发人员可以只关注各自的领域，对各自领域的修改不 会影响到其他开发人员。不过，从另一方面来讲，这种松耦合的架构也给整个系统的维护 带来了一定的困难，运维人员要掌握更多的系统相关的知识去调试出了问题的组件。所以， 无论对于开发还是维护人员，搞清楚各个组件之间的相互调用关系都是非常必要的，用户 可以从 nova-client 入手来了解其中的过程。 nova-client 是一个命令行的客户端应用，终端用户可以从 nova-client 发起一个 api 请求 到 nova-api，nova-api 服务会转发该请求到相应的组件上。同时，nova-api 支持对 cinder 和 neutron 的请求转发，也就是可以在 nova-Client 直接向 cinder 和 neutron 发送请求。用户可 以在调用 nova-Client 增加--debug 选项打印更多的 debug 消息，通过这些 debug 信息可以了 解到，如果用户需要发起一个完整的业务层面上请求，都需要与哪些服务打交道。以启动 一个实例的过程举例

nova --debug boot --flavor 3 \

以上 debug 输出用户可以清楚看到，执行一个 boot 新实例的操作需要发送如下几个 api 请求。  向 Keystone 发送请求，获取租户（d7beb7f28e0b4f41901215000339361d）的认证 token。  通过拿到的 token，向 nova-api 服务发送请求，验证 image 是否存在。  通过拿到的 token，向 nova-api 服务发送请求，验证创建的 favor 是否存在。  请求创建一个新的 instance，需要的元数据信息通过包含在请求 body 中。 nova-client 帮助用户把需要的全部请求放到一起，而最重要的就是第 4 种。如果用户 想自己通过 rest api 直接发送 http 请求的话，可以直接使用第 4 种，当然，前提是先通过调 用 Keystone 服务得到认证 token。 下面结合代码重点叙述一下在第 4 种情况下的请求数据流动在整个 stack 中的过程 是一个全局的流程图，图中每个服务都是一个单独的进程实例，他们之间通过 rpc 调 用（广播或者调用）另一个服务。 以下是上面涉及的服务的主要功能。  nova-api：接受 http 请求，并响应请求，当然还包括请求信息的验证。  nova-conductor：与数据库交互，提高对数据库访问的安全性。  nova-scheduler：调度服务，决定最终实例要在哪个服务上创建。迁移、重建等都 需要通过这个服务。  nova-compute：调用虚拟机管理程序，完成虚拟机的创建、运行以及控制。 ② 数据库结构讲解。 跟其他组件相似，Nova 也把数据存储在 mySQL 中，Nova 的每一步操作都记录在数据 库中，实例、网络、用户和租户通过关系型数据库相互依赖。 ③ kvm、libvirt 与 OpenStack。 1959 年 6 月，Christopher Strachey 发表虚拟化论文，虚拟化是今天云计算基础架构的 基石。KVM 是最底层的 hypervisor，它是用来模拟 CPU 的运行的，它缺少了对 network 和 周边 I/O 的支持，所以用户是没法直接用它的。QEMU-KVM 就是一个完整的模拟器，它 是构建于 KVM 上面的，它提供了完整的网络和 I/O 支持。OpenStack 不会直接控制 qemu-kvm，它会用一个称为 libvit 的库去间接控制 qemu-lvm，libvirt 提供了跨 VM 平台的 功能，它可以控制除了 QEMU 的模拟器，包括 VMware、virtualbox xen 等。所以，为了 OpenStack 的跨 VM 性，OpenStack 只会用 libvirt 而不直接用 qemu-kvm。libvirt 还提供了一 些高级的功能，例如 pool/vol 管理  libvirt 是一套用 C 语言写的 API，旨在 为各种虚拟机提供一套通用的编程接 口，而且支持与 Java、python 等语言的 绑定。  libvirt 由几个不同的部分组成，其中包 括应用程序编程接口（API）库、一个 守护进程（libvirtd），以及一个默认命 令行实用工具（virsh），libvirtd 守护进程负责对虚拟机的管理工作。  kvm 负责 CPU 虚拟化和内存虚拟化，实现了 CPU 和内存的虚拟化，但 kvm 不能 模拟其他设备；libvirt 则是调用 kvm 虚拟化技术的接口用于管理的，用 libvirt 管 理方便。 ④ API 解析。 在前面用户已经接触到了 API，API 是外部程序入口，OpenStack 作为开源的平台，开 发人员正是通过 OpenStack 每个组件的 API 接口实现组件服务调用和二次开发。用户简单 的执行一条关于 nova 的命令 查看该实例在机器的具体位置的命令如下。

nova show Cloud_test