(轉)如何閱讀OpenStack源碼

原文：https://github.com/int32bit/openstack-workflow

http://www.talkwithtrend.com/Article/240391

1 關於該項目

本項目使用在線繪圖工具web sequencediagrams完成，目標是圖形化OpenStack的所有操作流程，通過操作序列圖能快速學習Openstack的工作原理，理清各個組件的關系，運維人員也能根據操作序列圖進行更精確的故障定位和排查.

注意，該操作序列圖基於L版OpenStack源碼，未來版本的操作可能會有變化，請以最新版的源碼為准，該項目提供的序列圖僅供參考。

2 OpenStack基礎

2.1 OpenStack組件介紹

OpenStack是一個IaaS層的雲計算平台開源實現，其對標產品為AWS。最開始OpenStack只有兩個組件，分別為提供計算服務的Nova以及提供對象存儲服務的Swift，其中Nova不僅提供計算服務，還包含了網絡服務、塊存儲服務、鏡像服務以及裸機管理服務。之后隨着項目的不斷發展，從Nova中根據功能拆分為多個獨立的項目，如nova-volume拆分為Cinder項目提供塊存儲服務，nova-image拆分為Glance項目，提供鏡像存儲服務，nova-network則是neutron的前身，裸機管理也從Nova中分離出來為Ironic項目。最開始容器服務也是由Nova提供支持的，作為Nova的driver之一來實現，而后遷移到Heat，到現在已經獨立為一個單獨的項目Magnum，后來Magnum的願景調整為主要提供容器編排服務，單純的容器服務則由Zun項目接管。最開始OpenStack並沒有認證功能，從E版開始才加入認證服務Keystone。

目前OpenStack核心組件如下:

• Keystone：認證服務。
• Glance：鏡像服務。
• Nova：計算服務。
• Cinder：塊存儲服務。
• Neutorn：網絡服務。
• Swift：對象存儲服務。

E版之后，在這些核心服務之上，又不斷涌現新的服務，如面板服務Horizon、編排服務Heat、數據庫服務Trove、文件共享服務Manila、大數據服務Sahara以及前面提到的Magnum等，這些服務幾乎都依賴於以上的核心服務。比如Sahara大數據服務會先調用Heat模板服務，Heat又會調用Nova創建虛擬機，調用Glance獲取鏡像，調用Cinder創建數據卷，調用Neutron創建網絡等。

截至現在（2016年11月27日），OpenStack已經走過了6年半的歲月，最新發布的版本為第14個版本，代號為Newton，Ocata版已經處在快速開發中。

OpenStack服務越來越多、越來越復雜，覆蓋的技術生態越來越龐大，宛如一個龐然大物，剛接觸如此龐大的分布式系統，都或多或少感覺有點如"盲人摸象"的感覺。不過不必先過於絕望，好在OpenStack項目具有非常良好的設計，雖然OpenStack項目眾多，組件繁雜，但幾乎所有的服務骨架脈絡基本是一樣的，熟悉了其中一個項目的架構，深入讀了其中一個項目源碼，再去看其它項目可謂輕車熟路。

本文檔會以Nova項目為例，一步一步剖析源碼結構，閱讀完之后，你再去看Cinder項目，發現非常輕松。

2.2 工欲善其事必先利其器

要閱讀源代碼首先需要安裝科學的代碼閱讀工具，圖形界面使用pycharm沒有問題，不過通常在虛擬機中是沒有圖形界面的，首選vim，需要簡單的配置使其支持代碼跳轉和代碼搜索，可以參考GitHub - int32bit/dotfiles: A set of vim, zsh, git, and tmux configuration files.。如圖：

OpenStack所有項目都是基於Python開發，都是標准的Python項目，通過setuptools工具管理項目，負責Python包的安裝和分發。想知道一個項目有哪些服務組成，入口函數（main函數）在哪里，最直接的方式就是查看項目根目錄下的setup.cfg文件，其中console_scripts就是所有服務組件的入口，比如nova的setup.cfg的console_scripts如下:

