从源PC上一次性p2v(qcow2)的构想

磁盘分区表，虚拟硬盘文件，操作系统引导

1. 基本概念和术语

源硬盘：一般就是客户的PC机的硬盘，硬盘里面包含了Windows分区。

源Windows：以源硬盘启动的Windows环境。

虚拟磁盘文件：文件格式有qcow2、vhd、vhdx等。一个虚拟磁盘文件模拟一个磁盘，要模拟两个磁盘得用两个虚拟磁盘文件。

分区表：常见就mbr和gpt两种。

分区（磁盘分区）：给磁盘建立分区表后，可将一个磁盘的存储空间分成若干段落，每一段就是一个分区。

分区表表头：在给磁盘建立分区表后，磁盘初始位置的几百~几千字节的数据就是分区表表头，它索引了该磁盘分为几个分区，每个分区的头尾位置、大小、预设功能等。

gpt备份：磁盘若选用gpt分区表，则磁盘尾部的几百字节数据，它是gpt备份。

磁盘签名、磁盘guid：mbr的分区表表头里有一段数据是磁盘签名，gpt的分区表表头里有一段数据是磁盘guid。它们的诞生时机是新建分区表的时候。windows系统假定每个磁盘的磁盘签名（或磁盘guid）都不同。若两个磁盘的签名（或guid）相同，windows可能会把两个磁盘给弄混了。

引导方式：从bios程序寻找操作系统引导文件的方法，常见的就legacy和uefi两种。可以有mbr配legacy，mbr配uefi，mbr配双引导，gpt配uefi四种。

引导分区：存放系统引导文件的分区。一般是legacy场景下的活动分区和uefi场景下的EFI分区。

引导修复：创建（或找到）引导分区和Windows分区，建立正确的引导文件。

disk2vhd：微软出品的物理磁盘转vhd(x)的工具。

diskgenius：某公司出品的磁盘（分区）综合管理工具。

2. 1.x方案的p2v方案简述

2.1 流程

步骤A所在的环境为源Windows。步骤B（含）之后的操作所在环境简称为转换环境。转换环境一般选用源Windows即可，也可选其它机。

A. 在源Windows里执行disk2vhd，将C盘所在硬盘转为vhd(x)文件。

B. 用Windows自己的磁盘管理器，把vhd(x)像真实磁盘一样挂载到Windows环境里。

C. 根据云桌面对引导方式的需求，要求操作员手工执行mbr（gpt）转gpt（mbr）或自动执行mbr转gpt。

D. 用Windows自己的dism等工具把虚拟化设备的驱动（viosscsi、netkvm等）安装到vhd里的Windows。

E. 用Windows自己的diskpart工具，压缩分区，定制引导分区。

F. 用Windows自己的bcdboot工具修复引导。

G. 用qemu的qemu-img将vhd(x)转为qcow2。

H. 把qcow2所代表的磁盘的尾部的未分配空间砍减掉。

I. 就地启动qemu虚机，以qcow2文件作为磁盘，验证能否启动windows。

K. 上传qcow2到rcdc。

2.2 方案选型考虑

