虚拟机状态

本文主要参考（翻译）自 OpenStack 官方文档 VMState、Virtual Machine States and Transitions，以及简要说明一下其在 Nova 代码中的体现。

虚拟机状态

对于每个虚拟机而言，它都有 3 种状态，vm_state、task_state 以及 power_state。它们之间非常容易混淆。不过官方文档 VMState 简明扼要地区别了它们：

  • power_state 是虚拟机在 Hypervisor 上的状态，从计算节点从下而上（bottom-up）传递，如 RUNNING
  • vm_state 反应了基于 API 调用的一种稳定状态，如 ACTIVE
  • task_state 反应了 API 调用过程中的过渡状态，如 SCHEDULING

power_state

power_state 应该通过调用虚拟机的 virt 驱动来获得。Hypervisor 上虚拟机的状态是最权威的，而数据库中的 power_state 只是（最近）过去状态的一个快照。这个状态会周期性更新，而且应该在每一个会影响 power_state 的任务（task）结束时更新。

  • 如何更新
    从计算节点从下而上（bottom-up）传递，覆写数据库中相应的字段。这可能会触发跟 vm_state 的一致性协调，见下文 vm_state。

  • 命名规范
    取决于 Libvirt 返回的状态

  • 已废弃状态

    • BLOCKED：本质上是 RUNNING
    • SHUTOFF：对应到 SHUTDOWN
    • FAILED：对应到 NOSTATE
more >>

展开全文 >>

【译】 虚拟机生命周期

本文翻译自 Libvirt 官方文档 VM Lifecycle。

虚拟机生命周期

本文介绍虚拟机生命周期的基本要素，目的在于提供创建、运行、停止、迁移和删除虚拟机的基本信息。

术语

知道文档中使用的术语及命令和语法的意义一直很重要。如果你不熟悉 Libvirt 的基本概念，如节点（Node）、域（Domain），以及为了获取 Libvirt 项目目标、覆盖范围的概况，请参考这篇文章。

概念

**Guest Domain 用 XML 来描述 **

在 Libvirt 中，XML 文件被用来保存所有东西的配置信息，包括 Domain、网络、存储和其他元素。XML 使得用户可以使用舒适的编辑器及易于集成其他技术和工具。

例如，Domain 中的设备（Device）通过赋予 XML 元素或子元素属性来表示。一个 XML 片段如下：

1
2
3
4
5
6
7
8
9
10
11
<domain type='qemu'>
   <name>demo</name>
   ...
   <devices>
      ...
      <disk type='file' device='disk'> ... </disk>
      <disk type='file' device='cdrom'> ... </disk>
      <input type='mouse' bus='ps2'/>
      ...
   </devices>
</domain>

Libvirt 使用了 XPath 技术来选取 XML 文档中的节点（node）。

more >>

展开全文 >>

InnoDB 索引

本文如无特殊说明，所有内容均是针对 InnoDB 存储引擎而言。

首先，确保我们正在使用的 MySQL 引擎是 InnoDB（Support 行为 DEFAULT）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)

本文样例均在以下 MySQL 版本中测试通过：

1
2
# mysql -V
mysql  Ver 14.14 Distrib 5.6.22, for Linux (x86_64) using  EditLine wrapper
more >>

展开全文 >>

数据库版本管理

没有接触 OpenStack 之前，一直以为只有代码、Office 文档之类有版本管理，没想到数据库也有版本管理，真是大开眼界。

基于 SQLAlchemy 的数据库版本管理工具有 SQLAlchemy-Migrate 和 Alembic。前者在 OpenStack 中用得最多，目前由 OpenStack 官方维护。

本文主要摘录自 SQLAlchemy-Migrate 官方样例，以后如有需要再做进一步探讨。

1. 新建一个数据库版本管理仓库

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
$ pwd
/home/xiehongfeng100/Migrate
$ migrate create my_repository "Example project"
$ tree my_repository 
my_repository
├── __init__.py
├── __init__.pyc
├── manage.py
├── migrate.cfg
├── README
└── versions
    ├── __init__.py
    └── __init__.pyc

1 directory, 7 files
$ cat my_repository/migrate.cfg 
[db_settings]
# Used to identify which repository this database is versioned under.
# You can use the name of your project.
repository_id=Example project	# 我们指定的项目名称，只是我们这里并没有项目；如有项目，可写为项目名称

# The name of the database table used to track the schema version.
# This name shouldn't already be used by your project.
# If this is changed once a database is under version control, you'll need to
# change the table name in each database too.
version_table=migrate_version

# When committing a change script, Migrate will attempt to generate the
# sql for all supported databases; normally, if one of them fails - probably
# because you don't have that database installed - it is ignored and the
# commit continues, perhaps ending successfully.
# Databases in this list MUST compile successfully during a commit, or the
# entire commit will fail. List the databases your application will actually
# be using to ensure your updates to that database work properly.
# This must be a list; example: ['postgres','sqlite']
required_dbs=[]

# When creating new change scripts, Migrate will stamp the new script with
# a version number. By default this is latest_version + 1. You can set this
# to 'true' to tell Migrate to use the UTC timestamp instead.
use_timestamp_numbering=False
more >>

展开全文 >>

OpenStack 源码系列之 Keystone：API 路由

作为一个服务，Keystone 跟其他模块一样向外提供了 Rest API，以供其他 HTTP 客户端（如 Keystoneclient、POSTMan、Curl）调用。这些 Rest API 调用并不是直接调用底层的 API 来来实现，而是通过路由，转发到底层的 API 去执行并返回结果。只要理解了一个 Rest API 的路由过程，就可以以此类推知道其他 Rest API 是如何路由的。下文我们以用户创建（超级管理员权限）为例说明该过程。

1. 从 PasteDeploy 配置文件确定 API 入口

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# etc/keystone-paste.ini

[app:admin_service]
use = egg:keystone#admin_service

......

[pipeline:admin_api]
# The last item in this pipeline must be admin_service or an equivalent
# application. It cannot be a filter.
pipeline = ... admin_service

......

[composite:admin]
use = egg:Paste#urlmap
/v2.0 = admin_api
...

我们会发现超级管理员 API 的入口在 egg:keystone#admin_service。但这个入口并没有具体指向哪个函数，所以我们需要进一步确定该入口的具体指向。

2. 从 setup.cfg 确定具体服务入口

1
2
3
4
5
# setup.cfg

paste.app_factory =
    admin_service = keystone.version.service:admin_app_factory
    ...
more >>

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

谢宏峰，毕业于暨南大学（2009 - 2013）、中国科学院（2013 - 2016），现就职于深信服科技，从事 OpenStack 开发。