[entry_points]
...
console_scripts =
    nova-all = nova.cmd.all:main
    nova-api = nova.cmd.api:main
    nova-api-metadata = nova.cmd.api_metadata:main
    nova-api-os-compute = nova.cmd.api_os_compute:main
    nova-cells = nova.cmd.cells:main
    nova-cert = nova.cmd.cert:main
    nova-compute = nova.cmd.compute:main
    nova-conductor = nova.cmd.conductor:main
    nova-console = nova.cmd.console:main
    nova-consoleauth = nova.cmd.consoleauth:main
    nova-dhcpbridge = nova.cmd.dhcpbridge:main
    nova-idmapshift = nova.cmd.idmapshift:main
    nova-manage = nova.cmd.manage:main
    nova-network = nova.cmd.network:main
    nova-novncproxy = nova.cmd.novncproxy:main
    nova-rootwrap = oslo_rootwrap.cmd:main
    nova-rootwrap-daemon = oslo_rootwrap.cmd:daemon
    nova-scheduler = nova.cmd.scheduler:main
    nova-serialproxy = nova.cmd.serialproxy:main
    nova-spicehtml5proxy = nova.cmd.spicehtml5proxy:main
    nova-xvpvncproxy = nova.cmd.xvpvncproxy:main
...

由此可知nova項目安裝后會包含21個可執行程序，其中nova-compute服務的入口函數為nova/cmd/compute.py(. -> /)模塊的main函數:

