OpenStack虚拟机创建过程中镜像格式的的变化过程

Glance⽤来作为独⽴的⼤规模镜像查找服务，当它与Nova和Swift配合使⽤时，就为OpenStack提供了虚拟机镜像的查找服务，像所有的OpenStack项⽬⼀样，遵循以下设计思想：

基于组件的架构 – 便于快速增加新特性

⾼可⽤性 – ⽀持⼤负荷

容错性 – 独⽴的进程地址空间，避免串⾏错误

开放标准 – 对社区驱动的API提供参考实现

1. Glancle架构

Glance主要由三个部分构成：glance-api、glance-registry以及image store。

Glance-api接收REST API的请求，类似nova-api；

Glance-api在功能上与nova-api⼗分类似，都是接收REST API请求，然后通过其他模块（glance-registry及image store）来完成诸如镜像的查找、获取、上传、删除等操作，i默认监听端

⼝9292。

glance-registry⽤于与MySQL数据库交互，⽤于存储或获取镜像的元数据（metadata）；

Glance-registry⽤于提供镜像元数据相关的REST接⼝，通过glance-registry，可以向数据库中写⼊或获取镜像的各种数据，glance-registry监听端⼝9191。Glance的数据库中有两张表，

⼀张是image表，另⼀张是image property表。Image表保存了镜像格式、⼤⼩等信息；image property表则主要保存镜像的定制化信息。

image store是⼀个存储的接⼝层，通过这个接⼝，glance可以获取镜像，image store⽀持的存储有Amazon的S3、OpenStack本⾝的Swift，还有诸如ceph，sheepdog，GlusterFS等分布式存储。

Image store是镜像保存与获取的接⼝，它仅仅是⼀个接⼝层，具体的实现需要外部的存储⽀持，⽬前，⽀持的接⼝有Amazon S3、GlusterFS、Swift，sheepdog，ceph等。

Glance体系结构如下图所⽰，通过glance，OpenStack的三个模块计算组件（nova）、镜像管理组件（glance）、存储组件

（swift，ceph，sheepdog等）被连接成⼀个整体，Glance为Nova提供镜像的查找等操作，⽽存储组件⼜为Glance提供了实际的存储服务。⽽Swift，ceph，gluster，sheepdog等⼜是Glance存储接⼝的⼀些具体实现，Glance的存储接⼝还能⽀持S3等第三⽅的商业组件。

2. Openstack创建虚拟机的过程中镜像⽂件格式的变化过程

这⾥通过OpenStack的horizon组件来创建⼀个m1.small的virtual machine，来详细分析下镜像格式的变化以及glance底层具体执⾏的哪些操作。

（1）⾸先看⼀下Glance管理的镜像，如果采⽤local storage，glance将镜像⽂件默认存储到/var/lib/glance/image⽬录下，这⾥我们选择c036d689-0336-4fcd-a8e0-4aed4dd5e420这个镜像来作为创建虚拟机的模板，此镜像是通过如下命令添加的,因此在horizon中显⽰的名称为：Precise x86_64。

glance add name=”Precisex86_64″ is_public=true

container_format=ovf disk_format=qcow2

[root@controller ~]# ll -alh /var/lib/glance/images/ 查看当前所有镜像

total 2.5G

总用量 246G

drwxr-x—. 2 glance glance 4.0K 8月 9 15:41 .

drwxr-xr-x. 3 glance nobody 4.0K 12月 30 2020 ..

-rw-r—– 1 glance glance 22G 1月 22 2021 011f1795-96a7-49ed-a060-d0032be46ec3

-rw-r—– 1 glance glance 22G 3月 28 14:56 03e6ddec-9151-4e9f-acfb-4683296a54cb

通过qemu-img info命令，先看⼀下镜像⽂件的⼤⼩和格式如下(需要切换到目录底下查看)：

ubuntu@compute-63-02:/var/lib/glance/images$sudo qemu-img info c036d689-0336-4fcd-a8e0-4aed4dd5e420

image:c036d689-0336-4fcd-a8e0-4aed4dd5e420

file format: qcow2 //qcow2格式的镜像

virtual size: 2.0G (2147483648 bytes) //镜像⽂件⼤⼩的上限为2G，实际使⽤了223M

disk size: 223M

cluster_size: 65536

（2）通过horizon创建m1.small（具体配置为：1vcpu，2G memory，10G root disk，20G extra volume）的virtual machine 新创建的虚拟机存放在/var/lib/nova/instances⽬录下，该⽬录的⼤体结构如下：

ubuntu@compute-63-12:/var/lib/nova/instances$ll

total 32

drwxr-xr-x 8 nova nova 4096 Feb 28 21:39./

drwxr-xr-x 10 nova nova 4096 Dec 25 01:07../

drwxrwxr-x 2 nova nova 4096 Feb 28 21:39_base/ //相当于镜像⽂件的cache⽬录，在此host上创建的所有的vm，都会先cacha到这⾥

drwxrwxr-x 2 nova nova 4096 Jan 8 05:56instance-00000022/ //instance-xxxxx新创建的虚拟机

drwxrwxr-x 2 nova nova 4096 Feb 28 03:40instance-00000034/

drwxrwxr-x 2 nova nova 4096 Feb 28 04:02instance-00000037/

drwxrwxr-x 2 nova nova 4096 Feb 28 21:39instance-0000003a/

drwxrwxr-x 2 nova nova 4096 Jan 30 01:30snapshots/ //此host上虚拟机对应的快照⽂件

通过查看nova-compute.log可以看到vm创建过程中，镜像⽂件格式的变化过程，下⾯总结了下，具体参见下图。

