1读写机制
为了消除冗余和方便系统升级，系统镜像可能同时被多个虚拟机实例访问，因而虚拟机实例不可以更改该镜像文件的数据。同时，用户镜像不是简单的以磁盘形式挂载到系统的某个文件夹下，而是在目录级别与系统数据融合，对一个系统目录的修改也有可能实际是对用户数据的修改。更重要的，我们向用户屏蔽了数据是分离存储的，用户只能看到一个统一的文件系统，对之拥有可读可写的权利。在使用时，能向该虚拟机的目录树下的任意位置写数据。用户对系统镜像的修改也必须被存储到用户镜像中。在我们的设计中，借助于开源软件Unionfs来处理用户镜像文件的挂载问题，这样做有两个好处：1）Unionfs本身是对文件系统作合并操作，而不是像mount操作那样简单的覆盖性地挂载。合并后，多个分支里的文件都可以被系统访问。2）Unionfs对合并的分支提供了基本的权限控制，可以决定每个分支的读写权限，同时可简单地指定哪些分支来执行写操作。在系统运行时，对系统与用户文件系统下目录进行逐一合并。对于合并的目录，我们会在挂载点下建立同名的文件夹，然后把挂载点下的文件夹设置为可写，同时设置为高优先级，系统根目录下的文件夹设置为只读，再把合并后的访问点设置为系统根目录下的文件夹（如图3所示）。这样就可以保证在保证系统镜像的只读时，把用户的写操作写到用户镜像文件，同时，又使得文件重定向操作对用户变得透明。
2模型实现
基于上述系统设计，我们在qemu-kvm-1.0版本的KVM虚拟机上实现了细粒度系统和用户数据分离与融合，虚拟机实例的GuestOS是Ubuntu12.04。
2.1环境准备
按照设计中镜像格式的要求，提供系统镜像与用户镜像的镜像文件为qcow2格式，以满足镜像文件大小的动态增长，分别用system.img和user.img来表示。由于KVM虚拟机本身支持多镜像启动，所以直接使用KVM原始的命令行接口，即使用-hda选项作为系统镜像的接口，-hdb选项作为用户镜像的接口。一个简单的基于KVM的用户、系统数据分离的多镜像启动命令如下：系统镜像上安装操作系统时，系统默认将硬盘划分为3个分区：主分区sda1、扩展分区sda5和逻辑分区sda2。系统运行时主分区被挂载成根分区，逻辑分区被挂载成交换分区。由于交换分区用来保存操作系统运行时被换出来的页，当系统镜像被多个虚拟机实例同时使用时，每个虚拟机实例都可能向交换分区中写入数据，这样会破坏其它虚拟机的数据。因此，在多镜像启动模型中不能使用系统镜像的交换分区。基于虚拟机实例独占自身的用户镜像，因此在用户镜像模拟的虚拟磁盘里开辟出分区sdb2，用作GuestOS的交换分区。此外，在系统运行过程中，/var目录主要用来存储系统运行时进程的信息，里面的数据会随着系统启动而开始变化。因而，如果在系统运行时执行合并操作，则可能会由于进程对里面文件的写操作加锁而导致合并失败。即使合并成功，也会在系统关机时出现循环等待的问题而导致系统不能正常关机。对此，选择不合并此目录，同样的在用户镜像中开辟出分区sdb5，用来备份系统镜像的/var内容。因为该文件夹本身会存放进程自身的日志，所以在一些运行有需要记录大量日志的进程的系统中，也会专门把该目录挂载到特定分区来提高系统的性能。因此，用户镜像被划分为3个分区，分别为用来存储用户数据的sdb1、挂载GuestOS交换分区的sdb2和保存/var目录数据的sdb5。因为Linux内核本身不支持Unionfs，所以采用内核编译的方式来向Linux内核里添加Unionfs支持，以支持Unionfs在系统中以模块的形式被使用。
2.2合并配置
用户镜像在和系统镜像合并之前，创建对应的文件目录架构。在用户镜像下的逻辑分区sdb1建立需要与系统文件目录合并的目录（除开dev、proc、run、sys等4个目录，在系统运行时，会分别被挂载成devtmpfs[10]、procfs[11]、tmpfs[12]和sysfs[13]等内存文件系统）以进行持久化存储。然后将用户数据分区sdb1挂载到挂载点/mnt/user，在其下进行目录合并。在系统启动前，设置操作系统启动时需要挂载的设备和需要合并的目录。由于操作系统启动时会自动执行/etc/fstab里的挂载操作，因而，直接把挂载和合并操作写入到/etc/fstab文件里。之所以选择这个配置文件，一方面是为了保证合并后的文件系统在系统启动过程中被顺利挂载；另一方面，参照此配置文件中对文件系统的操作描述，可灵活的改变需要加入到合并操作中的文件目录。/etc/fstab的记录保存在系统镜像文件中。因为这些规则一旦写入，则在启动虚拟机实例时GuestOS就会在用户登录之前自动执行这些挂载操作。当用户试图修改里面的记录规则时，应在GuestOS里使用umount命令卸载掉对/etc目录的合并规则，否则用户的更改就会写入到用户镜像文件。在GuestOS读取并执行/etc/fstab里的记录时，用户镜像文件对应的目录还没有执行对应的合并操作。因而，用户的修改就不会生效。
3测试
基于上述实现，我们比较了KVM原有的多镜像启动（v1）和我们提出的细粒度多镜像启动（v2），测试指标包括虚拟机启动的开机时间和文件系统的读写性能两个方面。宿主机和物理机的操作系统均采用内核版本为3.2.44的Ubuntu12.04，采用版本号为1.0的KVM虚拟化软件，使用IOzone[14]作为测试读写性能的工具。首先测试两种方案下的开机时间。在开机时间方面，开机过程是指从主机操作系统上开始运行虚拟机实例启动，到虚拟机实例里的客户机操作系统加载完所有的预设启动项。开机时间即这两个时间点之间的时长。在进行多组测试后，得到图4中所示的平均开机时间。如图4所示，多镜像启动v2开机时间比多镜像启动v1多1.1s，约为2.2%。出现这种情况的原因是在多镜像启动v2下虚拟机开机启动时需要执行Unionfs的合并操作以及挂载合并后的新的文件目录，但这种情况属于可允许的波动范围。对于用户体验来说，几乎没有太大影响。因此，多镜像启动v2的虚拟机在启动时间上带来的延迟是可以接受的。然后对比两种方案下虚拟机在运行中文件系统的读写性能。由于多镜像启动v1所做的修改位于GuestOS的VFS底层，所以对合并后的文件系统进行读写测试是很有必要的。实验条件和测试开机时间时相同，文件读写操作选取了读、写、重读和重写四种，所取结果源自多组重复稳定测试后的平均值，对比情况如图5所示。在整体上，多镜像启动v1和多镜像启动v2在文件读写性能上的测试数据十分接近，在重读操作上v2虚拟机略高于v1。由于性能差别不大，而且各有上下，因而可以认为性能上存在的细微差距是测试中的不可避免的偶然误差导致的。因此，在多镜像虚拟机模型中，文件系统的读写性能基本维持不变。
4结束语
本文设计了基于KVM虚拟机的细粒度系统、用户数据分离和融合的多镜像启动方案，来解决虚拟机镜像文件中系统数据冗余的问题。并在KVM虚拟机平台上，利用Unionfs文件系统工具实现了简单的多镜像文件启动模型。通过测试表明，该方案在开机启动时间和文件读写性能上没有比较明显的损失，符合设计的预期。该方案在实现方面还存在一些不足，有待以后完善和改进。譬如，1）由于该实现模型中对文件系统的合并是在GuestOS启动之后，因而无法控制对GuestOS自身的一些设置。可考虑把文件系统的合并提前到Initrd中去执行，以尝试加强对GuestOS的控制；2）目前的实现依赖于开源系统Unionfs，它的不稳定可能会影响多镜像系统的运行，下一步工作中会对其进行改进。
作者：盖玲 郭凯 龚奕利 单位：江汉大学 政治学院 武汉大学 计算机学院
相关专题：mm理论 图学学报是核心期刊吗
