版权声明：本文为耕耘实录原创文章，各大自媒体平台同步更新。欢迎转载，转载请注明出处，谢谢。
随着云计算、大数据的发展，虚拟化改造已经成为一种行业趋势。在虚拟化实施过程中，P2V,V2V操作对于运维人员来说已经成为家常便饭。笔者从进入现在的公司开始就一直对公司现有的计算资源进行虚拟化改造，经历了P2V，V2V的各种折腾（包括Windows、Linux物理机向KVM、VMware虚拟化平台的迁移，VMware向KVM迁移，LXC容器向KVM平台迁移）。目前项目已经进行到一半，用大量时间实践了各种迁移方案，现将迁移过程容易失败的一些问题进行总结，希望对大家有所帮助。
1、分区表格式。这是一个很严重的问题，很多迁移工具不支持GPT格式的系统迁移，只支持MBR格式的系统迁移，在选择工具之前需要格外注意一下。
2、通用的OVF格式可能是个坑。我们采用的是H3C的CAS虚拟化平台，是居于KVM的一个虚拟化平台。在整个虚拟化项目开始之前，我通过查询资料，得知OVF模板是虚拟化业界比较通用的一种格式，是业界几个大厂商联合制定的标准。按照这种思路，从VMware迁移到KVM使用OVF模板就能搞定，CAS系统也是支持OVF模板导入的，根本无需再折腾。在实际操作过程中，发现CAS系统的OVF模板与其他厂商并不兼容，只支持自己的OVF模板，一个巨坑！
3、迁移之后磁盘不能成功挂载原系统的磁盘分区，系统不能成功启动。出现这种情况，一种很大的可能就是在原系统使用的是设备名称挂载的方式挂载的，在两个虚拟化环境中硬盘接口发生了变化，比如由原来的IDE接口变成了virtio接口，这样的话设备名称是会变的，设备名称会由原来的sda变为vda，这就需要修改fstab了（光盘引导，进入救急模式）。如果是通过UUID挂载的，一般来说不会出现这种问题。
