本文梳理一下 Nova 主要操作的流程。
0. Nova REST-CLI-Horizon 操作对照表
Nova 基本的 CRUD 操作和 extensions:
# | 类别 | Nova V2 REST API Action | Nova CLI | Horizon | 解释 |
虚机操作 | POST | boot | Launch Instance |
启动一个新的虚机 |
|
DELETE | delete | Terminate Instance |
关闭和删除一个虚机
|
||
confirmResize | resize-confirm | N/A |
确认 resize 操作 |
||
revertResize | resize-revert | N/A |
取消 resize 操作 |
||
reboot | reboot [--hard] |
Soft Reboot Instance Hard Reboot Instance |
重启虚机,具体分析见本文 1. 章节 |
||
changePassword | root-password | libvirt driver 没有实现 | |||
resize | resize | Resize Instance | 迁移虚机或者改变虚机的flavor: http://www.cnblogs.com/sammyliu/p/4572287.html | ||
rebuild | rebuild | Rebuild Instance | 先调用 driver.destroy (destroy domain,detach volume connections,plug VIF), 然后再调用 driver.spawn | ||
createImage | image-create | N/A | 快照。http://www.cnblogs.com/sammyliu/p/4468757.html | ||
os-start | start | Launch Instance | = hard reboot,见下面 1. 章节 | ||
os-stop | stop | Shut Off Instance | call dom.destroy | ||
admin action | pause | pause | Pause Instance | call dom.suspend | |
unpause | unpause | Resume Instance | call dom.resume | ||
suspend | suspend | N/A |
|
||
resume | resume | N/A |
|
||
migrate | migrate | N/A | http://www.cnblogs.com/sammyliu/p/4572287.html | ||
resetNetwork | N/A | libvirt 没有实现 | |||
injectNetworkInfo | N/A | Set up basic filtering (MAC, IP, and ARP spoofing protection),调用 _conn.nwfilterDefineXML(xml) | |||
lock | lock | N/A | 直接在数据库中 instance 上面设置 lock = true | ||
unlock | unlock | N/A | 直接在数据库中 instance 上面设置 lock = false | ||
createBackup | backup | N/A |
同 createImage,可以指定类型(daily 或者 weekly),和保存的 image 的最大数目,老的 image 会被删除 {"backup_type": "daily", "rotation": "2", "name": "bk"} |
||
os-migrateLive | live-migration | N/A | http://www.cnblogs.com/sammyliu/p/4572287.html | ||
os-resetState | reset-state | N/A | 传入 state 参数,直接修改数据库中 instance 的状态 | ||
bare metal | add_interface | baremetal-interface-add | TBD | ||
remove_interface | baremetal-interface-remove | TBD | |||
cloudpipe | update | cloudpipe-configure | TBD | ||
console | os-getVNCConsole | get-vnc-console | Console |
见本文第四章节 |
|
os-getSPICEConsole | get-spice-console | TBD | |||
os-getRDPConsole | get-rdp-console | TBD | |||
os-getSerialConsole | TBD | ||||
os-getConsoleOutput | console-log | View Log | 读取 虚机的 console.log 文件并返回其内容;如果没有这文件的话,则使用 “pty”,将其内容写入到 consolue文件并返回其内容。 | ||
delete | restore | restore | Terminate Instance | Restore a previously deleted (but not reclaimed) instance。直接修改数据库。 | |
forceDelete | force-delete | N/A |
有 snapshot,则全部删除;然后从 DB 中删除 instance. |
||
evacuate | evacuate | evacuate | 从 DB 中读取 instance 数据,在一个新的主机上 rebuild。 | ||
flavor access | addTenantAccess | flavor-access-add | Flavor - Modify Access | 修改 DB 中 flavor 表 | |
removeTenantAccess | flavor-access-remove | Flavor - Modify Access | 修改 DB 中 flavor 表 | ||
flavor manage | delete | flavor-delete | Flavor - Delete Flavor | 直接 DB 操作 | |
create | flavor-create | Flavor - Create Flavor | 直接 DB 操作 | ||
floating ip | addFloatingIp | floating-ip-create | Associate Floating IP | 调用 network_api.associate_floating_ip | |
removeFloatingIp | floating-ip-delete | Disassociate Floating IP | 调用 network_api.disassociate_floating_ip | ||
NIC | addFixedIp | fixed-ip-reserve |
参数 "networkId"。
|
||
removeFixedIp | fixed-ip-unreserve |
参数 "address"。
|
|||
network associate | disassociate_host | Associate or disassociate host or project to network。 call network_api.associate | |||
disassociate_project | network-disassociate | call network_api.associate | |||
associate_host | network-associate-host | call network_api.associate | |||
os network | disassociate | call network_api.associate | |||
rescue | rescue | rescue | 见本文第二章节 | ||
unrescue | unrescue | 见本文第二章节 | |||
security group | addSecurityGroup | add-secgroup | call security_group_rpcapi.refresh_security_group_rules | ||
removeSecurityGroup | secgroup-delete | call security_group_rpcapi.refresh_security_group_rules | |||
shelve | shelve | shelve | 见本文第三章节 | ||
shelveOffload | shelve-offload | 见本文第三章节 | |||
unshelve | unshelve | 见本文第三章节 |
1. Reboot (重启)
物理机有两种重启方式:一种从操作系统中重启,一种直接先断电然后再接通电源。虚机的重启也有类似的两种方式:Soft Reboot 和 Hard Reboot。nova reboot 命令在不使用 “-hard” 情况下,默认会 Soft Reboot,如果失败则会 Hard reboot;如果使用了 “-hard”,则直接 Hard reboot。
1.1 Soft reboot
Soft reboot 完全依赖于虚机的操作系统和 ACPI。其过程为:
- Shutdown domain (domain.shutdown)
- Launch domain (domain.createWithFlags)
关于 shutdown API ,它会shutdown一个虚机,但是虚机的各种附件(object)依然可以使用,只是虚机的操作系统被停止了。注意,虚机的操作系统可能会忽略该请求。这时候,shutdown 不会成功(在 CONF.libvirt.wait_soft_reboot_seconds 指定的时间内,nova发现虚机没有被 shutdown),得转到 hard reboot 了。(Shutdown a domain, the domain object is still usable thereafter, but the domain OS is being stopped. Note that the guest OS may ignore the request.)
1.2 Hard reboot
Hard reboot 比 Soft reboot 复杂、耗时长。其主要过程为:
- Destroy domain (virt_dom.destroy())。Destroy 和 Shutdown 两个 API 的区别是:shutdown domain 以后,客户机的磁盘存储处于可用状态,而且该 API 在命令发给 Guest OS 后立即返回,客户程序需要不断检查其状态来判断是否shutdown 成功;而 destroy API 执行后,客户机的所有资源都会被归还给 Hypervisor (all resources used by it are given back to the hypervisor),它的过程是首先给客户机发送一个terminate 指令比如SIGTERM,如果在一定的时间内未成功则直接发送 SIGKILL 指令将虚机杀掉。
- 根据 domain 的信息(instance, network_info, disk_info,image_meta, block_device_info)重新生成 domain 的配置 xml
- 根据 image 重新生成各镜像文件(包括 disk,disk.local 和 disk.swap)
- 连接各个 volume
- 将各个 interface 挂到 OVS 上
- 重新生成和应用 iptales 规则
- Define domain (conn.defineXML)
- Launch domain (domain.createWithFlags)
可见,hard reboot 是真正的 reboot 一个虚机。来比较一下 hard reboot 前后的虚机的磁盘和xml 文件:
#reboot 前
root@compute2:/var/lib/nova/instances/8352e969-0a25-4abf-978f-d9d0ec4de0cd# ls -l
total
-rw-rw---- root root Jun : console.log
-rw-r--r-- libvirt-qemu kvm Jun : disk
-rw-r--r-- nova nova Jun : disk.info
-rw-r--r-- libvirt-qemu kvm Jun : disk.local
-rw-r--r-- libvirt-qemu kvm Jun : disk.swap
-rw-r--r-- nova nova Jun : libvirt.xml
#reboot 后
root@compute2:/var/lib/nova/instances/8352e969-0a25-4abf-978f-d9d0ec4de0cd# ls -l
total
-rw-rw---- root root Jun : console.log
-rw-r--r-- libvirt-qemu kvm Jun : disk
-rw-r--r-- nova nova Jun : disk.info
-rw-r--r-- libvirt-qemu kvm Jun : disk.local
-rw-r--r-- libvirt-qemu kvm Jun : disk.swap
-rw-r--r-- nova nova Jun : libvirt.xml root@compute2:/var/lib/nova/instances/8352e969-0a25-4abf-978f-d9d0ec4de0cd# diff libvirt.xml libvirt.xml.ori
10c10
< <nova:creationTime>-- ::</nova:creationTime> #domain 除了创建时间不同别的都相同
---
> <nova:creationTime>-- ::</nova:creationTime>
84c84
< <source host="127.0.0.1" mode="bind" service=""/>
---
> <source host="127.0.0.1" mode="bind" service=""/>
2. Rescue (拯救)和 Unrescue
Rescue 是个很有意思的功能。它的一个使用场景是,虚机的启动盘的一个文件被误删除了导致无法再次启动了,或者 admin 的密码忘记了。Rescue 功能提供一个解决这类问题的手段。
执行 nova rescue 命令后的主要过程是:
(1)保存目前domain 的 xml 配置到 unrescue.xml 文件
(2)根据 image 重新生成启动盘 disk.swap (大小不受 falvor.root_disk_size 控制,尽可能小的一个文件)
root@compute2:/var/lib/nova/instances/8352e969-0a25-4abf-978f-d9d0ec4de0cd# qemu-img info disk.rescue
image: disk.rescue
file format: qcow2
virtual size: 39M ( bytes) #不是 falovr 里面定义的 1G 大小
disk size: 1.6M
cluster_size:
backing file: /var/lib/nova/instances/_base/fbad3d96a1727069346073e51d5bbb1824e76e34
Format specific information:
compat: 1.1
lazy refcounts: false
(3)构造一个新的 domain 的 xml 配置,使用 disk.rescue 做启动盘,将原来的 disk 挂载到该 domain,其他的盘和volume不会被挂载。
<disk type="file" device="disk">
<driver name="qemu" type="qcow2" cache="none"/>
<source file="/var/lib/nova/instances/8352e969-0a25-4abf-978f-d9d0ec4de0cd/disk.rescue"/> #新构造的启动盘
<target bus="virtio" dev="vda"/>
</disk>
<disk type="file" device="disk">
<driver name="qemu" type="qcow2" cache="none"/>
<source file="/var/lib/nova/instances/8352e969-0a25-4abf-978f-d9d0ec4de0cd/disk"/> #原来的启动盘
<target bus="virtio" dev="vdb"/>
</disk>
(4)将原来的 domain destroy 掉 (virt_dom.destroy)
(5)定义新的 domain (conn.defineXML(xml))
(6)启动新的 domain (domain.createWithFlags)
至此,nova rescue 的过程完成。用户可以 ssh 到新的虚机,修改 “Vdb“分区中的受损害的文件。然后执行 ”nova unrescue“命令。其主要过程是:
(1)读取之前保存的 unrescue.xml 文件
(2)将 rescued domain destroy 掉
(3)定义和启动新的domain(同上面5和6)
(4)删除 unrescue.xml 文件
注意,这时候文件夹中的 libvirt.xml 文件和新运行的 domain 的 xml 不一致,因为代码中没有将新的 domain 的xml 写到该文件。
3. Shelve (搁置)和 unshelve
当一个虚机不需要使用的时候,可以将其 shelve 起来。该操作会创建该虚机的一个快照并传到 Glance 中,然后在 Hypervisor 上将该虚机删除,从而释放其资源。
其主要过程为:
- destroy 虚机 (virt_dom.destroy())
- snapshot 该 domain
- 如果 CONF.shelved_offload_time == 0 的话,将domain 的各种资源(interface,volume,实例文件等),然后将其undefine (virt_dom.undefine())
其只存在于数据库和 Glance 中。运行 nova list 能看到一条记录:
| 8352e969-0a25-4abf-978f-d9d0ec4de0cd | vm11 | SHELVED_OFFLOADED | - | Shutdown | demo-net2=10.0.10.14; demo-net=10.0.0.41 |
运行 glance image-list 能看到其image:
| 6ed6eb92-ce42-46d1-ab46-259e3e235304 | vm11-shelved | qcow2 | bare | | active |
能看到该 image 的 instance 相关的属性:
s1@controller:~$ glance image-show 6ed6eb92-ce42-46d1-ab46-259e3e235304
+---------------------------------------+--------------------------------------+
| Property | Value |
+---------------------------------------+--------------------------------------+
| Property 'base_image_ref' | bb9318db---a309-268c6653b9ff |
| Property 'image_location' | snapshot |
| Property 'image_state' | available |
| Property 'image_type' | snapshot |
| Property 'instance_type_ephemeral_gb' | |
| Property 'instance_type_flavorid' | 129f237e--49fa-b489-0e41fb06b70e |
| Property 'instance_type_id' | |
| Property 'instance_type_memory_mb' | |
| Property 'instance_type_name' | tiny2 |
| Property 'instance_type_root_gb' | |
| Property 'instance_type_rxtx_factor' | 1.0 |
| Property 'instance_type_swap' | |
| Property 'instance_type_vcpus' | |
| Property 'instance_uuid' | 8352e969-0a25-4abf-978f-d9d0ec4de0cd |
| Property 'network_allocated' | True |
| Property 'owner_id' | 74c8ada23a3449f888d9e19b76d13aab |
| Property 'user_id' | bcd37e6272184f34993b4d7686ca4479 |
Unshelve 是 shelve 的反操作。它的主要过程是:
- 从 DB 中获取 network_info 和 block_device_info
- 从 Glance 中获取 image
- 象新建一个虚拟那样 spawn 新的虚机
- 调用 image API 将 image 删除
4. VNC (VNC 连接)
VNC 操作的过程:(来源)
(1)用户查询 VNC 的访问 URL。
Nova CLI 对应的命令为 “nova get-vnc-console <server> <console-type>”。 REST API 的数据格式为:{"os-getVNCConsole": {"type": "novnc"}}
“type” 参数值可以是 “novnc” 或者 “xvpvnc”。
(2)通过 RPC 调用虚机所在的 node 上的 Nova 生成一个 UUID(长度为 4)格式的 token,以及格式为 ‘<base_url>?token=<token>' 的 Access URL。
- base_url 从 CONF.novncproxy_base_url (比如 http://192.168.1.20:6080/vnc_auto.html)或者 CONF.xvpvncproxy_base_url 读取。
(3)本地Nova 调用 libvirt driver 从 domain xml 中获取 port,比如下面例子中的 5900,以及从 confi.vncserver_proxyclient_address 获取 host。
<graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0' keymap='en-us'>
<listen type='address' address='0.0.0.0'/>
</graphics>
(4)通过 RPC,调用 consoleauth 的 authorize_console 方法,它将 Access URL, host,port 保存到 memcached。
(5)返回 Access URL 给客户端,比如 http://192.168.1.20:6080/vnc_auto.html?token=8dc6f7cb-2e2d-4fbe-abab-3334fe3a19dc
在 Contoller 节点上运行着一个service “/usr/bin/python /usr/bin/nova-novncproxy --config-file=/etc/nova/nova.conf”。该 service 默认在 6080 端口(可由 CONF.novncproxy_port 配置)监听来自所有地址(可由 CONF.novncproxy_host 配置)的请求。
(6)在客户端浏览器上打开 Access URL,由 Controller 上的 nova-novncproxy 接收并处理
(7)nova-novncproxy 通过 RPC 调用 consoleauth.check_token() 方法,获取 console_type 和 port 等 connect info。期间还会到目的node上去校验这些信息。
{u'instance_uuid': u'7c53af66-765b-48f3-b8a2-a908feb63968', u'internal_access_path': None, u'last_activity_at': 1434670235.591856, u'console_type': u'novnc', u'host': u'192.168.1.15', u'token': u'10bffd07-e11c-48bb-880a-bc1a49c871d7', u'port': u''}
(8)连接到目的 node,握手,开始 proxying。
与 NOVNC 有关的配置参数:
节点 | 配置文件 | 参数 | 默认配置 | 说明 |
Controller | /etc/nova/nova.conf | novncproxy_port | 6080 | /usr/bin/nova-novncproxy 服务所在的节点(通常是 Controller 节点)上 该 service 所监听的端口。奇怪的是 nova 文档中没说明该配置参数。 |
novncproxy_host | 0.0.0.0 | nova-novncproxy service 所监听的请求来源地址。0.0.0.0 表示接收所有来源的请求。奇怪的是 nova 文档中没说明该配置参数。 | ||
nova-compute | /etc/nova/nova.conf | vncserver_proxyclient_address | 虚机所在的 nova compute 节点的 management 网卡的 IP 地址 | |
vncserver_listen | 127.0.0.1 | 虚机所在的 nova compute 节点的 vnc service 所监听的端口,需要修改默认配置为其 0.0.0.0 | ||
novncproxy_base_url |
http://127.0.0.1:6080/ |
nova 客户端通过 get_vncconsole 命令获取到的访问虚机的 VNC URL。需要修改其值为
http://<nova-novncproxy-node-management-interface-ip>:<nova-novncproxy-node-nova.conf.novncproxy_port>/vnc_auto.html 比如 http://192.168.1.20:6080/ |
||
vnc_enabled |
true |
使得虚机能够对外提供 VNC 服务 |
5. Evacuate (移机)
作用:当一个 node down 掉后,在新的 node 上根据其 DB 中保存的信息重新 build down node 上虚机。这个往往在虚机 HA 方案中用到。它尽可能地将原来的虚机在新的主机上恢复:
- 虚机的配置:从 DB 中获取,包括 image,block,network 等
- 虚机的数据:如果使用共享存储,则使用共享存储上的虚机数据;如果不使用共享存储,则无法恢复数据
- 内存状态:无法恢复
因此,HA 方案中,应该尽可能地将虚机的数据文件放在共享存储上,否则,恢复出来的虚机的价值非常有限。
Nova CLI:usage: nova evacuate [--password <password>] [--on-shared-storage] <server> [<host>]
要求:
(1)必须指定和虚机的 host 不同的 host,否则将报错“The target host can't be the same one”。
(2)虚机的host 必须处于不可用状态,否则将报错 “Compute service of compute2 is still in use.”
(3)可以指定新的 admin password,不指定的话,nova 将生成一个随机密码
(4)参数 on-shared-storage 表示虚机的 instance folder 是不是在共享存储上。
主要步骤:
(1)在做完以上各种参数检查后,调用 Conductor 的 方法:
return self.compute_task_api.rebuild_instance(context, instance=instance, new_pass=admin_password, injected_files=None, image_ref=None,
orig_image_ref=None, orig_sys_metadata=None, bdms=None, recreate=True, on_shared_storage=on_shared_storage, host=host)
如果 host 为none 的话,conductor 将调用 scheduler 的方法选择一个 host。
(2)接着调用 nova compute 的 rebuild_instance 方法。该方法从系统(DB)中获取已有的数据,然后根据这些已有的 metadata 重新构造domain。“A 'rebuild' effectively purges all existing data from the system and remakes the VM with given 'metadata' and 'personalities'.”
- 获取 image_ref,再获取 image meta
- 获取 network_info 并在新的 host 上构造网络
- 获取 BlockDeviceMappingList
- 获取 block_device_info
(3)然后调用 virt driver 的 rebuild 方法,但是 libvirt 没有实现该方法,转而调用 _rebuild_default_impl 方法。该方法:
- 从 volume 端断开其与原来 host 的连接
- 调用 driver.spawn 方法构造新的 domain,依次创建 image(如果 on_shared_storage = false 的话,则重新下载 image, 构造 instance folder;如果 on_shared_storage = true 的话,则直接使用共享存储上的 instance folder。这也可见使用共享存储的优势),network 和 domain,并设置 domain 的状态和之前一致。
(4)在坏了的 host 被重启后,nova-compute 服务调用 _destroy_evacuated_instances 方法来找到 evacuated instances 并将它们删除:
- 调用 libvirt 找到该 host 上所有 domains,然后在 nova db 中一一查找其状态,过滤出 “deleted” 为 false 的 domains
- 如果instance.host 不是本机,而且 instance.task_state 不是 { MIGRATING,RESIZE_MIGRATING,RESIZE_MIGRATED,RESIZE_FINISH} 之一,则删除该 domain,以及 network,block device 以及 instance folder。
总之,在使用共享存储的情况下,evacuate 出来的新的 domain 除了临时盘上的数据外,它和之前的 domain 的数据是一样的了,但是内存状态除外。