从glance中得知，有个virtual size =2G的qcow2格式的镜像⽂件Precise x86_64，它在glance中的ID=c036d689-0336-4fcd-a8e0-4aed4dd5e420。当Nova Compute接收到vm创建的请求时，通过以下步骤完成⼀个VM的创建过程：

（1）步：

从vm的描述⽂件中获得所使⽤的image⽂件的ID，然后向Glance发起索取image⽂件的HTTP请求，结果是image⽂件从Glance的存储节点下载到发起请求的host机器上，即：/var/lib/nova/instances/_base⽬录下：

ubuntu@compute-63-11:/var/lib/nova/instances/_base$ll -alh

total 4.0G

drwxrwxr-x 2 nova nova 4.0K Feb 28 21:39./

drwxr-xr-x 8 nova nova 4.0K Feb 28 21:39../

-rw-r–r– 1 nova kvm 2.0G Mar 1 02:06d265f9d66b8be65448e6c9147a83d65a300e1852

-rw-r–r– 1 nova kvm 10G Mar 1 02:06d265f9d66b8be65448e6c9147a83d65a300e1852_10

-rw-rw-r– 1 nova nova 223M Feb 28 03:17d265f9d66b8be65448e6c9147a83d65a300e1852.part

-rw-r–r– 1 nova nova 20G Feb 28 04:01ephemeral_0_20_None

-rw-r–r– 1 libvirt-qemu kvm 20G Feb 2804:01 ephemeral_0_20_None_20

-rw-r–r– 1 nova nova 40G Feb 28 21:39ephemeral_0_40_None

-rw-r–r– 1 libvirt-qemu kvm 40G Feb 28 21:39ephemeral_0_40_None_40

即从：c036d689-0336-4fcd-a8e0-4aed4dd5e420 —>d265f9d66b8be65448e6c9147a83d65a300e1852.part

通过qemu-img info，可以发现d265f9d66b8be65448e6c9147a83d65a300e1852.part仍为qcow2格式的镜像，且⼤⼩与glance上的⼤⼩⼀致。

ubuntu@compute-63-11:/var/lib/nova/instances/_base$sudo qemu-img info d265f9d66b8be65448e6c9147a83d65a300e1852.part

image:d265f9d66b8be65448e6c9147a83d65a300e1852.part

file format: qcow2

virtual size: 2.0G (2147483648 bytes)

disk size: 223M

cluster_size: 65536

（2）步：

镜像下载成功后，openstack先去判断image⽂件的类型是否为qcow2，如果是，则现将其转化为raw格式，否则，直接进⼊

（3）这⾥通过qemu-img convert命令，将qcow2格式转化为raw格式，转化完的镜像为：d265f9d66b8be65448e6c9147a83d65a300e1852，通过qemu-imag info查看其information。

ubuntu@compute-63-11:/var/lib/nova/instances/_base$sudo qemu-img info d265f9d66b8be65448e6c9147a83d65a300e1852

image:d265f9d66b8be65448e6c9147a83d65a300e1852

file format: raw

virtual size: 2.0G (2147483648 bytes)

disk size: 659M

（4）两步：

由于所请求的vm的类型为m1.small，其root disk的⼤⼩为10G，所以需要resize image fille to 10G。

这⾥⽐较奇怪的是，在resize之前，openstack会将d265f9d66b8be65448e6c9147a83d65a300e1852拷贝⼀份

d265f9d66b8be65448e6c9147a83d65a300e1852_10，然后对d265f9d66b8be65448e6c9147a83d65a300e1852_10进⾏resize操作，将其变成

10G的raw，这可能与vm的备份有关，暂时还没有理解为什么这么做。cp

/var/lib/nova/instances/_base/d265f9d66b8be65448e6c9147a83d65a300e1852

/var/lib/nova/instances/_base/d265f9d66b8be65448e6c9147a83d65a300e1852_10（raw–>raw 2G–>2G）qemu-img resize

/var/lib/nova/instances/_base/d265f9d66b8be65448e6c9147a83d65a300e1852_1010737418240 （raw–> raw 2G –>10G）(5) 步：

以（3）中创建的d265f9d66b8be65448e6c9147a83d65a300e1852_10作为base创建qcow2格式的overlay，可以理解为

以d265f9d66b8be65448e6c9147a83d65a300e1852_10为base，创建了⼀个快照disk,具体看对应虚拟机⽬录下的⽂件：

ubuntu@compute-63-12:/var/lib/nova/instances/instance-0000003a$ll -alh

total 417M

drwxrwxr-x 2 nova nova 4.0K Feb 28 21:39./

drwxr-xr-x 8 nova nova 4.0K Feb 28 21:39../

-rw-rw—- 1 libvirt-qemu kvm 23K Feb 2821:40 console.log

-rw-r–r– 1 libvirt-qemu kvm 417M Mar 102:36 disk

-rw-r–r– 1 libvirt-qemu kvm 576K Mar 101:35 disk.local

-rw-rw-r– 1 nova nova 1.6K Feb 28 21:38libvirt.xml

现在来总结下镜像⽂件的变化过程：

c036d689-0336-4fcd-a8e0-4aed4dd5e420(223M — qcow2)

–>d265f9d66b8be65448e6c9147a83d65a300e1852.part(223M — qcow2)

–>d265f9d66b8be65448e6c9147a83d65a300e1852 (2G — raw)

–>d265f9d66b8be65448e6c9147a83d65a300e1852_10(10G — raw)

–> disk (417M — qcow2)

3. cache机制

如果之后创建的vm的类型也是m1.small，并且是同⼀个image,将不会再去glance下载image⽂件，⽽是直接利⽤本地_base下的d265f9d66b8be65448e6c9147a83d65a300e1852_10来直接创建vm的disk⽂件，⼤⼤减少的vm的部署时间。