本节演示如何通过 Web GUI 和 CLI 两种方法创建 Image。

OpenStack 为终端用户提供了 Web UI（Horizon）和命令行 CLI 两种交换界面。

两种方式我们都要会用。 

可能有些同学觉得既然有更友好的 Web UI 了，干嘛还要用 CLI？ 这里 CloudMan 给出下面的理由： 

1. Web UI 的功能没有 CLI 全，有些操作只提供了 CLI。 即便是都有的功能，CLI 可以使用的参数更多

2.  一般来说，CLI 返回结果更快，操作起来更高效

3. CLI 可放在脚本中进行批处理

4. 有些耗时的操作 CLI 更合适，比如创建镜像（后面将涉及）

Web UI 创建 p_w_picpath

1. admin 登录后，Project -> Compute -> Images

2.点击右上角按钮，为新 p_w_picpath 命名。

这里我们上传一个 p_w_picpath。 点击，选择镜像文件 cirros-0.3.4-x86_64-disk.img。 cirros 是一个很小的 linux 镜像，非常适合测试用。 大家可以到  下载。

3.格式选择 QCOW2。

如果勾选，该 p_w_picpath 可以被其他 Project 使用 如果勾选，该 p_w_picpath 不允许被删除。 

4. 点击，文件上传到 OpenStack 并创建新的 p_w_picpath

5. 点击 p_w_picpath 链接，显示详细信息

10. 

CLI 创建 p_w_picpath

cirros 这个 linux 镜像很小，通过 Web UI 上传很快，操作会很顺畅。 但如果我们要上传的镜像比较大（比如好几个 G ），那么操作会长时间停留在上传的 Web 界面，我们也不知道目前到底处于什么状态。 对于这样的操作，CLI 是更好的选择。 

1. 将 p_w_picpath 上传到控制节点的文件系统中，例如 /tmp/cirros-0.3.4-x86_64-disk.img

2. 设置环境变量

Devstack 的安装目录下有个 openrc 文件。source 该文件就可以配置 CLI 的环境变量。这里我们传入了两个参数，第一个参数是 OpenStack 用户名 admin；第二个参数是 Project 名 admin

3. 执行 p_w_picpath 创建命令

glance p_w_picpath-create --name cirros --file /tmp/cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare --progress 

在创建 p_w_picpath 的 CLI 参数中我们用 --progress 让其显示文件上传的百分比 %，是不是比 Web UI更直观呢？ 

在 /opt/stack/data/glance/p_w_picpaths/ 下查看新的 Image

 

使用 OpenStack CLI 

 

本节首先讨论 p_w_picpath 删除操作，然后介绍 OpenStack CLI 的使用方法，最后讨如何 Troubleshoot。

Web UI 删除 p_w_picpath

1. admin 登录后，Project -> Compute -> Images

在列表中选择格式为 ARI 和 AKI 的 p_w_picpath，点击

2. 点击确认删除 

3. 操作成功

CLI 删除 p_w_picpath

1. 设置环境变量

2. 查询现有p_w_picpath

3. 删除p_w_picpath

如何使用 OpenStack CLI

OpenStack 服务都有自己的 CLI。 命令很好记，就是服务的名字，比如 Glance 就是 glance，Nova 就是 nova。 

但 Keystone 比较特殊，现在是用 openstack 来代替老版的 keystone 命令。 比如查询用户列表，如果用 keystone user-list 

会提示 keystone 已经 deprecated 了。 用 openstack 命令代替 

不同服务用的命令虽然不同，但这些命令使用方式却非常类似，可以举一反三。 

1. 执行命令之前，需要设置环境变量。 

这些变量包含用户名、Project、密码等； 如果不设置，每次执行命令都必须设置相关的命令行参数 

2. 各个服务的命令都有增、删、改、查的操作 

其格式是 

CMD <obj>-create [parm1] [parm2]… CMD <obj>-delete [parm] CMD <obj>-update [parm1] [parm2]… CMD <obj>-list CMD <obj>-show [parm]

例如 glance 管理的是 p_w_picpath，那么: CMD 就是 glance；obj 就是 p_w_picpath 对应的命令就有 

glance p_w_picpath-create glance p_w_picpath-delete glance p_w_picpath-update glance p_w_picpath-list glance p_w_picpath-show 

再比如 neutron 管理的是网络和子网等，那么： CMD 就是 neutron；obj 就是 net 和 subnet 对应的命令就有 

