简介围绕信创虚拟化及云平台建设这份PPT系统梳理了从现状评估到落地分级的完整解决方案适合承担国产化替代任务的IT架构师、运维工程师与云平台规划人员参考。内容先分析信创建设面临的多芯片路线、生态差、迁移难、性能弱等挑战随后依次介绍服务器虚拟化、云平台、云管理平台、容器云平台等产品线并覆盖替代VMware vSphere场景、软件定义基础架构、多云融合架构三类典型应用场景以及小型、大型、超大型、行业/区域集中型用户的差异化建设路径。方案还给出基础级、企业级、增强级、行业级信创云的分级建设思路强调应用平滑迁移、存储网络利旧、企业级能力保障业务连续性等客户价值。包内为1个pptx演示文档压缩包大小约3.09MB结构集中、便于直接阅读已有984人学习。借助其中的信创芯片特性对比、虚拟化选型要点与场景化部署框架可快速形成适合本单位现状的信创云实施主线。1. 信创虚拟化及云平台解决方案先想清楚是换Hypervisor还是换整个云管平台信创虚拟化及云平台解决方案听起来像是把VMware替换成国产虚拟化软件实际做过的都知道真正的成本不在Hypervisor本身而在CPU路线、操作系统适配、迁移工具链和云管平台这四层。很多单位第一反应是“把vCenter换成某国产虚拟化”结果发现底层CPU从x86换到ARM之后业务镜像、数据库、中间件全要重新适配。这篇文章我从选型、搭建、避坑到验证把一套能落地的信创虚拟化及云平台方案拆给你看适合正在做信创替代的运维工程师、方案售前和项目经理。2. 信创虚拟化选型CPU路线、Hypervisor与信创目录的三角关系先别急着装软件。在信创项目里虚拟化选型第一步是看CPU。目前信创服务器CPU主要是海光、鲲鹏、飞腾三条路线。海光是x86架构兼容性最好虚拟化指令走AMD-V现有基于VMware或KVM的x86镜像基本不用改鲲鹏和飞腾是ARM架构能跑Linux和部分国产OS但Windows、老版本中间件、商业数据库都很难直接迁移。所以选型第一个问题现有业务是自研还是商业软件如果业务全是自研Java/Go服务ARM路线可以接受如果有Oracle或老ERP老老实实选海光或兼容层方案。2.1 三种信创CPU路线海光、鲲鹏、飞腾对虚拟化的影响海光CPU目前常见的是Dhyana系列指令集兼容x86支持AMD-V和SVM所以在它上面跑KVM、libvirt、OpenStack和普通x86服务器几乎没有差别。好处是迁移路径短坏处是信创“纯度”审查时可能需要解释为什么选x86。鲲鹏对应的是华为生态适配openEuler、麒麟等系统虚拟化用KVM的ARM版本支持硬件虚拟化扩展。飞腾一般是FT-2000和S2500系列常见于终端虚拟化平台比如麒麟天逸终端虚拟化平台这类方案服务器场景也有但不如鲲鹏生态全。在项目里我一般给客户这样的建议虚拟化平台和云管平台优先考虑支持异构CPU的方案不要在单一ARM锁死。因为信创目录产品名单虽然给出了入围型号但实际项目里经常出现“第一批采购了鲲鹏第二批飞腾”的情况Hypervisor如果不支持异构调度后期运维会变成灾难。还有一个细节容易被忽略ARM架构的服务器虚拟化里KVM的vCPU默认模拟的是ARM虚拟CPU某些需要AVX指令集的应用会报非法指令这一点要在测试阶段就确认不能等上线再翻车。路线架构虚拟化扩展迁移难度适用场景海光x86AMD-V/SVM低Oracle、老ERP、Windows鲲鹏ARMARM Virtualization中自研云原生、大数据飞腾ARMARM Virtualization中高终端虚拟化、政务内网2.2 Hypervisor选型KVM是默认答案但发行版才是真正风险点信创虚拟化底层Hypervisor绝大多数方案默认是Linux内核自带KVM。它本身就是内核模块和openEuler、麒麟等信创OS天然兼容。对比XenKVM的设备直通、热迁移、嵌套虚拟化支持都更完整。VMware和Hyper-V虽然成熟但一个是闭源商业授权一个和信创目录有距离基本不在讨论范围。这里有个常见误区很多人把“虚拟化平台”等同于“云平台”其实KVM只是底层上面还要有virsh/libvirt、集群管理、云管平台三层。风险点在哪里在发行版。KVM通常由libvirt管理不同信创OS带的libvirt版本差异很大有的带的是libvirt-daemon-kvm有的是老版本libvirt 5.x有的厂商虚拟化平台直接改写了virsh命令。所以选型时不要只看“支持KVM”要看具体的组件版本和API兼容性。例如openEuler 2203 SP2上的libvirt-daemon-kvm和CentOS 7上的libvirt就有差异迁移脚本可能跑不通。我遇到过一次客户现场自带的云平台脚本里调用了virsh migrate --live但厂商版libvirt把参数改成了--migrate-live整个迁移流程卡了两周。2.3 信创目录产品名单不是采购清单是兼容性边界很多人把“信创目录产品名单”当成采购清单其实它是投标门槛不是兼容性保证。名单里的虚拟化平台可能只验证了特定CPU和OS组合例如“麒麟鲲鹏”“UOS飞腾”。如果你拿着名单直接套到海光openEuler环境可能连安装包都跑不起来。我一般会先拿测试环境跑一遍“CPUOSHypervisor云管平台”四件套的兼容性矩阵再决定投标时写哪个型号。最近几年信创适配及安全管理赛项、信创安全工程师投标这些需求背后本质是同一个问题信创不是单点替换是整链路适配。虚拟化和云平台只是中间层上面还有数据库、中间件、应用下面还有CPU和固件任何一层不匹配方案都交付不了。所以选型阶段一定要花时间把兼容性矩阵建好后面能省掉大量排错时间。2.4 从VMware迁移到信创KVM的四个改造点老环境大部分是VMware迁移到信创KVM不是把ovf导入就算完至少要改造四个地方。第一虚拟磁盘格式。VMware的vmdk不能直接被KVM用需要转换成qcow2或raw。转换命令是qemu-img convert -f vmdk -O qcow2 vmdisk.vmdk vmdisk.qcow2但转换后链路最好在测试环境先启动验证因为vmdk里的设备驱动可能不兼容。第二网卡类型。VMware虚拟机默认是vmxnet3KVM上需要改成virtio-net。在系统能启动的前提下先加载virtio驱动再改设备否则重启后直接断网。第三CPU模式。VMware迁移到KVM后虚拟机CPU默认可能是qemu64性能损失很大。要修改domain XML里的CPU mode建议用host-model或手动指定CPU型号。第四操作系统激活和时钟。Windows虚机迁移后要重激活Linux虚机要检查chrony/ntpARM信创环境里没有VMware的tools需要装对应的qemu-guest-agent否则优雅关机和IP获取都是问题。3. 用libvirt-daemon-kvm在openEuler上跑通最小信创云平台选型定了之后很多刚接触信创虚拟化的工程师会直接去装商业云平台结果装完发现底层命令都不会用。我的习惯是先在单机或一台物理机上用libvirt-daemon-kvm把KVM跑通把镜像、网络、CPU模式这些基本功练扎实再去套云管平台。这套流程也是信创适配及安全管理赛项的标准操作能让你在排查问题时不用靠猜。3.1 最小化环境规划三台物理机还是单机嵌套常见做法是准备三台物理机两台做计算节点一台做存储和控制节点。如果资源紧张在一台x86或ARM服务器上做完整个实验也够但要注意CPU必须支持硬件虚拟化BIOS里SVM/VMX要打开。验证是否支持用grep -E svm|vmx /proc/cpuinfo如果输出为svm表示AMD平台海光vmx表示Intel。如果这里没有输出后面启动虚拟机大概率报“此平台不支持虚拟化”的错误。另外还要确认已加载kvm模块lsmod | grep kvm逻辑说明grep指令只是看CPU特性模块没加载时即使CPU支持也起不来。信创ARM平台上模块名是kvm驱动是kvm_guest不会出现kvm_intel/kvm_amd。我见过有人在鲲鹏服务器上到处找kvm_intel模块最后发现架构不同白白耽误半天。3.2 安装libvirt-daemon-kvm与虚拟化内核模块在openEuler上安装命令如下yum install -y qemu-kvm libvirt-daemon-kvm virt-install systemctl enable --now libvirtd virsh version逻辑说明qemu-kvm提供QEMU用户态设备模拟libvirt-daemon-kvm提供virt管理守护进程virt-install是命令行创建虚拟机的工具。安装完成后virsh version会同时打印libvirt和QEMU版本如果libvirt版本低于6.0部分OpenStack网络插件会不兼容。另外建议执行modprobe kvm确认内核模块加载正常如果提示Key was revoked by service或权限不足先查Secure Boot和内核签名这是信创Arm服务器上常见的坑和软件包本身没关系。3.3 创建第一台虚拟机CPU、内存与磁盘参数用virt-install创建虚拟机是信创虚拟化最常用的方式。我这里给一个最小化的麒麟系统安装命令virt-install \ --name kylin-vm1 \ --vcpus 4 \ --memory 8192 \ --cpu host-passthrough \ --disk path/data/vms/kylin-vm1.qcow2,size50,formatqcow2 \ --network networkdefault \ --os-variant detecton \ --cdrom /iso/Kylin-Server-10.iso参数说明--cpu host-passthrough让虚拟机直接继承宿主机CPU特性避免迁移时CPU指令集不一致。--disk设置为qcow2格式支持快照和稀疏分配size50表示磁盘最大50GB但实际只占用到多少就分配多少。--network networkdefault使用libvirt自带的NAT网络。信创环境创建ARM虚拟机时--os-variant要指定为对应的aarch64版本比如--os-variant centos-stream8或--os-variant ubuntu20.04否则操作系统类型检测失败安装时会卡在登录界面之前。安装完后建议马上做一次快照virsh snapshot-create-as kylin-vm1 base-ok --disk-only --atomic快照是后悔药。我在信创项目里见过太多人装完系统不拍照后面调错参数改不回来只能重装浪费时间不说还容易把现场环境搞乱。3.4 网络配置NAT、桥接与多网卡绑定单机实验用NAT就够了生产环境必须用桥接。桥接在openEuler上的常见做法是用nmcli创建Linux桥nmcli connection add type bridge ifname br0 con-name br0 ipv4.addresses 192.168.10.10/24 nmcli connection add type bridge-slave ifname eth0 master br0 nmcli connection up br0逻辑说明先创建bridge连接把物理网卡eth0作为桥接子接口挂进去最后启用桥。注意执行后远程连接会断必须从控制台操作。桥接后虚拟机网络要使用--network bridgebr0访问物理网络。信创环境经常遇到多网卡建议先做bonding再挂bridge不要直接在多个物理口上分别建bridge否则虚拟机漂移时网卡MAC会混乱。用nmcli做bonding的常用做法是nmcli connection add type bond ifname bond0 con-name bond0 mode active-backup miimon 100 nmcli connection add type ethernet ifname eth1 con-name eth1 master bond0 nmcli connection add type ethernet ifname eth2 con-name eth2 master bond0 nmcli connection add type bridge ifname br0 con-name br0 master bond0这段命令里mode active-backup是主备模式生产环境建议用802.3ad来跑双活但需要交换机配合。如果交换机不支持LACP就老实做主备不要为了性能强行双活否则会丢包丢到怀疑人生。3.5 模板与快照管理让虚拟化平台达到可用状态KVM里模板的核心是cloud-init镜像。信创环境常见做法是先用virt-install装一个基础麒麟系统然后删除MAC地址和SSH host key做成模板virt-sysprep -d kylin-vm1 virsh undefine kylin-vm1说明virt-sysprep会清理网络身份、SSH密钥、主机名让镜像可以重复克隆。如果后续接OpenStack还需要给镜像装cloud-init和qemu-guest-agentyum install -y cloud-init qemu-guest-agent systemctl enable --now qemu-guest-agent这两个包如果不装云平台上虚机开机后拿不到IP密码重置和监控也全废。很多信创虚拟化项目交付时“表面功能都有”但虚机管理界面一直显示“未知状态”基本都是缺了qemu-guest-agent。4. 从单机KVM到云平台OpenStack还是商业信创云发行版单机KVM解决了“能不能跑”的问题但生产上的信创虚拟化及云平台解决方案要解决的是“能不能自助交付、能不能横向扩容、能不能统一监控”。所以需要云管层。现在国内市场大致两类一类是OpenStack开源分支或基于OpenStack的商业发行版一类是自研云管平台典型是厂商以KVM为基础加一层调度和IAM。这两类我都部署过先给结论如果团队有Python运维能力选OpenStack可控如果团队只有三四个工程师直接选商业信创云发行版更稳。4.1 基于KVM的云平台与单机虚拟化的本质差别单机libvirt管理的虚拟机生命周期是“创建—启动—关闭”没有租户、配额、网络隔离。云平台至少要提供多租户、资源配额、统一镜像、软件定义网络四件事。以OpenStack为例keystone管认证、nova管计算、neutron管网络、cinder管块存储、glance管镜像、horizon管界面。信创环境里每个组件都有适配点比如glance需要提前准备好ARM和x86两套云镜像nova-compute需要配置底层的libvirt连接方式。这里最容易被低估的是网络。OpenStack的neutron在信创环境里往往跑VXLAN或OVS而信创交换机有些型号对VXLAN封装报文的MTU支持不好。我遇到过一个现场虚拟机跨节点通信丢包率5%最后发现是underlay MTU设成了1500内层VXLAN包被丢弃。解决办法是全网MTU调成1600这个不在OpenStack默认配置里必须手动改。4.2 OpenStack核心组件与Kolla-Ansible部署路径生产环境别手动一个个装组件。我一般用Kolla-Ansible把OpenStack所有服务容器化通过ansible生成globals.yml、passwords.yml然后执行kolla-ansible deploy。对信创环境最关键的是镜像仓库提前替换成国内可用源并确认容器镜像是否带ARM版本。命令如下pip3 install kolla-ansible cp -r /usr/share/kolla-ansible/etc/kolla /etc/kolla/ kolla-genpwd vi /etc/kolla/globals.yml kolla-ansible -i multinode bootstrap-servers kolla-ansible -i multinode prechecks kolla-ansible -i multinode deploy逻辑说明globals.yml里必须设置openstack_release和base镜像。信创场景如果是在鲲鹏ARM上部署优先找官方标记为aarch64的镜像如果直接用x86镜像容器会启动失败。prechecks会检查磁盘空间、系统版本、网络时间同步信创环境最容易卡在chrony或ntp未配置。这里我要多说一句很多团队为了让部署“看起来很自动化”直接把prechecks输出忽略掉结果后面排错更难所以prechecks的每一项都要认真看。4.3 信创场景下的数据库、中间件与K8s联动适配OpenStack自身需要数据库和消息队列。常见做法是MariaDB和RabbitMQ作为内部组件容器化运行。但有些信创用户要求核心数据库用达梦、人大金仓这类国产库这会引入额外适配成本——不是改个连接串就行OpenStack的数据库驱动需要对应的dialect实现。我的处理方式第一年先保留MariaDB把国产数据库用于业务层等云平台稳定后再做替换不要一上来就全栈信创。另外如果上层还要跑深度学习云平台或K8s需要确认cinder-csi插件和nova的placement服务支持当前架构否则虚机漂移后存储卷挂不上去。K8s和OpenStack集成时我一般用external cloud-provider而不是in-tree provider这样信创环境里的网络插件Calico、Cilium可以独立于OpenStack做持久化网络策略。4.4 商业信创云发行版和开源OpenStack的取舍很多采购方只看“信创目录产品名单”里有没有某个商业虚拟化软件却忽略了它在你的实际环境里是否已经被验证。商业发行版的优势是图形界面和一键运维劣势是版本锁死和升级困难。开源OpenStack的优劣势正好反过来。这里给一个参考如果业务规模在50台物理机以内商业信创云发行版更划算如果超过100台建议认真评估OpenStack因为商业平台按CPU授权收费规模一大费用会失控。还有一类“自研”信创云平台是套了OpenStack内核但改了名字的这类反而要注意厂商可能只改了界面底层版本很老漏洞没人维护。投标时问清楚“核心组件开源版本号是什么、trunk分支还是stable分支、最近的CVE补丁能追溯到哪个commit”如果回答不上来建议直接淘汰。5. 信创虚拟化及云平台落地避坑5条高频故障与排查记录这部分是血泪经验。以下每一条我都踩过按“现象—原因—解决”写。5.1 嵌套虚拟化报错“此平台不支持虚拟化的AMD-V/RVI”现象在虚拟机里尝试装KVM虚拟化时开机遇到提示“此平台不支持虚拟化的AMD-V/RVI”即便打开了CPU穿透虚拟机还是无法启动。原因是宿主机本来就是虚拟机没有开启嵌套虚拟化。VMware或Hyper-V默认不把虚拟化指令透传给孩子机。信创测试环境经常用虚拟机冒充物理机就会撞上这个报错。解决如果是VMware在虚拟机CPU设置里勾选“虚拟化Intel VT-x/EPT 或 AMD-V/RVI”如果是Hyper-V需要执行Set-VMProcessor -ExposeVirtualizationExtensions $true。但注意嵌套虚拟化性能损失很大只能用来验证命令流程别拿来压测。还有个坑openEuler作为嵌套宿主机时启动虚拟机可能报“KVM is not available”这时要确认外层虚拟机内核是否加载了kvm_amd模块而不是只看CPU标志位。5.2 桥接网络在openEuler上重启后失效现象nmcli创建的bridge当时能通重启后物理网卡没有挂入bridge虚拟机断网。原因是openEuler默认网络管理行为是NetworkManager但nmcli创建bridge时没把主网卡配置文件设为从属于bridge导致开机网卡自检时先启动了原来的有线连接。解决删除原有有线连接只保留bridge和slave连接并设置autoconnect yes。同时确认/etc/sysconfig/network-scripts/目录下没有历史ifcfg文件造成干扰。最好进入系统后执行systemctl restart NetworkManager用bridge link检查eth0是否在br0下。如果用的是systemd-networkd则要单独配置networkd的netdev和network文件两种方案不要混用一混用网络配置就成黑匣子。5.3 国产化ERP虚机频繁IO延迟抖动现象数据库虚机上跑着国产ERPIO延迟平时2ms高峰期冲到200ms业务超时。原因是云平台默认给了qcow2格式磁盘读写走QEMU用户态没有打开原生aio或io_uring。信创ARM平台上更明显因为virtio-blk驱动配置不对。解决把磁盘缓存模式设置为none并给libvirt的domain配置driver nameqemu typeqcow2 cachenone ionative/。如果是高性能数据库建议用LVM裸设备直通绕开qcow2格式的写放大问题。另外在多节点云平台里要确认存储后端是不是分布式存储如果是Ceph需要单独调Ceph的rbd cache参数虚拟化层调好也没用因为瓶颈在下层。5.4 云平台资源监控里的CPU使用率统计不准现象监控面板显示CPU使用率只有10%但业务已经很卡了。原因是信创服务器常见有超线程和多NUMA节点默认监控取的是物理CPU整体利用没拆到虚拟核和NUMA节点。ARM服务器更明显因为频率动态调节策略不同。解决在云平台下方采集数据时按host CPU和vcpu分开统计。部署virt-top配合virsh cpu-stats来比对不要只看平台自带的图表。在ARM平台上还要注意kworker的中断处理线程会占用某个vCPU导致单核100%但整机CPU很低这种现象工单里叫“发散调度”需要通过virsh vcpuinfo确认每个vCPU的物理绑定情况。5.5 升级内核后libvirt驱动不匹配现象openEuler用yum upgrade升级内核后virsh list --all正常但启动虚拟机报“cannot open drive”错误。原因是内核升级后kvm模块与QEMU用户态的接口版本变了libvirt没有自动重新加载驱动。解决重启宿主机确保kvm模块重新加载。如果还不行将libvirt-daemon和qemu-kvm升级到同组版本。生产环境做内核升级前先virsh dumpxml备份所有虚机配置并且规划停机窗口。还有一个常见连带问题升完内核后某国产云管平台的agent服务挂了因为它编译时依赖的内核符号表变了要一并重装agent。6. 交付前验证性能、高可用与迁移演练一次做完方案写完不是终点能交付才是。信创虚拟化及云平台解决方案在客户现场能不能验收主要看三件事。6.1 跑三组关键性能指标CPU、磁盘、网络先用UnixBench验证CPU用fio测随机读写的IOPS和延迟用iperf3跑内部网络带宽。ARM平台跑UnixBench时单核分数会和x86差不少别悲观重点对比同架构下的基线。unixbench fio --namerandwrite --rwrandwrite --bs4k --size2G --iodepth64 --direct1 iperf3 -c 10.0.0.2 -t 60fio参数里--direct1必须开不然走Page Cache测出来的是内存速度不是磁盘速度。信创平台常见问题是首轮IOPS能看持续半小时后开始掉一般是散热降频或Ceph队列深度不够至少要跑20分钟以上才能下结论。6.2 高可用演练模拟物理机宕机与虚拟机迁移至少做一次宕机演练手动拔掉一台计算节点的网线看控制节点是否会在几分钟内把漂移虚机拉起。如果用了KVM原生热迁移注意业务虚机发布时CPU模式不要用host-passthrough建议用custom模式限定最低指令集不然漂移到另一台不同型号CPU的主机会直接失败。演练时记录三个时间宕机检测时间、虚机重启时间、数据完整性检查时间。贴一个热迁移命令示例virsh migrate --live kylin-vm1 qemussh://rootnode2/system --unsafe--unsafe参数在生产环境不要加它会跳过安全校验但在测试环境可以快速验证迁移链路通不通。迁移前用virsh dumpxml kylin-vm1备份配置迁移后一定要在目标节点上virsh list确认虚拟机状态为running。我见过太多信创项目在验收前一周才想起做迁移测试结果发现镜像和网络模式不兼容最后只能延期。现在我的习惯是方案里所有功能都先在测试环境跑一遍并把命令记录成运维手册再交付。希望帮到你。本文还有配套的精品资源点击获取