def main(): config.parse_args(sys.argv) logging.setup(CONF, 'nova') utils.monkey_patch() objects.register_all() gmr.TextGuruMeditation.setup_autorun(version) if not CONF.conductor.use_local: block_db_access() objects_base.NovaObject.indirection_api = \ conductor_rpcapi.ConductorAPI() else: LOG.warning(_LW('Conductor local mode is deprecated and will ' 'be removed in a subsequent release')) server = service.Service.create(binary='nova-compute', 由於OpenStack使用python語言開發，而python是動態類型語言，參數類型不容易從代碼中看出，因此必須部署一個allinone的OpenStack開發測試環境，建議使用RDO部署：[Packstack quickstart](https://www.rdoproject.org/install/quickstart/)，當然樂於折騰使用Devstack也是沒有問題的。 要想深入研究源碼，最有效的方式就是一步一步跟蹤代碼執行，因此會使用debug工具是關鍵技能之一。python的debug工具有很多，為了簡便起見，pdb工具就夠了。使用方法也非常簡單，只要在你想設置斷點的地方，嵌入以下代碼： 

import pdb; pdb.set_trace()

然后在命令行（不能通過systemd執行）直接運行服務即可。假如想跟蹤nova創建虛擬機的過程，首先在`nova/api/openstack/compute/servers.py`模塊的`create`方法打上斷點，如下：

```python
@wsgi.response(202)
    @extensions.expected_errors((400, 403, 409, 413))
    @validation.schema(schema_server_create_v20, '2.0', '2.0')
    @validation.schema(schema_server_create, '2.1', '2.18')
    @validation.schema(schema_server_create_v219, '2.19')
    def create(self, req, body):
        """Creates a new server for a given user."""

        import pdb; pdb.set_trace() # 設置斷點
        context = req.environ['nova.context']
        server_dict = body['server']
        password = self._get_server_admin_password(server_dict)
        name = common.normalize_name(server_dict['name'])

        if api_version_request.is_supported(req, min_version='2.19'):
            if 'description' in server_dict:
                # This is allowed to be None
                description = server_dict['description']
            else:
                # No default description
                description = None
        else:
            description = name
        ...

然后注意需要通過命令行直接運行，而不是通過systemd啟動:

su -c 'nova-api' nova

此時調用創建虛擬機API，nova-api進程就會馬上彈出pdb shell，此時你可以通過s或者n命令一步一步執行了。

2.3 OpenStack項目通用骨骼脈絡

閱讀源碼的首要問題就是就要對代碼的結構了然於胸，需要強調的是，OpenStack項目的目錄結構並不是根據組件嚴格划分，而是根據功能划分，以Nova為例，compute目錄並不是一定在nova-compute節點上運行，而主要是和compute相關(虛擬機操作相關）的功能實現，同樣的，scheduler目錄代碼並不全在scheduler服務節點運行，但主要是和調度相關的代碼。不過目錄結構並不是完全沒有規律，它遵循一定的套路。

通常一個服務的目錄都會包含api.py、rpcapi.py、manager.py，這個三個是最重要的模塊。

• api.py： 通常是供其它組件調用的封裝庫。換句話說，該模塊通常並不會由本模塊調用。比如compute目錄的api.py，通常由nova-api服務的controller調用。
• rpcapi.py：這個是RPC請求的封裝，或者說是RPC封裝的client端，該模塊封裝了RPC請求調用。
• manager.py： 這個才是真正服務的功能實現，也是RPC的服務端，即處理RPC請求的入口，實現的方法通常和rpcapi實現的方法一一對應。

比如對一個虛擬機執行關機操作：

API節點
nova-api接收用戶請求 -> nova-api調用compute/api.py -> compute/api調用compute/rpcapi.py -> rpcapi.py向目標計算節點發起stop_instance()RPC請求

計算節點
收到stop_instance()請求 -> 調用compute/manager.py的callback方法stop_instance() -> 調用libvirt關機虛擬機

前面提到OpenStack項目的目錄結構是按照功能划分的，而不是服務組件，因此並不是所有的目錄都能有對應的組件。仍以Nova為例:

• cmd：這是服務的啟動腳本，即所有服務的main函數。看服務怎么初始化，就從這里開始。
• db: 封裝數據庫訪問，目前支持的driver為sqlalchemy。
• conf：Nova的配置項聲明都在這里。
• locale: 本地化處理。
• image: 封裝Glance調用接口。
• network: 封裝網絡服務接口，根據配置不同，可能調用nova-network或者neutron。
• volume: 封裝數據卷訪問接口，通常是Cinder的client封裝。
• virt: 這是所有支持的hypervisor驅動，主流的如libvirt、xen等。
• objects: 對象模型，封裝了所有實體對象的CURD操作，相對以前直接調用db的model更安全，並且支持版本控制。
• policies： policy校驗實現。
• tests: 單元測試和功能測試代碼。

以上同樣適用於其它服務，比如Cinder等。

另外需要了解的是，所有的API入口都是從xxx-api開始的，RESTFul API是OpenStack服務的唯一入口，也就是說，閱讀源碼就從api開始。而api組件也是根據實體划分的，不同的實體對應不同的controller，比如servers、flavors、keypairs等，controller的index方法對應list操作、show方法對應get操作、create創建、delete刪除、update更新等。

根據進程閱讀源碼並不是什么好的實踐，因為光理解服務如何初始化、如何通信、如何發送心跳等就不容易，各種高級封裝太復雜了。我認為比較好的閱讀源碼方式是追蹤一個任務的執行過程，比如看啟動虛擬機的整個流程，因此接下來本文將以創建一台虛擬機為例，一步步分析其過程。

3 創建虛擬機過程分析

這里以創建虛擬機過程為例，根據前面的總體套路，一步步跟蹤其執行過程。需要注意的是，Nova支持同時創建多台虛擬機，因此在調度時需要選擇多個宿主機。

S1 nova-api

入口為nova/api/openstack/compute/servers.py的create方法，該方法檢查了一堆參數以及policy后，調用compute_api的create方法。

def create(self, req, body): """Creates a new server for a given user.""" context = req.environ['nova.context'] server_dict = body['server'] password = self._get_server_admin_password(server_dict) name = common.normalize_name(server_dict['name']) ... flavor_id = self._flavor_id_from_req_data(body) try: inst_type = flavors.get_flavor_by_flavor_id( flavor_id, ctxt=context, read_deleted="no") (instances, resv_id) = self.compute_api.create(context, inst_type, image_uuid, display_name=name, display_description=description, availability_zone=availability_zone, forced_host=host, forced_node=node, metadata=server_dict.get('metadata', {}), admin_password=password, requested_networks=requested_networks, check_server_group_quota=True, **create_kwargs) except (exception.QuotaError, exception.PortLimitExceeded) as error: raise exc.HTTPForbidden( explanation=error.format_message())

這里的compute_api即前面說的nova/compute/api.py模塊，找到該模塊的create方法，該方法會創建數據庫記錄、檢查參數等，然后調用compute_task_api的build_instances方法:

self.compute_task_api.schedule_and_build_instances(
    context,
    build_requests=build_requests, request_spec=request_specs, image=boot_meta, admin_password=admin_password, injected_files=injected_files, requested_networks=requested_networks, block_device_mapping=block_device_mapping)

compute_task_api即conductor的api.py。conductor的api並沒有執行什么操作，直接調用了conductor_compute_rpcapi的build_instances方法:

def schedule_and_build_instances(self, context, build_requests, request_spec, image, admin_password, injected_files, requested_networks, block_device_mapping): self.conductor_compute_rpcapi.schedule_and_build_instances( context, build_requests, request_spec, image, admin_password, injected_files, requested_networks, block_device_mapping) 

該方法即時conductor RPC調用api，即nova/conductor/rpcapi.py模塊，該方法除了一堆的版本檢查，剩下的就是對RPC調用的封裝，代碼只有兩行:

cctxt = self.client.prepare(version=version)
cctxt.cast(context, 'build_instances', **kw)

其中cast表示異步調用，build_instances是遠程調用的方法，kw是傳遞的參數。參數是字典類型，沒有復雜對象結構，因此不需要特別的序列化操作。

截至到現在，雖然目錄由api->compute->conductor，但仍在nova-api進程中運行，直到cast方法執行，該方法由於是異步調用，因此nova-api任務完成，此時會響應用戶請求，虛擬機狀態為building。

S2 nova-conductor

由於是向nova-conductor發起的RPC調用，而前面說了接收端肯定是manager.py，因此進程跳到nova-conductor服務，入口為nova/conductor/manager.py的build_instances方法，該方法首先調用了_schedule_instances方法，該方法調用了scheduler_client的select_destinations方法:

def _schedule_instances(self, context, request_spec, filter_properties): scheduler_utils.setup_instance_group(context, request_spec, filter_properties) # TODO(sbauza): Hydrate here the object until we modify the # scheduler.utils methods to directly use the RequestSpec object spec_obj = objects.RequestSpec.from_primitives( context, request_spec, filter_properties) hosts = self.scheduler_client.select_destinations(context, spec_obj) return hosts

scheduler_client和compute_api以及compute_task_api都是一樣對服務的client調用，不過scheduler沒有api.py，而是有個單獨的client目錄，實現在client目錄的__init__.py，這里僅僅是調用query.py下的SchedulerQueryClient的select_destinations實現，然后又很直接的調用了scheduler_rpcapi的select_destinations方法，終於又到了RPC調用環節。

def select_destinations(self, context, spec_obj): """Returns destinations(s) best suited for this request_spec and  filter_properties.   The result should be a list of dicts with 'host', 'nodename' and  'limits' as keys.  """ return self.scheduler_rpcapi.select_destinations(context, spec_obj)

毫無疑問，RPC封裝同樣是在scheduler的rpcapi中實現。該方法RPC調用代碼如下:

return cctxt.call(ctxt, 'select_destinations', **msg_args)

注意這里調用的call方法，即同步RPC調用，此時nova-conductor並不會退出，而是堵塞等待直到nova-scheduler返回。因此當前狀態為nova-conductor為blocked狀態，等待nova-scheduler返回，nova-scheduler接管任務。

S3 nova-scheduler

同理找到scheduler的manager.py模塊的select_destinations方法，該方法會調用driver方法，這里的driver其實就是調度算法實現，通常用的比較多的就是filter_scheduler的，對應filter_scheduler.py模塊，該模塊首先通過host_manager拿到所有的計算節點信息，然后通過filters過濾掉不滿足條件的計算節點，剩下的節點通過weigh方法計算權值，最后選擇權值高的作為候選計算節點返回。最后nova-scheduler返回調度結果的hosts集合，任務結束，返回到nova-conductor服務。

S4 nova-condutor

回到scheduler/manager.py的build_instances方法，nova-conductor等待nova-scheduler返回后，拿到調度的計算節點列表。因為可能同時啟動多個虛擬機，因此循環調用了compute_rpcapi的build_and_run_instance方法。

for (instance, host) in six.moves.zip(instances, hosts): instance.availability_zone = ( availability_zones.get_host_availability_zone(context, host['host'])) try: # NOTE(danms): This saves the az change above, refreshes our # instance, and tells us if it has been deleted underneath us instance.save() except (exception.InstanceNotFound, exception.InstanceInfoCacheNotFound): LOG.debug('Instance deleted during build', instance=instance) continue ... self.compute_rpcapi.build_and_run_instance(context, instance=instance, host=host['host'], image=image, request_spec=request_spec, filter_properties=local_filter_props, admin_password=admin_password, injected_files=injected_files, requested_networks=requested_networks, security_groups=security_groups, block_device_mapping=bdms, node=host['nodename'], limits=host['limits'])

看到xxxrpc立即想到對應的代碼位置，位於compute/rpcapi模塊，該方法向nova-compute發起RPC請求:

cctxt.cast(ctxt, 'build_and_run_instance', ...)

由於是cast調用，因此發起的是異步RPC，因此nova-conductor任務結束，緊接着終於輪到nova-compute登場了。

S5 nova-compute

到了nova-compute服務，入口為compute/manager.py，找到build_and_run_instance方法，該方法調用了driver的spawn方法，這里的driver就是各種hypervisor的實現，所有實現的driver都在virt目錄下，入口為driver.py，比如libvirt driver實現對應為virt/libvirt/driver.py，找到spawn方法，該方法拉取鏡像創建根磁盤、生成xml文件、define domain，啟動domain等。最后虛擬機完成創建。nova-compute服務結束。

以上是創建虛擬機的各個服務的交互過程以及調用關系，需要注意的是，所有的數據庫操作，比如instance.save（）以及update操作，如果配置use_local為false，則會向nova-conductor發起RPC調用，由nova-conductor代理完成數據庫更新，而不是由nova-compute直接訪問數據庫，這里的RPC調用過程在以上的分析中省略了。

4 操作序列圖

4.1 虛擬機操作列表

•  boot
•  start
•  stop
•  reboot
•  rebuild
•  resize
•  list
•  delete
•  reset-state
•  create-image(快照)
•  set-password
•  evacuate(疏散遷移)
•  pause
•  unpause
•  suspend
•  resume
•  reset-network
•  migrate(冷遷移)
•  live-migrate(在線遷移)
•  Shelve
•  Shelve-offload
•  Unshelve
•  lock
•  unlock
•  backup
•  Refresh Network
•  rename/update
•  rescue
•  unrescue
•  volume-attach
•  volume-detach
•  interface-attach
•  interface-detach

4.2 Todo列表

•  Cinder

•  Neutron

•  Sahara

  • •  create(創建集群)

•  Magnum
•  ...

5 如何開始工作

5.1 編譯圖形

生成最新圖片需要連接外網並且依賴於Make工具，請確保所依賴的包已經安裝。

直接執行make即可掃描所有的源碼並自動生成操作序列圖.

make

生成的圖片默認會保存在./output路徑下.

5.2 刪除圖片

執行以下命令可清理所有的圖片:

make clean

6.3 操作流程案例分析

注意:

• 圖中藍色線表示當前進程是active的，因此可以很容易看出是RPC同步調用還是異步調用的。
• Nova conductor配置use_local為false，訪問數據庫需要通過RPC調用conductor，但圖中為了方便表示數據庫操作，省略了RPC調用conductor訪問數據庫的過程。Nova已經使用objects模型封裝了數據庫操作，代碼位於nova/objects目錄。

1. 創建虛擬機

從操作序列圖看，虛擬機的創建主要分為三步：第一步是nova api對用戶創建虛擬機的參數進行檢查，如果參數沒有問題，nova api會在數據庫中創建相應的表項用來記錄用戶的請求，然后給nova-conductor發起一個異步RPC調用，conductor會對調度時的filters spect進行初始化，並向nova-scheduler發起RPC同步調用，nova-scheduler收到nova conductor發來的請求之后篩選能夠滿足虛擬機資源需求的hypervisor，並按照一定的策略選取其中的一台hypervisor，返回給nova-conductor，conductor然后給候選的計算節點nova compute發起一個run_instance的RPC調用。 Nova compute收到run_instance的請求之后，會為虛擬機的運行分配各種資源，如：ip地址、磁盤、網絡等。分配完各種資源之后，nova會調用libvirt創建根磁盤、xml文件等,並啟動虛擬機。到此，虛擬機的創建基本上就結束了，等虛擬機啟動完成，用戶就可以登錄和控制虛擬機了。

2. 重啟虛擬機

Nova中reboot操作可以分成兩種：soft reboot和hard reboot。Soft reboot通過發送acpid或者guest agent信號給虛擬機,虛擬機接收到信號號主動執行重啟操作。虛擬機必須支持appid或者運行qemu guest agent才能執行soft reboot。若soft reboot失敗或者超時(默認120秒)，則會進入hard reboot。hard reboot將執行強制重啟（相當於強制切電源），虛擬機重啟的序列圖如下：

從上圖可以看出，soft reboot和hard reboot最主要的差別是libvirt所執行的操作不同，soft reboot關機時執行shutdown操作，而hard reboot執行destroy操作，可能導致正在運行的虛擬機異常關機導致數據丟失。

3. 修改管理員密碼

從上圖中看出，修改管理員密碼是通過libvirt調用qemu guest agent執行的，因此虛擬機必須安裝了qemu-guest-agent服務並且處於運行狀態。

注意L版修改管理員密碼只支持使用kvm/qemu hypervisor。

4. 在線遷移

Live migrate是在不停止虛擬機的情況下，將虛擬機從一台宿主機上遷移到另外一台宿主機。在線遷移操作序列圖如下：

在線遷移相對復雜，不過從圖中看還是比較清晰的。如果不使用共享存儲，傳輸虛擬機磁盤會花很長一段時間，導致虛擬機遷移很慢，因此建議使用統一共享分布式存儲做OpenStack存儲后端。 在線遷移會不斷的增量同步內存狀態信息，直到收斂到很小的變化時，虛擬機會freeze一段時間，即處於downtime狀態，完成最后的狀態同步。遷移完成后，原來的虛擬機會自動刪除。

更多的操作序列圖

所有的圖形均使用工具生成，並且是可編程的。你只需要閱讀源代碼並使用Websequence Diagrams Tool語法編寫代碼，語法請參考官方文檔。以pause操作為例，對應源碼為:

title pause a server

participant client
participant nova_api

client->nova_api: pause
activate client
activate nova_api

# nova/api/openstack/compute/pause_server.py _pause()
note over nova_api: authrize context
nova_api->database: get instance by uuid
database->nova_api: done

# nova/compute/api.py pause()
note over nova_api: check policy
note over nova_api: check instance lock
note over nova_api: check instance cell
note over nova_api: ensure instance state is ACTIVE
nova_api->database: task_state = PAUSING
database->nova_api: done

note over nova_api: record pause action
# nova/compute/rpcapi.py pause_instance()
nova_api->nova_compute: pause_instance
deactivate nova_api
deactivate client
activate nova_compute

# nova/compute/manager.py pause_instance()
note over nova_compute: notify: pause.start
nova_compute->libvirt: pause
activate libvirt

# nova/virt/libvirt/driver.py pause()
note over libvirt: get domain
note over libvirt: domain.suspend()
libvirt->nova_compute: done
deactivate libvirt
# nova/compute/manager.py pause_instance()
nova_compute->database: vm_state = vm_states.PAUSED\ntask_state = None
database->nova_compute: done
note over nova_compute: notify: pause.end
deactivate nova_compute

新增了源碼后，只需要重新執行make命令即可生成新的圖片。

6 貢獻列表

以下這些開發者參與了該項目:

• AndiaQ: 喜愛研究OpenStack的萌妹紙，她的博客: https://andiaq.github.io。
• int32bit: 從2013年開始折騰OpenStack H版本，研究生期間曾在英特爾實習研究nova、ironic項目, 畢業后在UnitedStack負責cinder、nova開發和運維，現供職於雲極星創，主要研究nova和容器相關技術。nova、cinder以及oslo的代碼貢獻者。
• ljjjustin: OpenStack專家, 更多資料查看他的博客

7 虛擬機操作列表

• boot: 創建虛擬機。
• delete: 刪除虛擬機。
• force-delete: 無視虛擬機當前狀態，強制刪除虛擬機。即使開啟了軟刪除功能，該操作也會立即清理虛擬機資源。
• list: 顯示虛擬機列表。
• show: 查看指定虛擬機的詳細信息。
• stop: 關機虛擬機。
• start: 開機虛擬機。
• reboot: 重啟虛擬機。默認先嘗試軟重啟，當軟重啟嘗試120后失敗，將執行強制重啟。
• migrate: 冷遷移虛擬機，遷移過程中虛擬機將關機。
• live-migrate: 在線遷移虛擬機，虛擬機不會關機。
• resize: 修改虛擬機配置，即使用新的flavor重建虛擬機。
• rebuild: 重建虛擬機，指定新的image，如果指定快照，則相當於虛擬機狀態回滾。
• evacuate: 疏散遷移，只有當compute服務down時執行，能夠遷移虛擬機到其它正常計算節點中。
• reset-state: 手動重置虛擬機狀態為error或者active。
• create-image: 創建虛擬機快照。
• backup: 定期創建虛擬機快照。
• volume-attach: 掛載volume卷。
• volume-detach: 卸載volume卷。
• lock/unlock: 鎖定虛擬機，鎖定后的虛擬機普通用戶不能執行刪除、關機等操作。
• set-password: 修改管理員密碼，虛擬機需要運行qemu guest agent服務。
• pause/unpause: 暫停運行的虛擬機，如果底層的虛擬化使用的是libvirt，那么libvirt會在將虛擬機的信息保存到內存中，KVM/QEMU進程仍然在運行，只是暫停執行虛擬機的指令。
• suspend/resume: 掛起虛擬機，將虛擬機內存中的信息保存到磁盤上，虛擬機對於的KVM/QEMU進程會終止掉，該操作對應於libvirt中的save操作。resume從掛起的虛擬機恢復。
• reset-network: 重置虛擬機網絡，在使用libvirt時，該操作不執行任何實際的動作，因此功能尚未實現。
• shelve/unshelve: 虛擬機關機后仍占用資源，如果虛擬機長期不使用，可以執行shelve操作，該操作先創建虛擬機快照，然后刪除虛擬機，恢復時從快照中重建虛擬機。
• rename: 重命名虛擬機, 后期版本將被update操作替代。
• update: 修改虛擬機名稱、description信息等。
• rescue/unrescue: 虛擬機進入拯救模式。原理是創建一台新的虛擬機，並把需要rescue的虛擬機的根磁盤作為第二塊硬盤掛載到新創建的虛擬機。當原虛擬機根磁盤破壞不能啟動時該操作非常有用。
• interface-attach/interface-dettach: 綁定/解綁網卡。
• trigger-crash-dump: 使虛擬機觸發crash dump錯誤，測試使用。
• resize-confirm: 確認resize操作，此時原來的虛擬機將被刪除, 可以配置為自動確認。
• resize-revert: 撤銷resize操作，新創建的虛擬機刪除，並使用原來的虛擬機。
• console-log: 查看虛擬機日志。
• get-vnc-console: 獲取虛擬機vnc地址, 通常使用novnc協議。
• restore: 恢復虛擬機。如果配置了軟刪除功能，當虛擬機被刪除時，不會立即刪除，而僅僅標識下，此時能夠使用restore操作恢復刪除的虛擬機。
• instance-action-list: 查看虛擬機的操作日志。
• instance-action：查看某個虛擬機操作的詳細信息，如操作用戶、操作時間等。

8 協議

MIT

9 如何貢獻

歡迎有興趣的讀者補充更多的操作序列圖或者參與討論。

• 如果你有任何問題，請直接創建issure。
• 如果你要貢獻代碼，請直接PR。

10 更多項目

• dotfiles: vim、tmux、zsh、iterm配置，閱讀OpenStack源碼必備，vim支持標簽列表、函數跳轉、代碼搜索、智能補全功能。
• openstack-cheat-sheet: 匯集所有OpenStack相關的資料。
• int32bit's blog: int32bit的博客，主要專注於OpenStack、Docker、Ceph相關。

--by int32bit(OpenStack Contributor).