增量虚拟机的制作

我一直都很奇怪，在Openstack上，创建虚拟机的速度非常快，1分钟就搞定。虚拟化，其实最头疼的不是虚拟机运行的时候，而是创建的时候和重启的时候，是最消耗资源的。如何减少创建时候消耗资源呢? 我以前想过很多笨的所谓办法。不过现在看来，都是比较白痴。现在发现不但KVM支持，Xen也是支持这种方式，看来我真的是孤陋寡闻。http://hi.baidu.com/%B0%B5%D4%

q123456789098

1084人浏览 · 2012-08-03 08:58:36

q123456789098 · 2012-08-03 08:58:36 发布

我一直都很奇怪，在Openstack上，创建虚拟机的速度非常快，1分钟就搞定。

虚拟化，其实最头疼的不是虚拟机运行的时候，而是创建的时候和重启的时候，是最消耗资源的。

如何减少创建时候消耗资源呢? 我以前想过很多笨的所谓办法。

不过现在看来，都是比较白痴。

现在发现不但KVM支持，Xen也是支持这种方式，看来我真的是孤陋寡闻。

http://hi.baidu.com/%B0%B5%D4%C2%C1%F7%B9%E2/blog/item/8a0992b5589d2d668bd4b29e.html

http://www.cnblogs.com/chinacloud/archive/2010/08/17/1801638.html

在服务器上，经常需要启动数十个甚至上百个虚拟机，按照我们现有的方式可以安装一个虚拟机，然后复制相应的份数。在全虚拟化情况下，每个虚拟机至少需要4G以上空间，为了支持里面的应用，一般要分配10G左右，这样10个虚拟机就需要100G空间。事实上在目前为止里面还没有执行任何程序，这些空间都是分配，实际并不一定都要使用。是否能够实现用多少分配多少呢？分析下可以发现，每个虚拟机里面的内核都是一样的，大部分时候我们都不需要去修改里面的内核，是否能够共用内核？ Copy-On-Write模式为我们提供了很好的解决方式，通过创建一个基础镜像（base image），里面把各个虚拟机都需要的环境都搭建好，然后基于这个镜像建立起一个个增量镜像，每个增量镜像对应一个虚拟机，虚拟机对镜像中所有的改变都记录在增量镜像里面，基础镜像始终保持不变。这样我们建立10个虚拟机，需要的空间为：10G+10*52K(增量镜像的起始大小可能偏差)=10G，一下节省了近90G的空间。

1、资源准备

基础镜像文件（制作方式参考HVM Guest安装手册）：

vmdisk.img

2、制作虚拟机的增量镜像

制作一个容量为30G的虚拟硬盘：

# qemu-img-xen create –b vmdisk –f qcow2 vm1disk-qcow2.img 30000M //此处也可以用qcow-create

# ll –h

-rw-r--r-- 1 root root 52K Mar 11 19:42 vm1disk-qcow2.img

3、制作增量虚拟机配置文件

拷贝基础镜像配置文件

# cp windows.hvm vm1-windows.hvm

修改配置文件

disk = [ 'tap:qcow2:/home/wq/img/centos_pv/vmdisk-qcow.img,ioemu:hda,w' ]

4、启动增量虚拟机

# xm cr vm1-windows.hvm

可以拷贝一个50M以上的文件到虚拟机中，可以看到增量虚拟机镜像文件大小会动态改变。

下面是关于这个的讨论

http://www.linuxsir.org/bbs/thread368695.html

曾经有过一段时间，徘徊于对虚拟机硬盘格式的迷惑中，2009年，终于得出了一些结论（下面的思路基本通用于其他虚拟机）

搜了下，发现大部分用qemu或者kvm的，都默认使用qcow2来作为虚拟硬盘，但qemu官方默认是用raw。
下面是qemu wiki对两种格式的描述：
raw
Raw disk image format (default). This format has the advantage of being simple and easily exportable to all other emulators. If your file system supports holes (for example in ext2 or ext3 on Linux or NTFS on Windows), then only the written sectors will reserve space. Use qemu-img info to know the real size used by the image or ls -ls on Unix/Linux.

qcow2
QEMU image format, the most versatile format. Use it to have smaller images (useful if your filesystem does not supports holes, for example on Windows), optional AES encryption, zlib based compression and support of multiple VM snapshots.

raw的优势（能找到的相关资料太少，不知道是不是理解有误）：
1、简单，并能够导出为其他虚拟机的虚拟硬盘格式
2、根据实际使用量来占用空间使用量，而非原先设定的最大值（比如设定最高20G，而实际只使用3G）。——需要宿主分区支持hole（比如ext2 ext3 ntfs等）
3、以后能够改变空间最大值（把最高值20G提高到200G，qcow2也可以，不过要转为raw）
4、能够直接被宿主机挂载，不用开虚拟机即可在宿主和虚拟机间进行数据传输（注意，此时虚拟机不要开）

而qcow2的优势：
1、更小的虚拟硬盘空间（尤其是宿主分区不支持hole的情况下）
2、optional AES encryption, zlib based compression and support of multiple VM snapshots.

另外，根据fedora12的wiki，说测试结果是raw比qcow2性能更好，即使是新版的qcow2。 http://fedoraproject.org/wiki/Featur...w2_Performance

如果单纯靠这些信息，那么raw好像更有优势，而且更方便。（raw支持快照否？？？）

那么，为什么大家都默认使用qcow2呢？为什么？

同样的，还有vmdk vdi等虚拟机硬盘格式的优劣表现在哪方面呢？

又看到一个资料，说raw 格式是一种”直读直写”的格式,不具备特殊的特性。也就是说，qcow2具备的这两个AES encryption, zlib based compression，raw就没有。

kqemu是qemu的内核加速模块，不是kvm。wiki里qemu部分有写，和kvm是分为两部分的，是两种不同的内核加速模块。

qemu跑98、me、xp是很慢的，但跑win95，win2000，是飞速的，尤其是win2000（nnd，win2000好像在普通电脑里相比那几个好像是最慢的）。98、me要快，可以用定制版的windows，好像叫lite的。

但今天再回过头来看，发现其实raw更好：
raw相比qcow2就缺乏的四个功能，但都能通过别的方式解决：
1、加密功能：把raw本身就当普通文件加密之搞定
2、快照功能：把raw加入版本管理目录中，具体需要的设置可能稍微有点多。
3、宿主机不支持按需打孔模式（hole）：这个可以自己根据使用情况来扩展raw的最大值
4、硬盘压缩：就当普通电脑文件压缩之即可

而raw有qcow2所无法媲美的功能：
1、效率高于qcow2
2、直接读写虚拟机硬盘里面的文件，这比较“暴力”，但既然可以这么暴力，那么也就不怕虚拟机出任何问题了。
3、通用性好，是转为其他虚拟机的格式的通用中间格式，这样就不用担心转换虚拟机系统了。

ps：我知道这不是事情的最终面目，这个只是我目前的理解阶段，所以提出来供大家讨论，以期提高。