网络相关操作 

neutron net-create neutron net -delete neutron net -update neutron net -list neutron net –show 

子网相关操作 

neutron subnet-create neutron subnet -delete neutron subnet -update neutron subnet -list neutron subnet–show

有的命令 <obj> 可以省略，比如 nova 下面的操作都是针对 instance 

nova boot nova delete nova list nova show 

3. 每个对象都有 ID 

delete，show 等操作都以 ID 为参数，例如 

4. 可用 help 查看命令的用法 

除了 delete，show 等操作只需要 ID 一个参数，其他操作可能需要更多的参数，用 help 查看所需的参数，格式是 

CMD help [SUB-CMD] 

例如查看 glance 都有哪些 SUB-CMD 

查看 glance p_w_picpath-update 的用法 

如何 Troubleshooting

OpenStack 排查问题的方法主要是通过日志，Service 都有自己单独的日志。 Glance 主要有两个日志，glance_api.log 和 glance_registry.log，保存在 /var/log/apache2/ 目录里。 

devstack 的 screen 窗口已经帮我们打开了这两个日志，可以直接查看 

g-api 窗口显示 glance-api 日志，记录 REST API 调用情况 g-reg 窗口显示 glance-registry 日志，记录 Glance 服务处理请求的过程以及数据库操作 

如果需要得到最详细的日志信息，可以在 /etc/glance/*.conf 中打开 debug 选项。 devstack 默认已经打开了 debug。 

在非 devstack 安装中，日志在 /var/log/glance/ 目录里。

 理解 Nova 架构 

Compute Service Nova 是 OpenStack 最核心的服务，负责维护和管理云环境的计算资源。 

OpenStack 作为 IaaS 的云操作系统，虚拟机生命周期管理也就是通过 Nova 来实现的。

在上图中可以看到，Nova 处于 Openstak 架构的中心，其他组件都为 Nova 提供支持：

Glance 为 VM 提供 p_w_picpath 

Cinder 和 Swift 分别为 VM 提供块存储和对象存储 

Neutron 为 VM 提供网络连接

Nova 架构如下

Nova 的架构比较复杂，包含很多组件。 

这些组件以子服务（后台 deamon 进程）的形式运行，可以分为以下几类：

API

nova-api

接收和响应客户的 API 调用。 除了提供 OpenStack 自己的API，nova-api 还支持 Amazon EC2 API。 也就是说，如果客户以前使用 Amazon EC2，并且用 EC2 的 API 开发了些工具来管理虚机，那么如果现在要换成 OpenStack，这些工具可以无缝迁移到 OpenStack，因为 nova-api 兼容 EC2 API，无需做任何修改。 

Compute Core

nova-scheduler

虚机调度服务，负责决定在哪个计算节点上运行虚机 

nova-compute

管理虚机的核心服务，通过调用 Hypervisor API 实现虚机生命周期管理 

Hypervisor

计算节点上跑的虚拟化管理程序，虚机管理最底层的程序。 不同虚拟化技术提供自己的 Hypervisor。 常用的 Hypervisor 有 KVM，Xen， VMWare 等 

nova-conductor

nova-compute 经常需要更新数据库，比如更新虚机的状态。 出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor，这个我们在后面会详细讨论。 

Console Interface

nova-console

用户可以通过多种方式访问虚机的控制台： nova-novncproxy，基于 Web 浏览器的 VNC 访问 nova-spicehtml5proxy，基于 HTML5 浏览器的 SPICE 访问 nova-x***vncproxy，基于 Java 客户端的 VNC 访问 

nova-consoleauth

负责对访问虚机控制台请亲提供 Token 认证 

nova-cert

提供 x509 证书支持 

Database

Nova 会有一些数据需要存放到数据库中，一般使用 MySQL。 数据库安装在控制节点上。 Nova 使用命名为 “nova” 的数据库。 

Message Queue

在前面我们了解到 Nova 包含众多的子服务，这些子服务之间需要相互协调和通信。 为解耦各个子服务，Nova 通过 Message Queue 作为子服务的信息中转站。 所以在架构图上我们看到了子服务之间没有直接的连线，它们都通过 Message Queue 联系。 

OpenStack 默认是用 RabbitMQ 作为 Message Queue。 MQ 是 OpenStack 的核心基础组件，我们后面也会详细介绍。