尧图网站建设 
简介这套信创虚拟化及云平台解决方案PPT面向企业IT规划、信创迁移项目负责人及虚拟化平台选型人员针对国产芯片路线多样、软硬件生态不成熟、应用迁移难度大等现实问题提出基于服务器虚拟化与云计算技术的整体应对路径。内容涵盖信创建设挑战分析、信创云整体解决方案、虚拟化产品介绍及成果介绍四大部分并展开服务器虚拟化、软件定义基础架构、多云融合架构三类典型应用场景以及不同规模用户的分级建设建议对鲲鹏、飞腾、海光、龙芯、兆芯、申威等芯片路线亦有选型要点与性能对比梳理。资源为单个PPT文件约3.09MB四部分结构清晰可直接用于方案汇报、团队内部培训或项目前期调研参考。目前已有984人学习适合需要快速理解信创虚拟化技术架构和建设思路的从业者。1. 信创虚拟化及云平台为什么这次不是“PPT 里画画”就算完做信创项目最怕什么最怕方案汇报时 PPT 讲得天花乱坠落到机房却发现装不上、跑不动、迁移不了。所谓“信创虚拟化及云平台解决方案”本质上就是把基于 x86 的 VMware 或 OpenStack 那一套平移到鲲鹏、飞腾、海光、昇腾这些国产 CPU 和麒麟、统信这些国产操作系统上。这不是换个芯片重装一遍而是从 Hypervisor 选型、虚拟化层兼容、存储网络适配到迁移割接的整套重构。这篇笔记就从我实际做过的信创虚拟化项目出发讲清楚这套方案怎么落地参数怎么调哪些坑值得提前绕开。2. 信创虚拟化与云平台的选型逻辑先看 CPU 和操作系统再谈架构2.1 信创虚拟化的核心约束ARM 和 x86 的“双轨制”信创虚拟化方案的第一道分水岭不是虚拟化软件本身而是底层 CPU 架构。目前主流信创 CPU 分成两派鲲鹏和飞腾走 ARM 架构海光和兆芯走 x86 架构。这直接决定了你用哪套虚拟化方案。如果是 ARM 架构的鲲鹏或飞腾服务器常见的做法是用KVMKernel-based Virtual Machine配合libvirt做虚拟化底层操作系统选麒麟 V10 或统信 UOS 服务器版。KVM 在 ARM 上并不是简单的“有就能用”它依赖 ARM 的硬件虚拟化扩展——ARMv8 的 Virtualization ExtensionsEL2 特权级。好在海光、兆芯这类 x86 架构的 CPU 对 KVM 的支持就成熟得多基本可以直接复用现有 x86 生态。选型时我会先做一步硬件摸底通过/proc/cpuinfo确认 CPU 型号再检查虚拟化支持。ARM 上跑 KVM 还需要确认内核编进了KVM_ARM模块通常麒麟内核默认带但有些裁剪版服务器系统会去掉这就得重新编译内核非常麻烦。另一个关键约束是操作系统的内核版本。信创 OS 大多是 4.19 或 5.10 LTS 内核KVM 和 libvirt 的版本比较老和最新版虚拟化软件会有兼容性问题。所以选型时我会先锁定内核版本再去选配套的 qemu-kvm、libvirt 版本而不是反过来。2.2 KVM OpenStack还是 KVM 自研平台信创项目的虚拟化层选型我看到的主流方案有三种纯 KVM 虚拟化、KVM OpenStack 云平台、商业信创虚拟化软件如华为 FusionSphere、华云、云宏等。如果项目是私有云规模在几十台物理机以上走 KVM OpenStack 是最常见的路线因为 OpenStack 社区版已支持 ARM 架构不用二次开发就能把计算、存储、网络统一纳管。但注意OpenStack 组件在 ARM 上的坑比 x86 多。Nova 的虚拟化驱动libvirt在 ARM 上没问题但 Neutron 的网络节点如果用 Open vSwitchOVSARM 版 OVS 的性能和稳定性不如 x86。我一般会建议在 ARM 平台用 Linux Bridge 而不是 OVS少折腾。如果是 10 台以下的小规模直接用 KVM libvirt 手动管理就行上 OpenStack 反而引入高可用和网络复杂度维护成本远大于收益。另外一个常见做法是直接采购商业信创平台。优点是省心缺点是对底层硬件绑定较深扩容和迁移时受厂商限制。我做过的一个项目前期用了某商业平台后期因为授权问题迁移到自建 OpenStack 集群迁移的代价很高。所以选型时要把未来三到五年的扩容和退出成本算进去。2.3 信创目录产品名单与方案选型的现实关系做信创方案离不开“信创目录产品名单”这是招标和验收的硬门槛。名单里包含芯片、操作系统、整机、数据库、中间件等类别但虚拟化软件这个品类在不同批次目录里的名称和范围不太一样。实际操作中我一般会把目录里的适配项分成两类虚拟化平台如华为 FusionSphere、浪潮云海和云平台如 OpenStack 衍生发行版。选型时首先要看项目对“信创安全工程师”资质的要求——有些项目投标时要求虚拟化平台厂商提供适配认证这直接影响中标。注意目录名单是动态调整的。建议在招标文件发布后以最新一期目录为准不要沿用上一年的清单否则可能出现产品被移出目录导致废标的风险。3. 用 KVM 在 ARM 信创服务器上跑通最小虚拟化环境从内核参数到虚拟机启动3.1 检查硬件虚拟化支持并加载 KVM 模块这一步是整个方案的第一道门槛。ARM 服务器的 BIOS 通常默认开启虚拟化扩展但有些国产服务器固件会把虚拟化功能藏在一个不起眼的设置里出厂默认关闭。物理机装好麒麟 V10 后第一步检查 KVM 模块是否加载# 检查 KVM 模块是否已加载 lsmod | grep kvm # 如果没加载尝试手动加载 modprobe kvm modprobe kvm_arm # 检查设备节点是否存在 ls -l /dev/kvm如果/dev/kvm不存在说明模块没加载成功。ARM 平台上kvm_arm模块依赖硬件虚拟化扩展检查/proc/cpuinfo里有没有hyp标志位没有的话进 BIOS 找Virtualization或SVE相关选项打开。逻辑说明KVM 模块加载成功后虚拟机运行时通过/dev/kvm接口直接使用硬件虚拟化能力模块加载失败则只能退回到 QEMU 的纯软件模拟TCG性能下降一个数量级跑 Windows 虚拟机基本不可用。参数说明hyp标志位是 ARM 的 Virtualization Extensions 使能标识。有些 ARM 服务器支持虚拟化但cpuinfo不显示hyp这通常是固件版本太老升级固件就能解决。另外kvm_arm模块只对 ARMv7 及以上架构有效老型号 ARM CPU 需要另想办法。3.2 创建虚拟机镜像和 libvirt 域配置KVM 模块就绪后用qemu-img创建磁盘镜像再用virt-install一步创建虚拟机。最小化验证时我习惯跳过安装过程直接用 cloud image能省大量时间# 创建 40G 的 qcow2 磁盘镜像 qemu-img create -f qcow2 /data/kvm/centos7-arm.qcow2 40G # 用 virt-install 创建虚拟机指定 ARM64 架构 virt-install \ --name demo-vm1 \ --memory 4096 \ --vcpus 2 \ --os-variant centos7.0 \ --disk path/data/kvm/centos7-arm.qcow2,formatqcow2,size40 \ --network bridgebr0 \ --graphics vnc,listen0.0.0.0 \ --noautoconsole逻辑说明--os-variant告诉 libvirt 使用针对 CentOS 7 ARM 优化过的虚拟硬件配置如 virtio 驱动、默认 ACPI 表。ARM 上 ACPI 表不对会导致虚拟机无法启动或无法识别磁盘所以这个参数不能省。--network bridgebr0将虚拟机接入物理网桥生产环境一定要用桥接而不是 NAT否则虚拟机无法对外提供业务服务。参数说明--memory是分配给虚拟机的内存单位 MBARM 虚拟机的内存分配在宿主机物理内存充足的情况下尽量给满业务需求Overcommit 策略建议保守这与 x86 平台不同--vcpus建议与宿主机的物理核心数匹配ARM 服务器的核数通常很多但块设备 IO 和网络中断处理也算 CPU 开销少量虚拟机可以按 1:2 超配。--graphics vnc,listen0.0.0.0暴露 VNC 端口用于安装系统生产环境建议只监听内网或使用 SSH 隧道访问否则有安全风险。3.3 用 libvirt 常用命令管理虚拟机生命周期创建之后日常操作都走virsh。几个关键命令和排查思路如下# 查看虚拟机运行状态 virsh list --all # 启动自动启动物理机重启后自动拉起虚拟机 virsh autostart demo-vm1 # 在线调整 CPU 和内存上限热插拔场景 virsh setvcpus demo-vm1 --maximum 4 --config virsh setvcpus demo-vm1 --count 4 --live # 查看虚拟机 VNC 显示端口 virsh vncdisplay demo-vm1逻辑说明virsh autostart对信创项目尤其重要因为很多国产服务器的 IPMI 或带外管理系统不够可靠物理机意外重启后虚拟机自动恢复是刚需不能依赖人工干预。参数说明setvcpus的热插拔依赖虚拟机内部的 ACPI 支持和宿主机 CPU 拓扑配置。ARM 虚拟机对 CPU 热插拔的支持普遍不如 x86 完善个别内核版本下热插拔后虚拟机出现 soft lockup因此除非业务明确要求否则建议在计划维护窗口内修改配置并重启虚拟机生效。4. 从 VMware 到信创云平台的迁移落地迁移工具、网络映射与存储切换4.1 迁移前的准备采集 VMware 虚拟机配置清单信创项目里最常见的场景是把存量 VMware 虚拟机迁到国产化平台。这类迁移最怕的是没摸清虚拟机配置就动手迁到一半发现磁盘控制器不兼容或 IP 地址冲突。我会在迁移前做一次配置基线采集逐个虚拟机记录 vCPU、内存、磁盘大小、网卡 MAC、IP 地址、操作系统版本和需要保留的静态路由。# 通过 ovftool 导出 OVF 模板含磁盘和配置 ovftool --lax vi://administratorvcenter.example.com/datacenter/vm/web-prod \ /mnt/migration/web-prod.ovf # 查看导出的虚拟机配置 grep -E (Memory|CPU|s/vcpus|DiskCapacity) /mnt/migration/web-prod.ovf逻辑说明ovftool导出的 OVF 是最接近 VMware 原生配置的格式。后面的--lax参数是为了容忍 OVF 里的不标准字段我在几台特定版本 ESXi 上见过兼容性描述导致导出失败加了这个参数能跳过严格校验。参数说明导出的 OVF 文件中包含了 vCPU 数量和内存大小等关键元数据但不包含 IP 地址。如果迁移后要保留原 IP需要先在目标平台建好网络并用静态 IP 方式配置如果采用 DHCP务必要在迁移窗口前提前释放原环境的 IP避免冲突。4.2 使用 virt-v2v 做镜像转换导出的 OVF 不能直接被 KVM 使用。我常用的转换工具是virt-v2v它可以把 VMware 的 vmdk 磁盘格式转换成 qcow2并自动替换 virtio 驱动避免虚拟机进入新平台后蓝屏或卡在启动界面。# 将 VMware 导出的 OVF 转换为 KVM 可用的 qcow2 磁盘 virt-v2v -i ova /mnt/migration/web-prod.ovf \ -o local -os /data/kvm \ -of qcow2 -osd qcow2 \ --network bridgebr0逻辑说明virt-v2v内部做了三件事把 vmdk 转换格式、注入 virtio 驱动、修改启动配置。Windows 虚拟机的启动盘默认是 IDE 控制器如果转换后不换驱动新虚拟机加载不到磁盘驱动就会启动失败。Linux 虚拟机的转换相对简单virtio 驱动通常在系统内核里已内置。参数说明--network bridgebr0是网络映射参数把原 VMware 端口组映射到目标 KVM 的网桥。如果源虚拟机有多个网卡且对应不同网段建议用--network逐一映射不要一刀切全部桥接到同一个 br0。-os是目标存储路径我用/data/kvm是因为数据盘独立挂载方便后续做快照和数据备份。4.3 存储规划本地盘还是集中存储信创虚拟化项目里存储选型往往比计算选型更容易踩坑。常见组合有四种本地 RAID 盘、集中式存储SAN/磁盘阵列、分布式存储Ceph和信创厂商自研存储。每种方案都有各自明确的适用边界。存储方案适用规模优势常见问题本地 RAID单机或 3 节点以下部署简单、性能稳定无高可用节点故障即业务中断集中式存储中型生产集群成熟稳定、运维经验丰富依赖厂商支持信创协议成本高Ceph 分布式3 节点以上扩展性好、软硬件解耦网络要求高重删和快照性能需调优商业信创存储大型项目适配好、服务响应快绑定厂商扩容灵活性差我一般建议 5 节点以下测试环境用本地 RAID生产至少 10 节点以上再考虑 Ceph。Ceph 的块设备RBD配合 KVM 是标准玩法但信创 ARM 平台上的 Ceph 性能调优比 x86 更多网卡队列、中断绑核、PG 数量都要重新调直接用 x86 参数大概率性能不达标。如果预算允许集中式存储阵列是最稳的选择但强烈建议在采购前让存储厂商提供信创 CPU 服务器下的实测 IOPS 和延迟数据不要只看 x86 环境的指标。5. 信创云平台的组件选型与配置落地计算、网络、存储的最小可用架构5.1 控制节点和服务节点拆分当一个项目做到“云平台”而不是“几台虚拟机”就要决定控制节点布局。我推荐的最小架构是三节点一个控制节点、两个计算节点或者三节点都做控制计算混合。混合部署在信创环境更常见原因是 ARM 服务器的单机核心数通常非常多64 核、128 核很常见纯控制节点会浪费一半算力。# 计算节点上启用 Nova 和 Neutron 服务 systemctl enable openstack-nova-compute systemctl enable neutron-linuxbridge-agent systemctl start openstack-nova-compute systemctl start neutron-linuxbridge-agent逻辑说明计算节点上需要跑两类服务Nova Compute 负责虚拟机生命周期管理Neutron Agent 负责网络转发。二者缺一不可否则虚拟机实例能创建但网络不通。控制节点则要跑 Nova API、Neutron Server、Keystone、Glance 等控制面服务。参数说明Neutron 这边我在 ARM 平台选择 Linux Bridge 而不是 OVS不是 OVS 不好而是 Linux Bridge 的配置和维护复杂度低得多ARM 平台上遇到的问题也少。如果业务对网络性能有较高要求再评估 OVS 的 DPDK 方案但那时就得考虑 CPU 绑核和网卡选型不是默认部署能搞定的。5.2 网络平面规划管理网、存储网、业务网三网分离信创环境下网络配置是虚拟机访问不通、性能慢的首因而根源通常是网络平面规划失误。生产环境我强制要求三网分离管理网络承载 OpenStack API 和 SSH存储网络承载 Ceph 或集中式存储的块数据流业务网络承载虚拟机的真实业务流量。三张网必须用独立物理网卡或至少独立 VLAN。# 创建 Linux Bridge 并绑定业务物理网卡计算节点 brctl addbr br-int brctl addif br-int eth2 ip link set br-int up # 在 Neutron 配置中指定网桥 vim /etc/neutron/plugins/ml2/linuxbridge_agent.ini逻辑说明br-int是业务网桥虚拟机虚拟网卡通过这个网桥对外通信。物理网卡 eth2 不做 IP 配置直接作为二层交换机端口挂到网桥上这个网桥上承载了所有虚拟机的业务流量。参数说明管理网、存储网、业务网如果共用一张物理网卡一台虚拟机疯狂下载就能打满网卡队列导致宿主机 SSH 卡死、存储 IO 超时。三网分离的代价是多插两根网线收益是避免后续无休止的排查。带宽方面存储网建议 25GE 起步业务网按峰值流量评估管理网 1GE 足够。5.3 镜像和快照管理云平台的镜像管理由 Glance 负责。我会提前把常用的操作系统镜像导入 Glance避免每次创建虚拟机都从外部下载既慢又不可控。Glance 上传镜像建议用qcow2格式它能支持快照和增量镜像功能# 上传 CentOS 7 ARM 镜像到 Glance openstack image create --disk-format qcow2 \ --container-format bare \ --public \ --file centos7-arm.qcow2 \ centos7-arm # 列出镜像确认可用 openstack image list逻辑说明--disk-format qcow2是镜像格式参数如果上传的是裸格式则需要改成 raw。--container-format bare表示镜像文件没有外部容器封装是 Glance 最常用的组合。参数说明ARM 和 x86 的镜像不能混用。鲲鹏服务器上传 x86 的 CentOS 镜像虚拟机创建后一定会以 firmware 错误或内核 panic 告终。所以镜像命名里我会加上arm或x86后缀避免多人协作时拿错镜像。另外如果镜像文件超过 10G上传过程容易超时可以设置 Glance 的allowed_direct_url托管方式让计算节点直接从镜像服务器拉取。6. 信创虚拟化避坑指南5 个最常见问题与排查思路6.1 VNC 控制台黑屏虚拟机无法启动现象用virsh start启动虚拟机成功但通过 VNC 连接控制台是黑屏或者卡在固件启动界面不动。原因ARM 架构下没有标准的 BIOS虚拟机的固件选择直接决定能否启动。默认固件如 UEFI 或 SeaBIOS如果与实际镜像不匹配就会卡死在固件初始化阶段。另一个常见原因是--os-variant没有指定正确值导致 libvirt 使用了错误的机器类型machine type。解决先检查虚拟机 XML 配置里的固件和机器类型virsh edit demo-vm1 # 检查 os 段 # 确保 firmware 为 uefimachine 类型为 virt 或 vexpressARM 虚拟机必须使用 UEFI 固件推荐virt机器类型同时确保--os-variant用了支持 ARM 的变体如centos7.0或rhel7.0。如果仍然黑屏把virsh start --console加上再看启动日志能定位是否卡在内核解压前。6.2 虚拟机网络不通ping 网关无响应现象虚拟机创建成功能开机但无法 ping 通同网段的其它机器从宿主机也 ping 不通虚拟机 IP。原因信创平台最常见的是网桥配置错误或 Neutron 的端口安全策略阻止了流量。Linux Bridge 模式下如果宿主机的物理网卡没有正确加入网桥虚拟机流量到网桥后就出不去了。另外 OpenStack 默认开风险端口安全会过滤所有非虚拟机来源的 MAC 地址。# 在宿主机上查看网桥状态 brctl show br-int # 查看网桥上是否有物理网卡 # 如果 Column 里没有 eth2说明绑定失败 ip link set eth2 master br-int解决优先确认物理网卡绑到网桥了再看端口安全——Neutron 端口默认开启了port_security_enabled True这会导致 DHCP 响应和组播协议被过滤。测试阶段直接关掉端口安全验证网络调通后再按需开启安全策略。6.3 虚拟机磁盘 IO 慢宿主机 load average 飙高现象虚拟机性能明显低于同等 x86 平台宿主机的 load average 异常飙升即使虚拟机空闲时也在高位。原因很多虚拟化层驱动没有正确安装。Windows 虚拟机没装 virtio 驱动磁盘回退到模拟 IDE 模式IO 性能只有 virtio 的十分之一同时宿主机 CPU 要模拟 IDE 控制器导致宿主机 load 升高。ARM 平台上这个差距更明显。# 在虚拟机内确认磁盘驱动 lsblk -d -o NAME,TRAN # TRAN 如果为 sata 或 ide说明 virtio 驱动没有安装 # 安装 virtio 驱动后重新启动解决Windows 虚拟机迁移前务必安装 virtio-win 驱动包括网卡和磁盘控制器驱动。Linux 虚拟机确认内核里是否编译CONFIG_VIRTIO_BLK和CONFIG_VIRTIO_NET。驱动装完后再重新配置虚拟机的磁盘控制器为virtio-scsi或virtio-blk。我在迁移项目里踩过这个坑当时一业务虚拟机是 Windows Server 2016迁移后 IO 性能下降七成最后发现是磁盘控制器没切换。6.4 Ceph 集群网络拥堵导致虚拟机卡顿现象多台虚拟机同时做大量 IO 时整个集群响应变慢甚至出现虚拟机 CPU steal 飙升。原因Ceph 的底层 IO 走存储网络存储网和业务网共用物理链路后业务流量和存储复制流量互相争抢带宽。CRUSH map 或 PG 数量配置不合理也会导致 IO 不均匀分布。解决网络层面必须确保存储网独立且存储网交换机不配置流控或限速。Ceph 的性能调优参数在信创 ARM 平台上需要关注osd_pool_default_pg_num和osd_max_backfills# 调整存储池的 PG 数量按 OSD 数平方除以副本数估算 ceph osd pool set volumes pg_num 512 ceph osd pool set volumes pgp_num 512PG 数量估算方法总 PG 数约等于OSD 数 × 100除以副本数。512 个 PG 只适用中小规模集群规模大时需要具体计算避免 PG 过多导致内存占用过高或启动慢。6.5 信创平台迁移后 Windows 虚拟机无法激活或蓝屏现象从 VMware 迁移到 KVM 后Windows 虚拟机能启动但提示激活失效部分虚拟机直接蓝屏。原因蓝屏通常是硬盘控制器驱动不兼容所致。激活失效是硬件抽象层HAL信息变化产生的正常现象——VMware 的虚拟芯片组和 KVM 的不一样只要迁移就会变化大概率触发微软激活机制。解决蓝屏问题用 virtio 驱动解决迁移前注入驱动。激活问题没有取巧路径需要在迁移前和业务供应商确认原授权是否支持迁移通常 Windows Server 的批量授权包含一定次数的重新激活。另有一个经验迁移后先在 VNC 控制台观察启动情况确认 Windows 能完整进入桌面后再接入网络避免激活验证在不稳定环境下触发锁定策略。7. 从单机到集群的进阶验证HA 与数据备份的一次实操走到了集群这一步还需要验证高可用和备份恢复能力。一个很重要的操作是模拟宿主机故障观察虚拟机能否自动漂移到其它节点。很多信创项目交付验收时才发现业务数据没有完整备份机制做一次故障演练就发现恢复流程根本没写。# 模拟计算节点故障在另一节点执行 openstack host set --disable --maintenance compute-arm-1 # 检查虚拟机是否自动迁移到其它计算节点 openstack server list --host compute-arm-2 # 恢复节点 openstack host set --enable compute-arm-1逻辑说明Nova 的 VM 高可用依赖一个前提计算节点被判定为故障后控制节点需要看到虚拟机实例处于错误状态并触发 evacuation。如果只是--disable不会自动迁移只会在下次调度时避开该节点。生产环境建议部署 Nova 的compute_ha服务或依赖外部 HA 工具做节点健康检查。数据备份这块我会在交付清单里明确三层备份策略第一层数据库层面的定时 mysqldump第二层镜像和卷存储层面用快照第三层整机备份用离线导出 qcow2 文件。恢复演练至少每季度做一次演练过程要记录恢复耗时不能只备份不验证。最后一个习惯每次做完这类方案我都会把架构图、IP 规划、迁移步骤、回退方案整理成运维手册。原因很简单虚拟化平台出问题时现场的运维人员往往不是搭建团队手册能让他们在故障时不靠猜。这套信创虚拟化及云平台方案最关键的检验标准不是功能演示多漂亮而是故障演练时系统能不能自己爬起来。希望这篇笔记帮你把迁移路上的坑提前填平。本文还有配套的精品资源点击获取 信创虚拟化与云平台落地实战：从KVM到ARM迁移避坑指南
简介这套信创虚拟化及云平台解决方案PPT面向企业IT规划、信创迁移项目负责人及虚拟化平台选型人员针对国产芯片路线多样、软硬件生态不成熟、应用迁移难度大等现实问题提出基于服务器虚拟化与云计算技术的整体应对路径。内容涵盖信创建设挑战分析、信创云整体解决方案、虚拟化产品介绍及成果介绍四大部分并展开服务器虚拟化、软件定义基础架构、多云融合架构三类典型应用场景以及不同规模用户的分级建设建议对鲲鹏、飞腾、海光、龙芯、兆芯、申威等芯片路线亦有选型要点与性能对比梳理。资源为单个PPT文件约3.09MB四部分结构清晰可直接用于方案汇报、团队内部培训或项目前期调研参考。目前已有984人学习适合需要快速理解信创虚拟化技术架构和建设思路的从业者。1. 信创虚拟化及云平台为什么这次不是“PPT 里画画”就算完做信创项目最怕什么最怕方案汇报时 PPT 讲得天花乱坠落到机房却发现装不上、跑不动、迁移不了。所谓“信创虚拟化及云平台解决方案”本质上就是把基于 x86 的 VMware 或 OpenStack 那一套平移到鲲鹏、飞腾、海光、昇腾这些国产 CPU 和麒麟、统信这些国产操作系统上。这不是换个芯片重装一遍而是从 Hypervisor 选型、虚拟化层兼容、存储网络适配到迁移割接的整套重构。这篇笔记就从我实际做过的信创虚拟化项目出发讲清楚这套方案怎么落地参数怎么调哪些坑值得提前绕开。2. 信创虚拟化与云平台的选型逻辑先看 CPU 和操作系统再谈架构2.1 信创虚拟化的核心约束ARM 和 x86 的“双轨制”信创虚拟化方案的第一道分水岭不是虚拟化软件本身而是底层 CPU 架构。目前主流信创 CPU 分成两派鲲鹏和飞腾走 ARM 架构海光和兆芯走 x86 架构。这直接决定了你用哪套虚拟化方案。如果是 ARM 架构的鲲鹏或飞腾服务器常见的做法是用KVMKernel-based Virtual Machine配合libvirt做虚拟化底层操作系统选麒麟 V10 或统信 UOS 服务器版。KVM 在 ARM 上并不是简单的“有就能用”它依赖 ARM 的硬件虚拟化扩展——ARMv8 的 Virtualization ExtensionsEL2 特权级。好在海光、兆芯这类 x86 架构的 CPU 对 KVM 的支持就成熟得多基本可以直接复用现有 x86 生态。选型时我会先做一步硬件摸底通过/proc/cpuinfo确认 CPU 型号再检查虚拟化支持。ARM 上跑 KVM 还需要确认内核编进了KVM_ARM模块通常麒麟内核默认带但有些裁剪版服务器系统会去掉这就得重新编译内核非常麻烦。另一个关键约束是操作系统的内核版本。信创 OS 大多是 4.19 或 5.10 LTS 内核KVM 和 libvirt 的版本比较老和最新版虚拟化软件会有兼容性问题。所以选型时我会先锁定内核版本再去选配套的 qemu-kvm、libvirt 版本而不是反过来。2.2 KVM OpenStack还是 KVM 自研平台信创项目的虚拟化层选型我看到的主流方案有三种纯 KVM 虚拟化、KVM OpenStack 云平台、商业信创虚拟化软件如华为 FusionSphere、华云、云宏等。如果项目是私有云规模在几十台物理机以上走 KVM OpenStack 是最常见的路线因为 OpenStack 社区版已支持 ARM 架构不用二次开发就能把计算、存储、网络统一纳管。但注意OpenStack 组件在 ARM 上的坑比 x86 多。Nova 的虚拟化驱动libvirt在 ARM 上没问题但 Neutron 的网络节点如果用 Open vSwitchOVSARM 版 OVS 的性能和稳定性不如 x86。我一般会建议在 ARM 平台用 Linux Bridge 而不是 OVS少折腾。如果是 10 台以下的小规模直接用 KVM libvirt 手动管理就行上 OpenStack 反而引入高可用和网络复杂度维护成本远大于收益。另外一个常见做法是直接采购商业信创平台。优点是省心缺点是对底层硬件绑定较深扩容和迁移时受厂商限制。我做过的一个项目前期用了某商业平台后期因为授权问题迁移到自建 OpenStack 集群迁移的代价很高。所以选型时要把未来三到五年的扩容和退出成本算进去。2.3 信创目录产品名单与方案选型的现实关系做信创方案离不开“信创目录产品名单”这是招标和验收的硬门槛。名单里包含芯片、操作系统、整机、数据库、中间件等类别但虚拟化软件这个品类在不同批次目录里的名称和范围不太一样。实际操作中我一般会把目录里的适配项分成两类虚拟化平台如华为 FusionSphere、浪潮云海和云平台如 OpenStack 衍生发行版。选型时首先要看项目对“信创安全工程师”资质的要求——有些项目投标时要求虚拟化平台厂商提供适配认证这直接影响中标。注意目录名单是动态调整的。建议在招标文件发布后以最新一期目录为准不要沿用上一年的清单否则可能出现产品被移出目录导致废标的风险。3. 用 KVM 在 ARM 信创服务器上跑通最小虚拟化环境从内核参数到虚拟机启动3.1 检查硬件虚拟化支持并加载 KVM 模块这一步是整个方案的第一道门槛。ARM 服务器的 BIOS 通常默认开启虚拟化扩展但有些国产服务器固件会把虚拟化功能藏在一个不起眼的设置里出厂默认关闭。物理机装好麒麟 V10 后第一步检查 KVM 模块是否加载# 检查 KVM 模块是否已加载 lsmod | grep kvm # 如果没加载尝试手动加载 modprobe kvm modprobe kvm_arm # 检查设备节点是否存在 ls -l /dev/kvm如果/dev/kvm不存在说明模块没加载成功。ARM 平台上kvm_arm模块依赖硬件虚拟化扩展检查/proc/cpuinfo里有没有hyp标志位没有的话进 BIOS 找Virtualization或SVE相关选项打开。逻辑说明KVM 模块加载成功后虚拟机运行时通过/dev/kvm接口直接使用硬件虚拟化能力模块加载失败则只能退回到 QEMU 的纯软件模拟TCG性能下降一个数量级跑 Windows 虚拟机基本不可用。参数说明hyp标志位是 ARM 的 Virtualization Extensions 使能标识。有些 ARM 服务器支持虚拟化但cpuinfo不显示hyp这通常是固件版本太老升级固件就能解决。另外kvm_arm模块只对 ARMv7 及以上架构有效老型号 ARM CPU 需要另想办法。3.2 创建虚拟机镜像和 libvirt 域配置KVM 模块就绪后用qemu-img创建磁盘镜像再用virt-install一步创建虚拟机。最小化验证时我习惯跳过安装过程直接用 cloud image能省大量时间# 创建 40G 的 qcow2 磁盘镜像 qemu-img create -f qcow2 /data/kvm/centos7-arm.qcow2 40G # 用 virt-install 创建虚拟机指定 ARM64 架构 virt-install \ --name demo-vm1 \ --memory 4096 \ --vcpus 2 \ --os-variant centos7.0 \ --disk path/data/kvm/centos7-arm.qcow2,formatqcow2,size40 \ --network bridgebr0 \ --graphics vnc,listen0.0.0.0 \ --noautoconsole逻辑说明--os-variant告诉 libvirt 使用针对 CentOS 7 ARM 优化过的虚拟硬件配置如 virtio 驱动、默认 ACPI 表。ARM 上 ACPI 表不对会导致虚拟机无法启动或无法识别磁盘所以这个参数不能省。--network bridgebr0将虚拟机接入物理网桥生产环境一定要用桥接而不是 NAT否则虚拟机无法对外提供业务服务。参数说明--memory是分配给虚拟机的内存单位 MBARM 虚拟机的内存分配在宿主机物理内存充足的情况下尽量给满业务需求Overcommit 策略建议保守这与 x86 平台不同--vcpus建议与宿主机的物理核心数匹配ARM 服务器的核数通常很多但块设备 IO 和网络中断处理也算 CPU 开销少量虚拟机可以按 1:2 超配。--graphics vnc,listen0.0.0.0暴露 VNC 端口用于安装系统生产环境建议只监听内网或使用 SSH 隧道访问否则有安全风险。3.3 用 libvirt 常用命令管理虚拟机生命周期创建之后日常操作都走virsh。几个关键命令和排查思路如下# 查看虚拟机运行状态 virsh list --all # 启动自动启动物理机重启后自动拉起虚拟机 virsh autostart demo-vm1 # 在线调整 CPU 和内存上限热插拔场景 virsh setvcpus demo-vm1 --maximum 4 --config virsh setvcpus demo-vm1 --count 4 --live # 查看虚拟机 VNC 显示端口 virsh vncdisplay demo-vm1逻辑说明virsh autostart对信创项目尤其重要因为很多国产服务器的 IPMI 或带外管理系统不够可靠物理机意外重启后虚拟机自动恢复是刚需不能依赖人工干预。参数说明setvcpus的热插拔依赖虚拟机内部的 ACPI 支持和宿主机 CPU 拓扑配置。ARM 虚拟机对 CPU 热插拔的支持普遍不如 x86 完善个别内核版本下热插拔后虚拟机出现 soft lockup因此除非业务明确要求否则建议在计划维护窗口内修改配置并重启虚拟机生效。4. 从 VMware 到信创云平台的迁移落地迁移工具、网络映射与存储切换4.1 迁移前的准备采集 VMware 虚拟机配置清单信创项目里最常见的场景是把存量 VMware 虚拟机迁到国产化平台。这类迁移最怕的是没摸清虚拟机配置就动手迁到一半发现磁盘控制器不兼容或 IP 地址冲突。我会在迁移前做一次配置基线采集逐个虚拟机记录 vCPU、内存、磁盘大小、网卡 MAC、IP 地址、操作系统版本和需要保留的静态路由。# 通过 ovftool 导出 OVF 模板含磁盘和配置 ovftool --lax vi://administratorvcenter.example.com/datacenter/vm/web-prod \ /mnt/migration/web-prod.ovf # 查看导出的虚拟机配置 grep -E (Memory|CPU|s/vcpus|DiskCapacity) /mnt/migration/web-prod.ovf逻辑说明ovftool导出的 OVF 是最接近 VMware 原生配置的格式。后面的--lax参数是为了容忍 OVF 里的不标准字段我在几台特定版本 ESXi 上见过兼容性描述导致导出失败加了这个参数能跳过严格校验。参数说明导出的 OVF 文件中包含了 vCPU 数量和内存大小等关键元数据但不包含 IP 地址。如果迁移后要保留原 IP需要先在目标平台建好网络并用静态 IP 方式配置如果采用 DHCP务必要在迁移窗口前提前释放原环境的 IP避免冲突。4.2 使用 virt-v2v 做镜像转换导出的 OVF 不能直接被 KVM 使用。我常用的转换工具是virt-v2v它可以把 VMware 的 vmdk 磁盘格式转换成 qcow2并自动替换 virtio 驱动避免虚拟机进入新平台后蓝屏或卡在启动界面。# 将 VMware 导出的 OVF 转换为 KVM 可用的 qcow2 磁盘 virt-v2v -i ova /mnt/migration/web-prod.ovf \ -o local -os /data/kvm \ -of qcow2 -osd qcow2 \ --network bridgebr0逻辑说明virt-v2v内部做了三件事把 vmdk 转换格式、注入 virtio 驱动、修改启动配置。Windows 虚拟机的启动盘默认是 IDE 控制器如果转换后不换驱动新虚拟机加载不到磁盘驱动就会启动失败。Linux 虚拟机的转换相对简单virtio 驱动通常在系统内核里已内置。参数说明--network bridgebr0是网络映射参数把原 VMware 端口组映射到目标 KVM 的网桥。如果源虚拟机有多个网卡且对应不同网段建议用--network逐一映射不要一刀切全部桥接到同一个 br0。-os是目标存储路径我用/data/kvm是因为数据盘独立挂载方便后续做快照和数据备份。4.3 存储规划本地盘还是集中存储信创虚拟化项目里存储选型往往比计算选型更容易踩坑。常见组合有四种本地 RAID 盘、集中式存储SAN/磁盘阵列、分布式存储Ceph和信创厂商自研存储。每种方案都有各自明确的适用边界。存储方案适用规模优势常见问题本地 RAID单机或 3 节点以下部署简单、性能稳定无高可用节点故障即业务中断集中式存储中型生产集群成熟稳定、运维经验丰富依赖厂商支持信创协议成本高Ceph 分布式3 节点以上扩展性好、软硬件解耦网络要求高重删和快照性能需调优商业信创存储大型项目适配好、服务响应快绑定厂商扩容灵活性差我一般建议 5 节点以下测试环境用本地 RAID生产至少 10 节点以上再考虑 Ceph。Ceph 的块设备RBD配合 KVM 是标准玩法但信创 ARM 平台上的 Ceph 性能调优比 x86 更多网卡队列、中断绑核、PG 数量都要重新调直接用 x86 参数大概率性能不达标。如果预算允许集中式存储阵列是最稳的选择但强烈建议在采购前让存储厂商提供信创 CPU 服务器下的实测 IOPS 和延迟数据不要只看 x86 环境的指标。5. 信创云平台的组件选型与配置落地计算、网络、存储的最小可用架构5.1 控制节点和服务节点拆分当一个项目做到“云平台”而不是“几台虚拟机”就要决定控制节点布局。我推荐的最小架构是三节点一个控制节点、两个计算节点或者三节点都做控制计算混合。混合部署在信创环境更常见原因是 ARM 服务器的单机核心数通常非常多64 核、128 核很常见纯控制节点会浪费一半算力。# 计算节点上启用 Nova 和 Neutron 服务 systemctl enable openstack-nova-compute systemctl enable neutron-linuxbridge-agent systemctl start openstack-nova-compute systemctl start neutron-linuxbridge-agent逻辑说明计算节点上需要跑两类服务Nova Compute 负责虚拟机生命周期管理Neutron Agent 负责网络转发。二者缺一不可否则虚拟机实例能创建但网络不通。控制节点则要跑 Nova API、Neutron Server、Keystone、Glance 等控制面服务。参数说明Neutron 这边我在 ARM 平台选择 Linux Bridge 而不是 OVS不是 OVS 不好而是 Linux Bridge 的配置和维护复杂度低得多ARM 平台上遇到的问题也少。如果业务对网络性能有较高要求再评估 OVS 的 DPDK 方案但那时就得考虑 CPU 绑核和网卡选型不是默认部署能搞定的。5.2 网络平面规划管理网、存储网、业务网三网分离信创环境下网络配置是虚拟机访问不通、性能慢的首因而根源通常是网络平面规划失误。生产环境我强制要求三网分离管理网络承载 OpenStack API 和 SSH存储网络承载 Ceph 或集中式存储的块数据流业务网络承载虚拟机的真实业务流量。三张网必须用独立物理网卡或至少独立 VLAN。# 创建 Linux Bridge 并绑定业务物理网卡计算节点 brctl addbr br-int brctl addif br-int eth2 ip link set br-int up # 在 Neutron 配置中指定网桥 vim /etc/neutron/plugins/ml2/linuxbridge_agent.ini逻辑说明br-int是业务网桥虚拟机虚拟网卡通过这个网桥对外通信。物理网卡 eth2 不做 IP 配置直接作为二层交换机端口挂到网桥上这个网桥上承载了所有虚拟机的业务流量。参数说明管理网、存储网、业务网如果共用一张物理网卡一台虚拟机疯狂下载就能打满网卡队列导致宿主机 SSH 卡死、存储 IO 超时。三网分离的代价是多插两根网线收益是避免后续无休止的排查。带宽方面存储网建议 25GE 起步业务网按峰值流量评估管理网 1GE 足够。5.3 镜像和快照管理云平台的镜像管理由 Glance 负责。我会提前把常用的操作系统镜像导入 Glance避免每次创建虚拟机都从外部下载既慢又不可控。Glance 上传镜像建议用qcow2格式它能支持快照和增量镜像功能# 上传 CentOS 7 ARM 镜像到 Glance openstack image create --disk-format qcow2 \ --container-format bare \ --public \ --file centos7-arm.qcow2 \ centos7-arm # 列出镜像确认可用 openstack image list逻辑说明--disk-format qcow2是镜像格式参数如果上传的是裸格式则需要改成 raw。--container-format bare表示镜像文件没有外部容器封装是 Glance 最常用的组合。参数说明ARM 和 x86 的镜像不能混用。鲲鹏服务器上传 x86 的 CentOS 镜像虚拟机创建后一定会以 firmware 错误或内核 panic 告终。所以镜像命名里我会加上arm或x86后缀避免多人协作时拿错镜像。另外如果镜像文件超过 10G上传过程容易超时可以设置 Glance 的allowed_direct_url托管方式让计算节点直接从镜像服务器拉取。6. 信创虚拟化避坑指南5 个最常见问题与排查思路6.1 VNC 控制台黑屏虚拟机无法启动现象用virsh start启动虚拟机成功但通过 VNC 连接控制台是黑屏或者卡在固件启动界面不动。原因ARM 架构下没有标准的 BIOS虚拟机的固件选择直接决定能否启动。默认固件如 UEFI 或 SeaBIOS如果与实际镜像不匹配就会卡死在固件初始化阶段。另一个常见原因是--os-variant没有指定正确值导致 libvirt 使用了错误的机器类型machine type。解决先检查虚拟机 XML 配置里的固件和机器类型virsh edit demo-vm1 # 检查 os 段 # 确保 firmware 为 uefimachine 类型为 virt 或 vexpressARM 虚拟机必须使用 UEFI 固件推荐virt机器类型同时确保--os-variant用了支持 ARM 的变体如centos7.0或rhel7.0。如果仍然黑屏把virsh start --console加上再看启动日志能定位是否卡在内核解压前。6.2 虚拟机网络不通ping 网关无响应现象虚拟机创建成功能开机但无法 ping 通同网段的其它机器从宿主机也 ping 不通虚拟机 IP。原因信创平台最常见的是网桥配置错误或 Neutron 的端口安全策略阻止了流量。Linux Bridge 模式下如果宿主机的物理网卡没有正确加入网桥虚拟机流量到网桥后就出不去了。另外 OpenStack 默认开风险端口安全会过滤所有非虚拟机来源的 MAC 地址。# 在宿主机上查看网桥状态 brctl show br-int # 查看网桥上是否有物理网卡 # 如果 Column 里没有 eth2说明绑定失败 ip link set eth2 master br-int解决优先确认物理网卡绑到网桥了再看端口安全——Neutron 端口默认开启了port_security_enabled True这会导致 DHCP 响应和组播协议被过滤。测试阶段直接关掉端口安全验证网络调通后再按需开启安全策略。6.3 虚拟机磁盘 IO 慢宿主机 load average 飙高现象虚拟机性能明显低于同等 x86 平台宿主机的 load average 异常飙升即使虚拟机空闲时也在高位。原因很多虚拟化层驱动没有正确安装。Windows 虚拟机没装 virtio 驱动磁盘回退到模拟 IDE 模式IO 性能只有 virtio 的十分之一同时宿主机 CPU 要模拟 IDE 控制器导致宿主机 load 升高。ARM 平台上这个差距更明显。# 在虚拟机内确认磁盘驱动 lsblk -d -o NAME,TRAN # TRAN 如果为 sata 或 ide说明 virtio 驱动没有安装 # 安装 virtio 驱动后重新启动解决Windows 虚拟机迁移前务必安装 virtio-win 驱动包括网卡和磁盘控制器驱动。Linux 虚拟机确认内核里是否编译CONFIG_VIRTIO_BLK和CONFIG_VIRTIO_NET。驱动装完后再重新配置虚拟机的磁盘控制器为virtio-scsi或virtio-blk。我在迁移项目里踩过这个坑当时一业务虚拟机是 Windows Server 2016迁移后 IO 性能下降七成最后发现是磁盘控制器没切换。6.4 Ceph 集群网络拥堵导致虚拟机卡顿现象多台虚拟机同时做大量 IO 时整个集群响应变慢甚至出现虚拟机 CPU steal 飙升。原因Ceph 的底层 IO 走存储网络存储网和业务网共用物理链路后业务流量和存储复制流量互相争抢带宽。CRUSH map 或 PG 数量配置不合理也会导致 IO 不均匀分布。解决网络层面必须确保存储网独立且存储网交换机不配置流控或限速。Ceph 的性能调优参数在信创 ARM 平台上需要关注osd_pool_default_pg_num和osd_max_backfills# 调整存储池的 PG 数量按 OSD 数平方除以副本数估算 ceph osd pool set volumes pg_num 512 ceph osd pool set volumes pgp_num 512PG 数量估算方法总 PG 数约等于OSD 数 × 100除以副本数。512 个 PG 只适用中小规模集群规模大时需要具体计算避免 PG 过多导致内存占用过高或启动慢。6.5 信创平台迁移后 Windows 虚拟机无法激活或蓝屏现象从 VMware 迁移到 KVM 后Windows 虚拟机能启动但提示激活失效部分虚拟机直接蓝屏。原因蓝屏通常是硬盘控制器驱动不兼容所致。激活失效是硬件抽象层HAL信息变化产生的正常现象——VMware 的虚拟芯片组和 KVM 的不一样只要迁移就会变化大概率触发微软激活机制。解决蓝屏问题用 virtio 驱动解决迁移前注入驱动。激活问题没有取巧路径需要在迁移前和业务供应商确认原授权是否支持迁移通常 Windows Server 的批量授权包含一定次数的重新激活。另有一个经验迁移后先在 VNC 控制台观察启动情况确认 Windows 能完整进入桌面后再接入网络避免激活验证在不稳定环境下触发锁定策略。7. 从单机到集群的进阶验证HA 与数据备份的一次实操走到了集群这一步还需要验证高可用和备份恢复能力。一个很重要的操作是模拟宿主机故障观察虚拟机能否自动漂移到其它节点。很多信创项目交付验收时才发现业务数据没有完整备份机制做一次故障演练就发现恢复流程根本没写。# 模拟计算节点故障在另一节点执行 openstack host set --disable --maintenance compute-arm-1 # 检查虚拟机是否自动迁移到其它计算节点 openstack server list --host compute-arm-2 # 恢复节点 openstack host set --enable compute-arm-1逻辑说明Nova 的 VM 高可用依赖一个前提计算节点被判定为故障后控制节点需要看到虚拟机实例处于错误状态并触发 evacuation。如果只是--disable不会自动迁移只会在下次调度时避开该节点。生产环境建议部署 Nova 的compute_ha服务或依赖外部 HA 工具做节点健康检查。数据备份这块我会在交付清单里明确三层备份策略第一层数据库层面的定时 mysqldump第二层镜像和卷存储层面用快照第三层整机备份用离线导出 qcow2 文件。恢复演练至少每季度做一次演练过程要记录恢复耗时不能只备份不验证。最后一个习惯每次做完这类方案我都会把架构图、IP 规划、迁移步骤、回退方案整理成运维手册。原因很简单虚拟化平台出问题时现场的运维人员往往不是搭建团队手册能让他们在故障时不靠猜。这套信创虚拟化及云平台方案最关键的检验标准不是功能演示多漂亮而是故障演练时系统能不能自己爬起来。希望这篇笔记帮你把迁移路上的坑提前填平。本文还有配套的精品资源点击获取