动手玩 Nova：Hypervisor、主机聚合、可用分区、虚拟机生命周期实操

文章目录

[OpenStack 计算管理](#OpenStack 计算管理)
- OpenStack计算管理-nova
- 实践
- [OpenStack Dashboard 操作](#OpenStack Dashboard 操作)
- - [Hypervisor 和主机聚合管理](#Hypervisor 和主机聚合管理)
  - 实例类型（规格）管理
  - 密钥和虚拟机组管理
  - 创建网络
  - 虚拟机实例操作
- [OpenStack CLI 操作](#OpenStack CLI 操作)

OpenStack 计算管理

OpenStack计算管理-nova

nova负责：

虚拟机生命周期管理 •其他计算资源生命周期管理

nova不负责：

承载虚拟机的物理主机自身的管理 •全面的系统状态监控

nova系统架构

DB：用于数据存储的SQL数据库。 •API：接收 HTTP 请求、转换命令并通过oslo.messaging队列或 HTTP与其他组件通信的组件。 •Scheduler：为虚拟机选择合适的物理主机。 •Compute：虚拟机生命周期和复杂流程控制。 •Conductor：处理需要协调（构建/调整大小）的请求，充当数据库代理或处理对象转换。 •Placement：跟踪资源提供者的库存和使用情况。 •RPC：Remote Procedure Call，远程过程调用，是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。 •API服务器处理REST请求，通常涉及数据库读写，将RPC消息发送到其他Nova服务（可选），并生成对 REST调用的响应。 •RPC消息传递是通过oslo.messaging库完成的，它是消息队列之上的抽象。 •Nova使用基于消息传递的"无共享"架构，大多数主要的nova组件可以在多个服务器上运行，并且有一个监听RPC消息的管理器。查看控制节点，计算节点的nova服务：

控制节点：

计算节点：

nova物理部署

检查RabbitMQ服务是否正常：

bash 复制代码

# 执行命令：systemctl status rabbitmq-server.service
[root@controller ~(keystone_admin)]# systemctl status rabbitmq-server.service

nova服务运行架构

Nova服务各组件可分布式部署，且可通过virtDriver对接不同的虚拟化平台。

nova-api

nova-conductor

引入nova-conductor的好处： ▫安全性上考虑。之前每个nova-compute都是直接访问数据库的。如果由于某种原因，某个计算节点被攻陷了，那攻击者就可以获取访问数据库的全部权限，肆意操作数据库。 ▫方便升级。将数据库和nova-compute解耦，如果数据库的模式改变，nova-compute就不用升级了。 ▫性能上考虑。之前数据库的访问在nova-compute中直接访问且数据库访问是阻塞性的，由于nova- compute只有一个os线程，所以当一个绿色线程去访问数据库的时候会阻塞其他绿色线程，导致绿色线程无法并发。但是nova-conductor是通过rpc 调用，rpc调用是绿色线程友好的，一个rpc call的执行返回前不会阻塞其他绿色线程的执行。这样就会提高了操作的并发。查看nova.conf

bash 复制代码

# 编辑/etc/nova/nova.conf配置文件
[root@controller ~(keystone_admin)]# vim /etc/nova/nova.conf
nova-api、nova-conductor操作数据库由下面两行配置文件决定
1132 connection=mysql+pymysql://nova_api:d247d6a4c7f14f2f@192.168.108.10/nova_api
1763 connection=mysql+pymysql://nova:d247d6a4c7f14f2f@192.168.108.10/nova

nova-scheduler

Nova-Scheduler：确定将虚拟机分配到哪一台物理机，分配过程主要分为两步，过滤和权重；用户创建虚拟机时会提出资源需求，例如CPU、内存、磁盘各需要多少，OpenStack将这些需求定义在flavor中，用户只需要指定flavor就可以了。 •调度过程分为两步： ▫通过过滤器选择满足条件的计算节点； ▫通过权重选择最优的节点。下面介绍 nova-scheduler 是如何实现调度的。在 /etc/nova/nova.conf 中，nova 通过 scheduler_driver，scheduler_available_filters 和 scheduler_default_filters 这三个参数来配置 nova- scheduler。 Filter scheduler Filter scheduler 是 nova-scheduler 默认的调度器，调度过程分为两步： 1. 通过过滤器（filter）选择满足条件的计算节点（运行 nova-compute）

通过权重选择分值最高的服务器上创建 Instance。 scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler Nova 允许使用第三方 scheduler，配置 scheduler_driver 即可。这又一次体现了OpenStack的开放性。Scheduler 可以使用多个 filter 依次进行过滤，过滤之后的节点再通过计算权重选出最适合的节点。

上图是调度过程的一个示例： 1. 最开始有 6 个计算节点 Host1-Host6 2. 通过多个 filter 层层过滤，Host2 和 Host4 没有通过，被刷掉了 3. Host1，Host3，Host5，Host6 计算权重，结果 Host5 得分最高，最终入选 Filter 当 Filter scheduler 需要执行调度操作时，会让 filter 对计算节点进行判断，filter 返回 True 或 False。

bash 复制代码

Nova.conf 中的 available_filters 选项用于配置 scheduler 可用的 filter，默认是所有 nova 自带的

filter 都可以用于滤操作。

bash 复制代码

# 编辑/etc/nova/nova.conf配置文件
[root@controller ~]# vim /etc/nova/nova.conf
1931 available_filters=nova.scheduler.filters.all_filters
另外还有一个选项 enabled_filters ，用于指定 scheduler 真正使用的 filter，默认值如下

# 编辑/etc/nova/nova.conf配置文件
[root@controller ~]# vim /etc/nova/nova.conf
1938 
enabled_filters=AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,Im
agePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter

scheduler 按照列表中的顺序依次过滤。下面依次介绍每个 filter。

RetryFilter RetryFilter 的作用是刷掉之前已经调度过的节点。举个例子方便大家理解：假设 A,B,C 三个节点都通过了过滤，最终 A 因为权重值最大被选中执行操作。但由于某个原因，操作在 A 上失败了。默认情况下，nova-scheduler 会重新执行过滤操作（重复次数由 scheduler_max_attempts 选项指定，默认是 3）。那么这时候 RetryFilter 就会将 A 直接刷掉，避免操作再次失败。 RetryFilter 通常作为第一个 filter。 AvailabilityZoneFilter 为提高容灾性和提供隔离服务，可以将计算节点划分到不同的Availability Zone中。例如把一个机架上的机器划分在一个 Availability Zone 中。 OpenStack 默认有一个命名为 "nova" 的 Availability Zone，所有的计算节点初始都是放在 "nova" 中。用户可根据需要创建自己的 Availability Zone。

创建 Instance 时，需要指定将 Instance 部署到在哪个 Availability Zone中。

nova-scheduler 在做 filtering 时，会使用 AvailabilityZoneFilter 将不属于指定 Availability Zone 的计算节点过滤掉。实验案例：

将controller节点加入到gpu_az 将compute节点加入nogpu_az

创建gpu_az选择controller节点

同理，创建nogpu_az选择compute节点

AZ创建完后的现象：

思考：

bash 复制代码

此刻创建一个实例instance_gpu ，该实例要用GPU，创建实例时，选择哪个AZ?-->gpu_az---

controller

bash 复制代码

此刻创建一个实例instance_nogup ,该实例用不到GPU，创建实例时，选择哪个AZ？-->nogpu_az--

compute 前置条件，创建一个网络用于后面创建实例

创建规格

上传镜像

创建instance_gpu

选择使用cirros-0.5.2镜像

选择规格

创建instance_nogpu参考上面创建instance_gpu步骤

bash 复制代码

# 编辑/etc/nova/nova.conf配置文件
[root@controller ~]# vim /etc/nova/nova.conf
694 debug=True

# 重启openstack-nova*服务
[root@controller ~]# systemctl restart openstack-nova*

# 执行命令：tail /var/log/nova/nova-scheduler.log -f
[root@controller ~]# tail /var/log/nova/nova-scheduler.log -f

然后，参考前面创建实例的步骤，web界面创再建一个虚拟机，选择AZ，会用到AvailabitZoneFilter规则，观察log现象

RamFilter RamFilter 将不能满足 flavor 内存需求的计算节点过滤掉。对于内存有一点需要注意：为了提高系统的资源使用率，OpenStack 在计算节点可用内存时允许 overcommit，也就是可以超过实际内存大小。超过的程度是通过 nova.conf 中 ram_allocation_ratio 这个参数来控制的，默认值为 1.5 210 ram_allocation_ratio = 1.5

bash 复制代码

#将默认的1.5调整为5
 210 ram_allocation_ratio=5

其含义是：如果计算节点的内容为 10GB，OpenStack 则会认为它有 50GB（10*5）内存。

DiskFilter DiskFilter 将不能满足 flavor 磁盘需求的计算节点过滤掉。Disk 同样允许 overcommit，通过 nova.conf 中 disk_allocation_ratio 控制，默认值为 1 216 #disk_allocation_ratio= CoreFilter CoreFilter 将不能满足 flavor vCPU 需求的计算节点过滤掉。vCPU 同样允许 overcommit，通过 nova.conf 中 cpu_allocation_ratio 控制，默认值为 16 203 cpu_allocation_ratio=16.0 这意味着一个 8 vCPU 的计算节点，nova-scheduler 在调度时认为它有 128 个 vCPU。需要提醒的是： nova-scheduler 默认使用的 filter 并没有包含 CoreFilter。如果要用，可以将 CoreFilter 添加到 nova.conf 的 scheduler_default_filters 配置选项中。 ComputeFilter ComputeFilter 保证只有 nova-compute 服务正常工作的计算节点才能够被 nova-scheduler调度。 ComputeFilter 显然是必选的 filter。

ComputeCapabilitiesFilter ComputeCapabilitiesFilter 根据计算节点的特性来筛选。这个比较高级，我们举例说明。例如我们的节点有 x86_64 和 ARM 架构的，如果想将 Instance 指定部署到 x86_64 架构的节点上，就可以利用 ComputeCapabilitiesFilter。还记得 flavor 中有个 Metadata 吗，Compute 的 Capabilitie s就在 Metadata中指定。

"Compute Host Capabilities" 列出了所有可设置 Capabilities。

点击 "Architecture" 后面的 "+"，就可以在右边的列表中指定具体的架构。

配置好后，ComputeCapabilitiesFilter 在调度时只会筛选出 x86_64 的节点。如果没有设置 Metadata，ComputeCapabilitiesFilter 不会起作用，所有节点都会通过筛选。 ImagePropertiesFilter ImagePropertiesFilter 根据所选 image 的属性来筛选匹配的计算节点。跟 flavor 类似，image 也有 metadata，用于指定其属性。

例如希望某个 image 只能运行在 kvm 的 hypervisor 上，可以通过 "Hypervisor Type" 属性来指定。

点击 "+"，然后在右边的列表中选择 "kvm"。

配置好后，ImagePropertiesFilter 在调度时只会筛选出 kvm 的节点。如果没有设置 Image 的 Metadata，ImagePropertiesFilter 不会起作用，所有节点都会通过筛选。 ServerGroupAntiAffinityFilter(反亲和性) ServerGroupAntiAffinityFilter 可以尽量将 Instance 分散部署到不同的节点上。例如有 inst1，inst2 和 inst3 三个 instance，计算节点有 A,B 和 C。为保证分散部署，进行如下操作： 1. 创建一个 anti-affinity 策略的 server group "group-1" nova server-group-create --policy anti-affinity group-1 请注意，这里的 server group 其实是 instance group，并不是计算节点的 group。 2. 依次创建 Instance inst1, inst2和inst3并放到group-1中

nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst1 nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst2 nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst3 因为 group-1 的策略是 AntiAffinity，调度时 ServerGroupAntiAffinityFilter 会将 inst1, inst2 和 inst3 部署到不同计算节点 A, B 和 C。目前只能在 CLI 中指定 server group 来创建 instance。创建 instance 时如果没有指定 server group，ServerGroupAntiAffinityFilter 会直接通过，不做任何过滤。 ServerGroupAffinityFilter 与 ServerGroupAntiAffinityFilter 的作用相反，ServerGroupAffinityFilter 会尽量将 instance 部署到同一个计算节点上。方法类似 1. 创建一个 affinity 策略的 server group "group-2" nova server-group-create --policy affinity group-2 2. 依次创建 instance inst1, inst2 和 inst3 并放到 group-2 中 nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst1 nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst2 nova boot --image IMAGE_ID --flavor 1 --hint group=group-2 inst3 因为 group-2 的策略是 Affinity，调度时 ServerGroupAffinityFilter 会将 inst1, inst2 和 inst3 部署到同一个计算节点。创建 instance 时如果没有指定 server group，ServerGroupAffinityFilter 会直接通过，不做任何过滤。 Weight 经过前面一堆 filter 的过滤，nova-scheduler 选出了能够部署 instance 的计算节点。如果有多个计算节点通过了过滤，那么最终选择哪个节点呢？ Scheduler 会对每个计算节点打分，得分最高的获胜。打分的过程就是 weight，翻译过来就是计算权重值，那么 scheduler 是根据什么来计算权重值呢？目前 nova-scheduler 的默认实现是根据计算节点空闲的内存量计算权重值：空闲内存越多，权重越大，instance 将被部署到当前空闲内存最多的计算节点上。创建一个实例，观看日志先开启debug:

bash 复制代码

# 编辑/etc/nova/nova.conf配置文件
[root@controller ~]# vim /etc/nova/nova.conf
694 debug=True

# 重启openstack-nova*服务
[root@controller ~]# systemctl restart openstack-nova*

记录创建的实例id

日志是时候完整的回顾一下 nova-scheduler 的工作过程了。整个过程都被记录到 /var/log/nova- scheduler.log的日志文件中。

bash 复制代码

# 查看/var/log/nova/nova-scheduler.log |文件内容
[root@controller nova(keystone_admin)]# cat /var/log/nova/nova-scheduler.log | grep Filter

日志显示初始有两个 host（在我们的实验环境中就是controller 和compute），依次经过6 个 filter 的过滤（AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGrou pAntiAffin ityFilter,ServerGroupAffinityFilter），两个计算节点都通过了。那么接下来就该 weight 了：

bash 复制代码

# 查看/var/log/nova/nova-scheduler.log |文件内容
[root@controller nova(keystone_admin)]# cat /var/log/nova/nova-scheduler.log | grep weight
2024-09-25 16:28:52.882 16246 DEBUG nova.scheduler.filter_scheduler [req-
ee2f456e-9997-4d83-95b0-083b69b903da 7ef9147a8abe485889ece90dce340ab1 
03e49a46342d48ab9607b4919925e42c - default
compute ram: 15217MB disk: 58368MB io_ops: 0 instances: 0, weight: 3.0],
controller ram: 15217MB disk: 54272MB io_ops: 0 instances: 0, weight: 
2.9298on3.6/site-packages/nova/scheduler/filter_scheduler.py:462

经过权重比较，做种compute获胜

bash 复制代码

# 查看/var/log/nova/nova-scheduler.log |文件内容
[root@controller nova(keystone_admin)]# cat /var/log/nova/nova-scheduler.log | grep Select

可以看到因为compute的硬盘比 controller 多（58368 > 54272），权重值更大（3.0 > 2.928），最终选择 compute。注意：生产环境没有故障时，不要开启deubg,浪费性能

nova-compute

虚拟机生命周期操作的真正执行者（会调用对应的hypervisor的driver）。 •底层对接不同虚拟化的平台（KVM/VMware/XEN/Ironic等）。 •内置周期性任务，完成资源刷新，虚拟机状态同步等功能。 •资源管理模块（resource_tracker）配合插件机制，完成资源的统计。配置compute节点配置文件，定义driver:

bash 复制代码

# 编辑/etc/nova/nova.conf配置文件
[root@compute ~]# vim /etc/nova/nova.conf
53 compute_driver=libvirt.LibvirtDriver

# 切换到/usr/lib/python3.6/site-packages/nova/virt/目录
[root@compute ~]# cd /usr/lib/python3.6/site-packages/nova/virt/

# 列出当前目录内容
[root@compute virt]# ls
arch.py          driver.py    hyperv         __init__.py          netutils.py  
storage_users.py
block_device.py  event.py     image          interfaces.template  osinfo.py    
virtapi.py
configdrive.py   fake.py      imagecache.py  ironic               powervm      
vmwareapi
disk             hardware.py  images.py      libvirt              __pycache__  
zvm

RabbitMQ性能查看

启用 RabbitMQ 管理 plugin

查看RabbitMQ服务状态：

bash 复制代码

# 执行命令：systemctl status rabbitmq-server.service
[root@controller ~]# systemctl status rabbitmq-server.service
● rabbitmq-server.service - RabbitMQ broker
   Loaded: loaded (/usr/lib/systemd/system/rabbitmq-server.service; enabled; 
vendor preset: disabled)
  Drop-In: /etc/systemd/system/rabbitmq-server.service.d
           └─90-limits.conf
   Active: active (running) since Thu 2024-09-26 09:06:19 CST; 18min ago
 Main PID: 1721 (beam.smp)
   Status: "Initialized"
    Tasks: 91 (limit: 100416)
   Memory: 118.7M
   CGroup: /system.slice/rabbitmq-server.service
           ├─1721 /usr/lib64/erlang/erts-10.7.2.1/bin/beam.smp -W w -A 64 -MBas 
ageffcbf -MHas ageffcbf -MBlmbcs 512>
           ├─2144 /usr/lib64/erlang/erts-10.7.2.1/bin/epmd -daemon
           ├─3100 erl_child_setup 16384
           ├─7806 inet_gethost 4
           └─7807 inet_gethost 4

默认安装中，我们只能用命令 rabbitmqctl 监控 RabbitMQ，比如：rabbitmqctl list_queues， rabbitmqctl list_exchanges 等子命令。这种方式不太直观，效率不高。好在 RabbitMQ 有一个管理 plugin，提供了图形管理界面，可以在运行 RabbitMQ 的节点（一般是控制节点）执行下面的命令启用。

bash 复制代码

# 执行命令：rabbitmq-plugins enable rabbitmq_managem
[root@controller ~]# rabbitmq-plugins enable rabbitmq_management
Enabling plugins on node rabbit@controller:
rabbitmq_management
The following plugins have been configured:
rabbitmq_management
rabbitmq_management_agent
rabbitmq_web_dispatch
Applying plugin configuration to rabbit@controller...
The following plugins have been enabled:
rabbitmq_management
rabbitmq_management_agent
rabbitmq_web_dispatch
started 3 plugins.

然后还需要创建一个用户，用来登录管理控制台了。

bash 复制代码

# 执行命令：iptables -F
[root@controller ~]# iptables -F

# 执行命令：rabbitmqctl add_user user_admin passwd_a
[root@controller ~]# rabbitmqctl add_user user_admin passwd_admin   #创建用户名密码
Adding user "user_admin" ...

# 执行命令：rabbitmqctl set_user_tags user_admin adm
[root@controller ~]# rabbitmqctl set_user_tags user_admin administrator
rabbitmqctl set_permissions -p / user_admin ".*" ".*" ".*"    #授权
Setting tags for user "user_admin" to [administrator, rabbitmqctl, 
set_permissions, user_admin, .*, .*, .*] ...
[root@controller ~]#

然后就可以用 user_admin（密码 passwd_admin）登录了，地址是 http://192.168.108.10:15672

观察Unacked Unacked Message 指的是还没有被处理的消息。正常情况下，这个值应该为 0。如不是 0，并且持续增长，那你就得注意了，这意味着RabbitMQ 出现了问题，队列开始积压，消息开始堆积，是一个严重的信号。

接下来怎么办呢？这个时候就可以点开 Overview 后面的标签，查看到底消息是在哪个或者哪些 Connection，Channel， Exchange，Queues 中堆积，进而分析问题的根源并解决。

查看nova相关服务

nova-console控制台：用户由多种方式访问虚拟控制台 nova-novncproxy，基于 Web 浏览器的 VNC 访问 nova-spicehtml5proxy，基于 HTML5 浏览器的 SPICE 访问 nova-xvpnvncproxy，基于 Java 客户端的 VNC 访问

bash 复制代码

# 加载keystonerc_admin环境变量
[root@controller ~]# source keystonerc_admin
#查看nova组件分部安装在哪些设备上，状态是否正常
[root@controller ~(keystone_admin)]# openstack compute service list
+----+----------------+------------+----------+---------+-------+----------------
------------+
| ID | Binary         | Host       | Zone     | Status  | State | Updated At     
            |
+----+----------------+------------+----------+---------+-------+----------------
------------+
|  1 | nova-conductor | controller | internal | enabled | up    | 2024-09-
26T01:40:15.000000 |
|  2 | nova-scheduler | controller | internal | enabled | up    | 2024-09-
26T01:40:17.000000 |
|  5 | nova-compute   | controller | nova     | enabled | up    | 2024-09-
26T01:40:21.000000 |
|  6 | nova-compute   | compute    | nova     | enabled | up    | 2024-09-
26T01:40:19.000000 |
+----+----------------+------------+----------+---------+-------+----------------
------------+
[root@controller ~(keystone_admin)]#

创建虚拟机过程(简单)

客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求："帮我创建一个 Instance" 2. API对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息："让 Scheduler 创建一个 Instance" 3. Scheduler（nova-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计算节点中选出节点 A。请参考看 nova-scheduler 如何选择计算节点 4. Scheduler 向 Messaging 发送了一条消息："在计算节点 A 上创建这个 Instance" 5. 计算节点 A 的 Compute（nova-compute）从 Messaging 中获取到 Scheduler 发给它的消息，然后通过本节点的 Hypervisor Driver 创建 Instance。请参考 nova-compute 部署 instance详解 6. 在 Instance 创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向 Conductor（nova-conductor）发送消息，Conductor 负责数据库访问。如何观察现象，在配置文件中打开debug，分别tail -f (nova-api，nova-scheduler，nova- conductor，nova-compute)这些组件，然后创建实例，观察日志，就可以看到现象

创建虚拟机过程(详细)

Step1：用户通过Dashboard/CLI 申请创建虚拟机，并以REST API 方式来请求Keystone授权。 •Step2：keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。 •Step3：界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）。 •Step4：nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。 •Step5：keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。 •Step6：通过认证后nova-api和数据库通讯。 •Step7：初始化新建虚拟机的数据库记录。 •Step8：nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源（Host ID）。 •Step9：nova-scheduler进程侦听消息队列，获取nova-api的请求。 •Step10：nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。 •Step11：对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。 •Step12：nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。 •Step13：nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。 •Step14：nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。 •Step15：nova-conductor从消息队队列中拿到nova-compute请求消息。 •Step16：nova-conductor根据消息查询虚拟机对应的信息。 •Step17：nova-conductor从数据库中获得虚拟机对应信息。 •Step18：nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。 •Step19：nova-compute从对应的消息队列中获取虚拟机信息消息。 •Step20：nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。 •Step21：glance-api向keystone认证token是否有效，并返回验证结果。
Step22：token验证通过，nova-compute获得虚拟机镜像信息（URL）。 •Step23：nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron- server获取创建虚拟机所需要的网络信息。 •Step24：neutron-server向keystone认证token是否有效，并返回验证结果。 •Step25：token验证通过，nova-compute获得虚拟机网络信息。 •Step26：nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。 •Step27：cinder-api向keystone认证token是否有效，并返回验证结果。 •Step28：token验证通过，nova-compute获得虚拟机持久化存储信息。 •Step29：nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

nova操作

创建实例首先，一个实例创建最少需要以下资源：规格镜像网络创建规格

创建镜像

创建网络

创建实例

如果创建实例是灰的，点击下一步，寻找创建的网络关闭实例

启动实例

软重启与硬重启区别

soft reboot 与 hard reboot 的区别在于： 1. soft reboot 只是重启操作系统，整个过程中， instance 依然处于运行状态。相当于在 linux 中执行 reboot 命令 2. hard reboot 是重启 instance，相当于关机之后再开机

暂停实例与挂起实例区别

有时需要短时间暂停 instance，可以通过 Pause 操作将 instance 的状态保存到宿主机的内存中。当需要恢复的时候，执行 Resume 操作，从内存中读回 instance 的状态，然后继续运行 instance。有时需要长时间暂停 instance，可以通过 Suspend 操作将 instance 的状态保存到宿主机的磁盘上。需要恢复的时候，执行 Resume 操作，从磁盘读回 instance 的状态，然后继续运行。这里需要对 Suspend 和 Pause 做个比较：相同点两者都是暂停 instance 的运行，并保存当前状态，之后可以通过 Resume 操作恢复。不同点 1. Suspend (挂起)将 instance 的状态保存在磁盘； Pause(暂停) 是保存在内存中，所以 Resume (恢复)被 Pause 的 instance 要比 Suspend 快。 2. instance 被 Suspend 后，状态为 Shut Down；而被 Pause 的 instance 状态是 Paused。 3. 虽然都是通过 Resume 操作恢复， Pause 对应的 Resume 在 OpenStack 内部被叫作 "Unpause" ； Suspend 对应的 Resume 才是真正的 "Resume" 。这个在日志中能体现出来。

废弃实例

Instance 被 Suspend 后虽然处于 Shut Down 状态，但 Hypervisor 依然在宿主机上为其预留了资源，以便在以后能够成功 Resume。如果希望释放这些预留资源，可以使用 Shelve 操作。 Shelve 会将 instance 作为 image 保存到 Glance 中，然后在宿主机上删除该instance。锁定实例

创建普通用户用于测试：

创建好普通用户后，用普通用户登陆WEB界面，尝试删除锁定的实例，发现无法删除尝试解锁实例，发现可以解锁锁定实例: 防止意外删除，要先解锁，才能删除admin锁定的实例管理员对于上锁的实例，能不能不解锁直接删除---->能管理员上锁后，普通用户能不能直接删除--->不能管理源创建的实例不上锁，普通用户能不能直接删除--->能普通用户能不能解锁---->能管理员加锁，普通用户可以解锁为什么普通用户可以解锁？

bash 复制代码

# 切换到/etc/openstack-dashboard/目录
[root@controller ~(keystone_admin)]# cd /etc/openstack-dashboard/

# 列出当前目录内容
[root@controller openstack-dashboard(keystone_admin)]# ls
cinder_policy.json  glance_policy.json  keystone_policy.json  local_settings  
local_settings.d  neutron_policy.json  nova_policy.d  nova_policy.json

# 编辑nova_policy.json配置文件
[root@controller openstack-dashboard(keystone_admin)]# vim nova_policy.json
69     "os_compute_api:os-lock-server:lock": "rule:admin_or_owner",
70     "os_compute_api:os-lock-server:unlock": "rule:admin_or_owner",
71     "os_compute_api:os-lock-server:unlock:unlock_override": "rule:admin_api",

发现，普通用户可以直接解锁，解锁再删除(虽然难删除一些，但是还是能删除) ！！！防止意外删除配置让普通用户不能解锁

bash 复制代码

# 编辑nova_policy.json配置文件
[root@controller openstack-dashboard(keystone_admin)]# vim nova_policy.json
69     "os_compute_api:os-lock-server:lock": "rule:admin_or_owner",
70     "os_compute_api:os-lock-server:unlock": "rule:admin_api",
71     "os_compute_api:os-lock-server:unlock:unlock_override": "rule:admin_api",

实验效果：切换到普通用户不能够解锁，admin能够解锁(清空网页缓存) 重建实例虚拟机奔溃了可以拿原有镜像重建实例

实践

关于本实验

本实验主要介绍如何通过OpenStack Dashboard 和OpenStack CLI 两种方式管理Hypervisor、主机聚合、规

格、密钥对以及虚拟机组，最后介绍了虚拟机实例的发放、生命周期管理以及快照和重建等基本操作。

实验目的

⚫ 熟悉OpenStack Dashboard 和OpenStack CLI 主机聚合的创建和操作方法。

⚫ 熟悉OpenStack Dashboard 和OpenStack CLI 规格的创建和操作方法。

⚫ 熟悉OpenStack Dashboard 和OpenStack CLI 密钥对和虚拟机组的创建和操作方法。

⚫ 熟悉OpenStack Dashboard 和OpenStack CLI 虚拟机实例的发放、生命周期管理以及快照和重建等基本操作

方法。

实验流程

OpenStack Dashboard 操作

Hypervisor 和主机聚合管理

使用admin 用户登录OpenStack Dashboard 界面，在左侧导航栏，选择"管理员>计算>虚拟机管理器"，

进入虚拟机管理器概述列表，查看虚拟机管理概览等信息。

选择"计算主机"页签，进入计算主机列表，查看计算节点信息。

在左侧导航栏，选择"管理员 > 计算> 主机聚合"，进入主机聚合列表，单击页面右上方的"创建主机

聚合"。

弹出创建主机聚合对话框，在"主机聚合信息"页签，输入主机聚合名称"HostAggr_web"和可用分区

名称"nova"。

选择"管理聚合内的主机"页签，单击左侧可用主机"controller"后面的，右侧将显示选择的主

机，单击"创建主机聚合"，完成主机聚合的创建。

返回主机聚合列表，显示刚刚创建的主机聚合。

验证：

参考步骤3~6，创建主机聚合"HostAggr_web_test"，可用分区设置为"AZ_web"，添加主机

"controller"，是否能成功，即同一个主机是否可以加入不同的AZ。

单击主机聚合"HostAggr_web_test"所在行"Actions"列的"编辑主机聚合"，将可用分区设置为

"nova"，单击"提交"。单击主机聚合"HostAggr_web_test"所在行"Actions"列方框中的，在操

作列表中选择"管理主机"，添加主机"controller"，是否能成功，即同一个主机是否可以加入不同的

主机聚合。

单击待操作的主机聚合"HostAggr_web_test"所在行"Actions"列方框中的，在操作列表中选择"管

理主机"。

弹出从主机聚合中添加/移除主机的对话框，单击右侧主机后面的，主机将显示在左侧可用主机列表

中，单击"保存"。

返回主机聚合列表，勾选主机聚合 "HostAggr_web_test"，单击"删除主机聚合"。

弹出如下确认信息提示框，单击"删除主机聚合"。

实例类型（规格）管理

在左侧导航栏，选择"管理员>计算>实例类型"，进入规格列表，单击页面右上方的"创建实例类

型"。

弹出创建规格对话框，在"实例类型信息"页签，填写如下信息：

⚫ 名称：规格的名称，可自定义，如"Flavor_web"。

⚫ VCPUs：规格的VCPU 数量，如"1"。

⚫ RAM (MB)：规格的RAM 大小，如"128"。

⚫ Root Disk (GB)：规格的根磁盘大小，如"1"。

⚫ 其他保持默认。

选择"实例类型使用权"页签，单击页面左侧项目列表中项目名称后面的，如项目"Project_web"，

页面右侧将显示选择的项目，表示该规格可以被项目"Project_web"使用，单击"创建实例类型"。

参考步骤3 在创建规格"Flavor_web_test"时未选择任何项目，则默认该规格对所有项目可用，即该规格

是"Public"的。

验证：

规格"Flavor_web"创建完成后，若移除选择的项目，是否表示该规格为"Public"？

具体方法如下：

单击待操作规格"Flavor_web"所在行方框中的"修改使用权"。

弹出编辑规格对话框，单击右侧项目后面的，移除选择的项目，单击"保存"。

返回规格列表，查看规格的"Public"状态。

结论：

规格"Flavor_web"仍为"Private"，说明移除选择的所有项目，仅表示该规格不对任何项目可用（具

有admin 角色的用户能看到该规格，但无法使用该规格，其他用户既无法看到该规格也无法使用该规

格），而非"Public"。

规格创建后，不支持变更（包括变更为"Public"和"Private"），若需要变更规格，只能重新创建新

的规格。

在待操作的规格所在行，单击最后方框中的，在操作列表中选择"删除实例类型"，删除该规格。(注

意：删除的是Flavor_web)

弹出如下确认信息提示框，单击"删除实例类型"。

密钥和虚拟机组管理

在左侧导航栏，选择"项目>计算>密钥对"，进入密钥对列表，单击页面右上方的"创建密钥对"（在

标准的写法中应该是密钥，因此本文中统一使用密钥）。

弹出创建密钥对对话框，输入密钥对名称"KeyPair_web"，选择密钥类型"SSH Key"，单击"创建密钥

对"。

弹出打开密钥对创建成功提示，并请下载密钥对。

打开下载的密钥对，显示如下：

返回密钥对列表，显示创建的密钥对。

在左侧导航栏，选择"项目>计算>主机组"，进入虚拟机组列表，单击页面右上方"创建服务器组"。

弹出创建虚拟机组对话框，输入服务器组名称"ServerGroup_web"，选择策略类型。有如下4 种策略类

型：

关联：亲和性，同一个虚拟机组中的虚拟机必须共存在同一台主机上。

不关联：反亲和性，同一个虚拟机组中的虚拟机不能共存在同一台主机上。

软不关联：弱反亲和性，若组内虚拟机调度的主机资源充足，则与反亲和性策略保持一致；若组内虚拟

机调度的主机资源不足，则自动忽略弱反亲和性规则。

软关联：弱亲和性，若组内虚拟机调度的主机资源充足，则与亲和性策略保持一致；若组内虚拟机调度

的主机资源不足，则自动忽略弱亲和性规则。

此处策略选择"关联"，单击"提交"。

返回主机组列表，显示创建的虚拟机组。

创建网络

创建shared 网络

创建网络

虚拟机实例操作

发放虚拟机实例

使用admin 用户登录OpenStack Dashboard 界面，在左侧导航栏，选择"项目>计算> 实例"，进入虚拟

机实例列表，单击页面上方的"创建实例"。

弹出发放虚拟机实例对话框，在"详情"页签。输入虚拟机实例名称"Instance_web_01"，选择发放虚

拟实例的可用分区"nova"和数量"1"，单击"下一项"。

进入"源"页签，在"创建新卷"下方选择"否"，单击"可用"下方列表中镜像"Img_web"最后

的，"已分配"下方列表中将显示选择的镜像，其他保持默认，单击"下一项"。

进入"实例类型"页签，单击"可用"下方列表中规格"Flavor_web_test"最后的，"已分配"下方

列表中将显示选择的规格，单击"下一项"。

进入"网络"页签， "已分配"下方列表中将显示选择的网络，单击 3 次"下一项"。

进入"Key Pair"页签，"已分配"下方列表中将显示已创建的密钥对"KeyPair_web"，单击2 次"下一

项"。

进入"服务器组"页签，单击"可用"下方列表中服务器组"ServerGroup_web"最后的，"已分

配"下方列表中将显示选择的服务器组和策略，单击"创建实例"。

返回虚拟机实例列表，显示刚刚创建的虚拟机实例，且状态为"运行"。

虚拟机实例开启、关闭与重启

在左侧导航栏，选择"项目> 计算>实例"，进入虚拟机实例列表。单击待操作的虚拟机实例所在行

"Actions"列方框中的，在操作列表中选择"关闭实例"，关闭虚拟机实例。

弹出如下确认信息对话框，单击"关闭实例"。

返回虚拟机实例列表，虚拟机实例状态变为"关机"。

单击待操作的虚拟机实例所在行"Actions"列方框中的"启动实例"，开启虚拟机实例。

等待虚拟机实例状态重新变为"运行中"，虚拟机实例启动成功。

单击待操作的虚拟机实例所在行"Actions"列方框中的，在操作列表中选择"软重启实例"，软重启

虚拟机实例。

弹出如下确认信息对话框，单击"软重启实例"。

等待虚拟机实例状态重新变为"运行"，虚拟机实例启动成功。

参考步骤6~8，在操作列表中选择"硬重启实例"，硬重启虚拟机实例。

虚拟机实例锁定、解锁

在左侧导航栏，选择"项目>计算>实例"，进入虚拟机实例列表。单击待操作的虚拟机实例所在行

"Actions"列方框中的，在操作列表中选择"锁定实例"，锁定虚拟机实例。

返回虚拟机实例列表，观察虚拟机实例的锁标志。

验证：

虚拟机实例在锁定状态时，使用admin 用户是否可执行关闭虚拟机实例？使用普通用户

"User_web_01"是否可执行关闭虚拟机实例（登录后在页面上方切换到"admin"项目）？

重新使用admin 用户登录OpenStack Dashboard 页面，在左侧导航栏，选择"项目>计算>实例"，进入虚

拟机实例列表。单击待操作的虚拟机实例所在行"Actions"列方框中的，在操作列表中选择"解锁实

例"，解锁虚拟机实例。

返回虚拟机实例列表，观察虚拟机实例的锁标志。

验证：

重新锁定虚拟机实例，并使用普通用户"User_web_01"验证是否可以对admin 用户锁定的虚拟机实

例解锁（登录后在页面上方切换到"admin"项目）？

虚拟机实例暂停、挂起和恢复

在左侧导航栏，选择"项目>计算>实例"，进入虚拟机实例列表。单击待操作的虚拟机实例所在行

"Actions"列方框中的，在操作列表中选择"暂停实例"，暂停虚拟机实例。

返回虚拟机实例列表，虚拟机实例的状态变为"暂停"，电源状态变为"已暂停"。

单击待操作的虚拟机实例所在行"Actions"列方框中的，查看虚拟机实例在"暂停"状态时可执行的

操作。

在操作列表中选择"恢复实例"，恢复虚拟机实例。

返回虚拟机实例列表，观察虚拟机实例的状态重新变为"运行"，电源状态重新变为"运行中"。

单击待操作的虚拟机实例所在行"Actions"列方框中的，在操作列表中选择"挂起实例"，挂起虚拟

机实例。

返回虚拟机实例列表，观察虚拟机实例任务的变化过程，直到虚拟机实例状态变为"挂起"，电源状态

变为"关闭"。

单击待操作的虚拟机实例所在行"Actions"列方框中的，查看虚拟机实例在"挂起"状态时可执行的

操作。

在操作列表中选择"恢复实例"，恢复虚拟机实例。

返回虚拟机实例列表，观察虚拟机实例任务的变化过程，直到虚拟机实例状态重新变为"运行"，电源

状态重新变为"运行中"。

虚拟机实例废弃（搁置）和取消废弃（解搁置）

在左侧导航栏，选择"项目>计算>实例"，进入虚拟机实例列表。单击待操作的虚拟机实例所在行

"Actions"列方框中的，在操作列表中选择"废弃实例"，搁置虚拟机实例。

返回虚拟机实例列表，观察虚拟机实例任务的变化过程，直到虚拟机实例状态变为"强制搁置"，电源

状态变为"关闭"。

单击待操作的虚拟机实例所在行"Actions"列方框中的，查看虚拟机实例在"强制搁置"状态时可执

行的操作。

在操作列表中选择"取消废弃实例"，解搁置虚拟机实例。

返回虚拟机实例列表，观察虚拟机实例任务的变化过程，直到虚拟机实例状态重新变为"运行"，电源

状态重新变为"运行中"。

虚拟机实例快照和重建

在左侧导航栏，选择"项目>计算>实例"，进入虚拟机实例列表。单击待操作的虚拟机实例所在行

"Actions"列方框中的"创建快照"，为虚拟机实例创建快照。

弹出创建快照对话框，输入快照名称"Instance_Snap_web"，单击"创建快照"。

页面将自动跳转到镜像列表，列表中将显示镜像名称为"Instance_Snap_web"的镜像，等待镜像状态变

为"运行中"，表示镜像注册成功。查看其类型为"快照"，可见性为"私有"，受保护性为"否"

（注：镜像状态长时间停留在"已排队"状态，请尝试刷新页面）。

单击待操作的虚拟机实例所在行"Actions"列方框中的，在操作列表中选择"重建实例"，重建虚拟

机实例。

弹出重建虚拟机实例对话框，在"Select Image"下方选择刚刚创建的快照"Instance_Snap_web"，单击

"重建实例"。

返回虚拟机实例列表，观察虚拟机实例任务的变化过程，直到虚拟机实例状态重新变为"Active"，镜像

名称变为"Instance_Snap_web"，表示虚拟机实例恢复成功。

验证：

单击虚拟机实例名称"Instance_web_01"，选择"控制台"页签，单击"点击此处只显示控制台"，

打开独立的Console 页面，验证虚拟机实例是否可以正常登录（登录用户名和密码见系统提示）。

调整实例大小

由于是多节点，调整实例大小操作会有迁移操作，所以新建一个共享存储NFS

cinder 进行对接，相关配置放在Cinder 章节，此刻暂时看不到现象

选择"项目>计算>实例"，返回虚拟机实例列表。将鼠标移到待操作的虚拟机实例的规格名称

"Flavor_web_test"上，右侧将显示该规格的详细信息。

在左侧导航栏，选择"管理员>计算>实例类型"，进入规格列表，创建规格

"Flavor_web_new"，并将规格的内存(MB)设置为"156"，VCPU 数量和跟磁盘设置与

"Flavor_web_test"保持一致。

在左侧导航栏，选择"项目>计算>实例"，返回虚拟机实例列表。单击待操作的虚拟机实例所在行

"Actions"列方框中的，在操作列表中选择"调整实例大小"，调整虚拟机实例规格大小。

弹出调整虚拟机实例规格对话框，在"实例类型选择"页签，在"新的实例类型"下方选择刚刚创建的

规格"Flavor_web_new"，右侧将显示选择的规格的详细信息，单击下方的"调整大小"。

返回虚拟机实例列表，虚拟机实例状态为"确认或放弃调整大小/迁移"，单击"Actions"列的"确认

调整大小/迁移"。

等待虚拟机实例开始调整，直到虚拟机实例的状态重新变为"运行"，表示实例调整大小完成。

再次查看虚拟机实例的规格是否变为"Flavor_web_new"。

验证：

若步骤5，将规格的RAM (MB)设置为"64"，验证虚拟机实例是否可以Resize 成功，为什么？

这里调整实例大小会失败，由于是多节点，调整实例大小操作会有迁移操作，所以新建一个共享存储NFS

cinder 进行对接，相关配置放在Cinder 章节

虚拟机实例删除

（这里不进行删除看下怎么操作就行，在6.2.2 中将会继续使用该实例。）

在左侧导航栏，选择"项目>计算>实例"，进入虚拟机实例列表，勾选待操作虚拟机实例，单击页面上

方的"删除实例"。

弹出如下确认信息提示框，单击"取消"。

OpenStack CLI 操作

Hypervisor、主机聚合和可用分区管理

远程登录controller。执行以下命令，导入用户admin 的环境变量。

bash 复制代码

# 加载环境变量配置文件
source kestonerc_admin

执行以下命令，查看OpenStack Hypervisor 的列表。

bash 复制代码

# 列出所有虚拟化管理
openstack hypervisor list --long

执行以下命令，查看OpenStack 主机的列表。

bash 复制代码

# 列出所有host
openstack host list

执行以下命令，创建主机聚合"HostAggr_cli"。

bash 复制代码

# 创建主机聚合
openstack aggregate create --zone nova HostAggr_cli

执行以下命令，为主机聚合"HostAggr_cli"添加主机"controller"。

bash 复制代码

# 添加主机聚合
openstack aggregate add host HostAggr_cli controller

验证：

执行以下命令，验证同一个主机是否可以加入不同的AZ。

bash 复制代码

# 创建主机聚合
openstack aggregate create --zone AZ_cli HostAggr_cli_test

# 添加主机聚合
openstack aggregate add host HostAggr_cli_test controller

执行以下命令，验证同一个主机是否可以加入不同的主机聚合。

bash 复制代码

# 设置/修改主机聚合
openstack aggregate set --zone nova HostAggr_cli_test

# 查看主机聚合
openstack aggregate show HostAggr_cli_test

# 添加主机聚合
openstack aggregate add host HostAggr_cli_test controller

执行以下命令，为主机聚合"HostAggr_cli_test"移除主机"controller"。

bash 复制代码

# 移除主机聚合
openstack aggregate remove host HostAggr_cli_test controller

执行以下命令，删除主机聚合"HostAggr_cli_test"。

bash 复制代码

# 删除主机聚合
openstack aggregate delete HostAggr_cli_test

执行以下命令，查看主机聚合列表。

bash 复制代码

# 列出所有主机聚合
openstack aggregate list

规格管理

执行以下命令，创建规格"Flavor_cli"，要求设置如下：

⚫ VCPUs：规格的VCPU 数量，如"1"。

⚫ RAM (MB)：规格的RAM 大小，如"128"。

⚫ Root Disk (GB)：规格的根磁盘大小，如"1"。

⚫ 该规格仅对项目"Project_cli"可见。

⚫ 其他保持默认。

bash 复制代码

# 创建规格
openstack flavor create --vcpus 1 --ram 128 --disk 1 --private --project Project_cli Flavor_cli

执行以下命令，移除规格"Flavor_cli"对项目"Project_cli"可见。

bash 复制代码

# 清除规格
openstack flavor unset --project Project_cli Flavor_cli

执行以下命令，查看规格"Flavor_cli"的详细信息。

bash 复制代码

# 查看规格
openstack flavor show Flavor_cli

规格"Flavor_cli"仍不是"Public"。若要变更规格为"Public"，可以先删除原先的规格，再创建新的规

格。

执行以下命令，删除规格"Flavor_cli"。

bash 复制代码

# 删除规格
openstack flavor delete Flavor_cli

执行以下命令，创建规格"Flavor_cli", 要求配置如下：

⚫ VCPUs：规格的VCPU 数量，如"1"。

⚫ RAM (MB)：规格的RAM 大小，如"128"。

⚫ Root Disk (GB)：规格的根磁盘大小，如"1"。

⚫ 其他保持默认。

bash 复制代码

# 创建规格
openstack flavor create --vcpus 1 --ram 128 --disk 1 Flavor_cli

由回显信息可知，规格创建时默认为"Public"。

密钥对和虚拟机组管理

执行以下命令，创建密钥对"KeyPair_cli"。

bash 复制代码

# 创建密钥对
openstack keypair create KeyPair_cli

执行以下命令，创建虚拟机组"ServerGroup_cli"，策略设置为"Affinity"。

bash 复制代码

# group虚拟机实例
openstack server group create --policy affinity ServerGroup_cli

记录虚拟机组"ServerGroup_cli"的ID。

虚拟机实例操作

发放虚拟机实例

执行以下命令，创建虚拟机实例"Instance_cli_01"，要求配置如下：

⚫ 可用分区：nova。

⚫ 镜像：Img_cli。

⚫ 规格：Flavor_cli。

⚫ 密钥对：KeyPair_cli。

⚫ 虚拟机组：ServerGroup_cli。

⚫ 网络：shared 。

bash 复制代码

# 创建虚拟机实例
openstack server create --availability-zone nova --image Img_cli --flavor Flavor_cli --network shared --key-name KeyPair_cli --hint group=SERVER_GROUP_ID Instance_cli_01

执行以下命令，查看虚拟机实例列表，虚拟机实例"Instance_cli_01"状态为"Active"表示虚拟机实例创

建成功。

bash 复制代码

# 列出所有虚拟机实例
openstack server list

虚拟机实例开启、关闭与重启

执行以下命令，关闭虚拟机实例"Instance_cli_01"。

bash 复制代码

# stop虚拟机实例
openstack server stop Instance_cli_01

执行以下命令，查看虚拟机实例"Instance_cli_01"的状态。

bash 复制代码

# 查看虚拟机实例
openstack server show Instance_cli_01 | grep status

执行以下命令，启动虚拟机实例"Instance_cli_01"。

bash 复制代码

# start虚拟机实例
openstack server start Instance_cli_01

重复步骤2，查看虚拟机实例"Instance_cli_01"的状态。

执行以下命令，软重启虚拟机实例"Instance_cli_01"。

bash 复制代码

# 重启虚拟机实例
openstack server reboot Instance_cli_01

上述命令等同于命令：openstack server reboot --soft Instance_cli_01，命令执行后没有输出。

执行以下命令，硬重启虚拟机实例"Instance_cli_01"。

bash 复制代码

# 重启虚拟机实例
openstack server reboot --hard Instance_cli_01

虚拟机实例锁定、解锁

执行以下命令，锁定虚拟机实例"Instance_cli_01"。

bash 复制代码

# 锁定虚拟机实例
openstack server lock Instance_cli_01

执行以下命令，解锁虚拟机实例"Instance_cli_01"。

bash 复制代码

# 解锁虚拟机实例
openstack server unlock Instance_cli_01

虚拟机实例暂停、挂起和恢复

执行以下命令，暂停虚拟机实例"Instance_cli_01"。

bash 复制代码

# 暂停虚拟机实例
openstack server pause Instance_cli_01

执行以下命令，查看虚拟机实例"Instance_cli_01"的状态。

bash 复制代码

# 查看虚拟机实例
openstack server show Instance_cli_01 | grep status

执行以下命令，恢复虚拟机实例"Instance_cli_01"。

bash 复制代码

# 恢复虚拟机实例
openstack server unpause Instance_cli_01

重复步骤2，查看虚拟机实例"Instance_cli_01"的状态

执行以下命令，挂起虚拟机实例"Instance_cli_01"。

bash 复制代码

# 挂起虚拟机实例
openstack server suspend Instance_cli_01

重复步骤2，查看虚拟机实例"Instance_cli_01"的状态。

执行以下命令，恢复虚拟机实例"Instance_cli_01"。

bash 复制代码

# 恢复虚拟机实例
openstack server resume Instance_cli_01

重复步骤2，查看虚拟机实例"Instance_cli_01"的状态。

虚拟机实例废弃和取消废弃

执行以下命令，废弃虚拟机实例"Instance_cli_01"。

bash 复制代码

# 搁置虚拟机实例
openstack server shelve Instance_cli_01

执行以下命令，查看虚拟机实例"Instance_cli_01"的状态。

bash 复制代码

# 查看虚拟机实例
openstack server show Instance_cli_01 | grep status

执行以下命令，取消废弃虚拟机实例"Instance_cli_01"。

bash 复制代码

# 取消搁置虚拟机实例
openstack server unshelve Instance_cli_01

重复步骤2，查看虚拟机实例"Instance_cli_01"的状态。

虚拟机实例规格调整、快照和重建

执行以下命令，为虚拟机实例"Instance_cli_01"创建快照"Instance_Snap_cli"。

bash 复制代码

# image虚拟机实例
openstack server image create --name Instance_Snap_cli Instance_cli_01

执行以下命令，查看镜像列表。

bash 复制代码

# 列出所有镜像
openstack image list

执行以下命令，查看虚拟机实例"Instance_cli_01"的规格。

bash 复制代码

# 查看虚拟机实例
openstack server show Instance_cli_01 | grep flavor

执行以下命令，查看规格的详细信息。

bash 复制代码

# 查看规格
openstack flavor show Flavor_cli

执行以下命令，创建一个新规格"Flavor_cli_new"，将规格的RAM (MB)设置为"156"，VCPU 和RAM

设置与"Flave_cli"保持一致。

bash 复制代码

# 创建规格
openstack flavor create --vcpus 1 --ram 156 --disk 1 Flavor_cli_new

执行以下命令，为虚拟机实例"Instance_cli_01"调整实例大小。(做完共享存储回来做)

bash 复制代码

# 调整大小虚拟机实例
openstack server resize --flavor Flavor_cli_new Instance_cli_01

执行以下命令，查看虚拟机实例"Instance_cli_01"的状态。

bash 复制代码

# 列出所有虚拟机实例
openstack server list | grep Instance_cli_01

执行以下命令，确认虚拟机实例Resize。

bash 复制代码

# 调整大小虚拟机实例
openstack server resize confirm Instance_cli_01

重复步骤8，再次查看虚拟机实例"Instance_cli_01"的状态。

重复步骤4，再次查看虚拟机实例"Instance_cli_01"的规格。

规格从"Flavor_cli"变为"Flavor_cli_new"，表示调整实例大小成功。

执行以下命令，恢复虚拟机实例快照"Instance_Snap_cli"。

bash 复制代码

# 重建虚拟机实例
openstack server rebuild --image Instance_Snap_cli Instance_cli_01

执行以下命令，查看虚拟机实例"Instance_cli_01"的镜像。

bash 复制代码

# 查看虚拟机实例
openstack server show Instance_cli_01 | grep image

镜像从"Img_cli"变为"Instance_Snap_cli"，表示快照恢复成功。

4.3.4.7 虚拟机实例删除

执行以下命令，删除虚拟机实例"Instance_cli_01"。

bash 复制代码

# 删除虚拟机实例
openstack server delete Instance_cli_01

执行以下命令，查看虚拟机实例列表，是否删除成功。

bash 复制代码

# 列出所有虚拟机实例
openstack server list

实例列表为空，证明已经删除成功。