本文主要是介绍从源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字节，那需要能解析并理解分区表。我也充分清楚了解。
这篇关于从源PC上一次性p2v(qcow2)的构想的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