A. 为什么要mbr(gpt)转gpt(mbr）？

正规的配置方案是mbr配legacy，gpt配uefi。rcdc和idv启动镜像前，选取哪种引导方式就跟操作系统和分区表有关。假使源pc是Win10的mbr+legacy，所以我们得到的vhd也是Win10的mbr，但预期rcdc会以uefi启动这个镜像，所以要修正为gpt+uefi。

B. 为什么要经过vhd而不是直接从物理磁盘转为qcow2？

因为vhd能够很容易地像真实磁盘一样挂载出来，只要是挂载出来的磁盘，就能很容易用windows自有工具达成2.1的D、E、F的需求。

若想要qcow2像真实磁盘一样挂载出来，那么有方法但确实不如vhd那么容易。

C. 为什么要把qcow2尾部未分配空间砍减？

假设源硬盘（总量301GB）的分区布局如下：

分区表表头

引导分区（500MB）

D盘（160G）

C盘（30G）

恢复分区（500MB）

E盘（110G）

在disk2vhd运行时，尽管只转换C盘，但是得到的vhd依然是代表301GB的磁盘，分区空间也是划分好的，得到vhd如下布局：

分区表表头

引导分区（500MB）

raw文件系统分区（160G）

C盘（30G）

恢复分区（500MB）

raw文件系统分区（110G）

末尾的110.5GB空间都可以砍减的。如果不砍减，那么rcdc也不支持以301GB的qcow2来新建镜像。

纵使编辑镜像环境没有300GB的限制，如果不砍减，在IDV场景下，即使客户实际只需30G的C盘，那么110.5GB的空间shine模块总要预留出来给C盘扩展用，这个预留就是浪费了的。

3. 旧方案的缺陷

A. vhd文件的生成耗时也不灵活

C盘通常是大几十G，所以生成的vhd也有大几十G，大几十G的文件的生成总要十来分钟。若不经过vhd，直接从物理磁盘到qcow2，这十来分钟就能省下来。

见2.2.C。vhd会把分区表表头，分布布局，磁盘签名（或guid）都从源硬盘复制到vhd里。此时若在源Windows里就地挂载vhd，就会触发相同磁盘签名（或guid）的异常，进而导致转换环境蓝屏，mbr（gpt）转gpt（mbr）异常，引导修复异常等问题。

见2.2.C，vhd里中间160G的未分区部分，C盘不能利用上。这段空间可以新建D盘，但C盘的扩展方向只能往C盘的尾部方向扩展，不能往头部方向扩展。

B. mbr（gpt）转gpt（mbr）麻烦，还会经常失败

失败原因见A。

mbr转gpt可以用windows原生自带的mbr2gpt.exe。但gpt转mbr则需要操作员用diskgenius手工操作，显得操作不够流畅。

C. 砍减qcow2会砍减掉gpt备份

多数情况下没有问题。但是毕竟就使用了不正规的gpt分区形式，有隐患。

D. n个磁盘里的m个分区不能整合到一个qcow2里

n个磁盘就会生成n个vhd。1.x方案没法将n个vhd整合成一个qcow2。

4. 精进方案的构想

4.1 流程

A. 展示源硬盘

例如源硬盘有2个，p2v工具的ui直接展示出来：

分区表表头

引导分区（500MB）

D盘（160G）

C盘（30G）

恢复分区（500MB）

E盘（110G）

分区表表头

F盘（100G）

G盘（50G）

B. 勾选分区

用户在UI上勾选了若干分区，并要求组装成如下形式：

分区表表头

引导分区（500MB）

恢复分区（500MB）

F盘（100G）

D盘（160G）

C盘（30G）

C. 新建qcow2

p2v工具用qemu工具直接新建291G的qcow2。

D. 挂载qcow2

用TCI产品的rjvdisk的技术，把qcow2像物理磁盘一样挂载到Windows的磁盘管理器里。

E. 给qcow2磁盘新建分区表

如B样式划分分区位置和大小。

F. 分区拷贝

直接读取源磁盘各个分区的裸数据，拷贝到qcow2磁盘对应的分区位置里。

G. 其它流程

执行2.1的D、E、F、I、K。

4.2 新方案改良点

A. 跳过大几十G的vhd文件的生成

B. 天然规避了磁盘签名（guid）的雷同

由于4.1.E是新建的分区表，所以磁盘的mbr签名或者gpt的磁盘guid都是新建的，大概率不会跟源磁盘雷同。

C. 不需mbr转gpt或gpt转mbr

D. 镜像分区灵活

可以达成n个磁盘里的m个分区能整合到一个qcow2里。

可以保证C盘的末尾一定是磁盘的末尾，这样C盘就会有充分的扩展空间。

不会出现C盘前头存在未分配空间的情况。

5. 关于精进方案的初步的可行性验证

5.1 把qcow2像物理磁盘一样挂载

TCI产品的vdisk.sys程序就是在Windows开机的早期阶段，模拟一个achi磁盘控制器，再把qcow2当作真实磁盘一样挂载在磁盘控制器下，然后从这个磁盘启动Windows。本文方案在Windows启动之后再模拟一个achi磁盘控制器，再把qcow2挂载和卸载，应该是容易达成的，技术上充分具备的。

5.2 直接读取源磁盘各个分区的裸数据，拷贝到qcow2磁盘对应的分区位置里

直接读写磁盘某某段落的裸数据，p2v1.0已达成。

识别出某个分区的空间是从磁盘头偏移X字节到Y字节，那需要能解析并理解分区表。我也充分清楚了解。