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

wxyfj

　　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="Precise x86_64" is_public=true
  
  
• container_format=ovf disk_format=qcow2
  
• 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
    
  （3）（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_10 10737418240 （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 28 21:40 console.log
    
  • -rw-r--r-- 1 libvirt-qemu kvm  417M Mar  1 02:36 disk
    
  • -rw-r--r-- 1 libvirt-qemu kvm  576K Mar  1 01:35 disk.local
    
  • -rw-rw-r-- 1 nova         nova 1.6K Feb 28 21:38 libvirt.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的部署时间。