简介一份关于信创虚拟化及云平台解决方案的54页PPT面向政企信息化负责人、运维工程师与方案架构师聚焦国产化替代中性能弱、迁移难、生态差等痛点给出以虚拟化云计算技术为核心的应对思路。内容系统梳理信创建设面临的挑战讲解信创云整体解决方案、虚拟化产品与成果案例并对比龙芯、飞腾、鲲鹏、海光、兆芯、申威等芯片技术路线分析虚拟化选型要点和中小型到行业级的分级建设路径还涉及业务高可用、多技术路线统一管理、应用平滑迁移等落地目标以及稳定性、性能、功能等方面的选型验证方法。资源为单个PPTX文件大小约4.5MB共五十四页。目前已有66人学习适合正在推进信创改造或希望快速理清云平台架构的读者参考。1. 信创虚拟化与云平台先弄明白这份方案PPT值钱在哪“信创虚拟化”和“云平台”这两个词在刚入行的同事嘴里是概念到了交付现场就是一连串必须拍板的决策用哪家CPU、装什么系统、虚拟化层选KVM还是VMware、云管平台要不要叠OpenStack、存量虚机怎么搬过去不翻车。这份54页的信创虚拟化及云平台解决方案PPT不是给你解释概念的它把信创招标、POC和交付阶段那些最容易被质疑的点——技术路线、架构分层、资源池规划、迁移路径、安全合规——按方案文档的套路排成了可以直接改用的素材。适合正在做信创适配的交付工程师、投标的售前以及被云平台报错折腾的运维负责人。2. 虚拟化选型与信创适配为什么大概率得走KVM这条路线2.1 信创不是把厂商名字换一遍就算完成聊信创虚拟化的第一个认知问题就是很多人把“信创”理解成“国产化替代”认为选型等于把VMware换成KVM把CentOS换成openEuler就完事。真实项目里远没这么简单。评审会看的是三件事方案里的产品能不能进信创目录、能不能在目标硬件上跑起来、出了问题有没有人接得住。一份解决方案里最常见的“信创目录产品名单”不是给你当陈列架看的它是合规边界。CPU通常要从鲲鹏、飞腾、海光、龙芯这几家里选操作系统要从麒麟、统信、openEuler里选虚拟化层必须能同时踩住这两层。我一般会先画一个“CPU-操作系统-虚拟化”三角表格把每类硬件的兼容型号列进去再往下谈架构。这样做的好处是万一现场突然换了一台飞腾服务器至少方案里已经预留了对应驱动和镜像的坑位。另外要留意信创目录在不同行业、不同省份会有差异。做金融的和做能源的采购目录不完全一样不能拿一张通用PPT到处套。正确做法是把目录清单当成校验文件方案定了之后逐一比对缺哪个就补哪个的适配证明材料。否则答辩时被问一句“你这台存储不在目录名单里怎么解释”整份方案的可信度会掉一截。2.2 服务器虚拟化三件套KVM是底座QEMU是执行引擎libvirt是管理接口服务器虚拟化的选型是信创方案里最容易被问“为什么”的部分。VMware在存量x86机房确实好用但到了信创目录场景授权、适配和名单都不占优势。实践里最主流的选择还是KVM因为它直接作为Linux内核模块存在openEuler、麒麟、统信这些系统默认就带。有人把KVM、QEMU、libvirt混成一个概念实际分工很明确。KVM负责提供CPU和内存的虚拟化能力让内核变成HypervisorQEMU负责模拟磁盘、网卡、串口这些设备libvirt是统一管理接口virsh、virt-manager、OpenStack的nova-compute最后都通过它去跟KVM和QEMU对话。做性能调优时经常看到有人只调KVM参数忽略了QEMU的I/O模拟结果磁盘吞吐上不去白折腾半天。选型虚拟化类型信创适配性迁移成本适合场景VMware ESXi裸机虚拟化一般依赖x86与商业授权高存量x86机房、非信创业务KVM libvirt内核虚拟化高原生支持x86和ARM中信创云底座、私有云、云平台POC容器 Docker操作系统虚拟化高但隔离边界弱低云原生PaaS、微服务、无状服务这张表我每次都会放在PPT选型页旁边目的是给评审查清“不是不能用VMware而是信创目录里的典型场景优先考虑KVM”。如果现场有人问“容器能不能完全替代虚拟化”回答要克制。容器共享宿主内核隔离边界比KVM弱拿它跑数据库、特殊内核模块或要求内核参数隔离的业务翻车概率会明显变大。2.3 云平台分层OpenStack不要再背“底层报错”的锅有了KVM底座接下来才轮到云平台。很多PPT把OpenStack、Kubernetes、虚拟化管理平台全画在同一张架构图上其实层级完全不同。我一般把方案拆成三层。最底层是计算、存储、网络组成的物理资源池中间是虚拟化层的KVM/QEMU再往上才是云管理平台负责租户、镜像、调度、计费这些事。OpenStack属于云管理平台里偏IaaS的实现它通过nova-compute调用libvirt驱动去操作KVM。PaaS层的容器平台可以跑在虚拟机上面也可以直接跑物理机。很多人一看到虚机起不来就怀疑OpenStack控制面实际上应该先查宿主机KVM模块是否加载、libvirtd是否活着。有个典型报错叫“此平台不支持虚拟化的amd-v/rvi”看起来像没开BIOS开关实际常见于两层虚拟化叠加时配置不对。宿主机没把CPU的虚拟化标志透传给虚机虚机里再套一层KVM就会报这个错跟OpenStack没有任何关系。如果不理解这层边界排障时很容易在控制面的日志里浪费时间。2.4 54页PPT的阅读路径拿到手先翻这四个模块如果你拿这份资源去投标或做方案我建议不要从第一页顺序翻到最后一页。第一遍先看目录和技术架构页判断这套方案讲的是纯虚拟化还是带云管理平台第二遍找虚拟化选型和资源池规划页这是评委会追问最深的部分第三遍看迁移方案和安全合规页它们是信创项目里耗时最长的环节。PPT模块在项目里怎么用背景与政策投标文件里的信创背景和必要性叙述技术路线选型答辩时解释为什么选KVM附对比数据资源池规划POC阶段的硬件清单和CPU/内存配比参考迁移方案实施排期、回退计划、兼容性风险说明安全合规等保评测、信创安全工程师投标支撑材料实际动手改方案时我习惯把它当作“引子”不要原样照抄。一份54页的通用方案落到具体客户往往要砍掉一半再加上客户环境里的硬件型号、网络分区、安全基线要求。把通用素材和自己POC产出的截图、命令、配置块拼在一起才是答辩现场最有底气的东西。3. 把架构落到环境上POC部署的完整操作路径3.1 环境准备网络分区、硬件配额和操作系统版本PPT里的架构图画得再漂亮落地时先看物理环境。做信创虚拟化POC我最大概率使用的组合是两台鲲鹏或飞腾服务器再加一台管理部署机操作系统选openEuler 22.03 LTS。内存建议每台64GB起步存储至少两块盘一块装系统一块给虚拟机镜像。网络要提前分三个平面管理网络、业务网络、存储网络。很多POC只拉一根网线后面做VXLAN、做迁移时就开始翻车因为存储网络和业务网络混在一起带宽和延迟全部受影响。下面这套参数可以当成默认起点参数建议值CPU2路鲲鹏920或飞腾S2500BIOS开启相关虚拟化能力内存64GB/节点预留NUMA配比系统盘1 x 960GB SSD数据盘1 x 3.84TB NVMe建议独立存储网络管理网独立VLANMTU 1500存储网络独立VLAN或物理隔离MTU 9000环境到位后先确认KVM能力不要等到创建虚机时才报错。在openEuler上检查# 检查KVM设备节点是否存在 ls -l /dev/kvm # 手动加载KVM模块 modprobe kvm # 查看模块是否已经挂载 lsmod | grep kvm逻辑说明/dev/kvm是宿主内核暴露给QEMU的接口它存在说明KVM模块已经工作。如果连这个节点都没有后面安装libvirt和OpenStack都会报“不支持虚拟化”。参数说明在ARM架构的鲲鹏环境里没有Intel VT-x或AMD-V开关重点确认内核是否编译进KVM模块以及/dev/kvm权限是否被qemu进程访问。3.2 安装虚拟化底座libvirt-daemon-kvm的最小化部署虚拟化底座这里我建议直接用发行版自带的libvirt不要自己编译QEMU。信创环境里每省一次编译时间就少一个适配兼容的坑。openEuler下安装命令如下# 安装KVM、libvirt守护进程和virt-install命令行工具 yum install -y qemu-kvm libvirt-daemon-kvm virt-install # 启动libvirtd并设置开机自启 systemctl enable --now libvirtd # 查看libvirt和QEMU版本 virsh version逻辑说明libvirt-daemon-kvm是openEuler里专门打包KVM能力的守护进程装完后libvirtd通过qemu-kvm进程创建虚拟机。virsh version输出会同时显示libvirt和QEMU两个版本号如果只显示libvirt不显示QEMU说明qemu没装全。参数说明virt-install是创建虚机时用到的命令行工具虽然libvirt本身不带它但POC阶段少了它每一步都别扭建议一起装。装完还要想清楚网络怎么建。默认的libvirt网络是NAT模式物理机重启后IP地址会变化不适合POC阶段固定拓扑。我这里会创建一个Linux Bridge让虚拟机直接并入管理网络。# 通过nmcli创建桥接设备br0并绑定物理网卡 nmcli con add type bridge ifname br0 con-name br0 nmcli con add type bridge-slave ifname ens3f0 master br0 nmcli con up br0 # 定义libvirt的bridge网络 cat /tmp/host-bridge.xml EOF network namehost-bridge/name forward modebridge/ bridge namebr0/ /network EOF virsh net-define /tmp/host-bridge.xml virsh net-start host-bridge virsh net-autostart host-bridge逻辑说明先建好物理层面的br0再让libvirt网络去引用它顺序不能反。如果物理网卡没加入桥接虚机即使配了IP也出不了网。参数说明ens3f0是我测试机上的网卡名实际环境以nmcli device status输出为准。forward modebridge表示直接把虚机流量交给Linux Bridge处理不经过NAT这样租户虚机可以获得与物理机同网段地址。3.3 存储池与镜像准备先准备qcow2不要临时找镜像创建虚机之前必须先把存储池和镜像准备好。libvirt默认存储池是/var/lib/libvirt/images但POC阶段我经常单独建一个存储目录方便后面做快照和迁移测试# 创建存储池目录并定义到libvirt mkdir -p /data/kvm-images virsh pool-define-as kvm-images dir --target /data/kvm-images virsh pool-start kvm-images virsh pool-autostart kvm-images # 查看存储池信息 virsh pool-list virsh vol-list kvm-images逻辑说明pool-define-as告诉libvirt有一个存储池存在但不会主动建目录所以要先mkdir。pool-autostart保证重启后存储池自动激活。参数说明路径可以按业务调整但尽量别放在系统盘上否则虚机一多系统盘很快就满。另外一个细节是思路要从“临时下一张镜像”改成“用做好的模板镜像复制”这样后续批量创建快速且稳定。3.4 创建第一台信创虚拟机从virt-install到启动验证环境都准备好后创建虚机就是一线操作。以ARM64架构的openEuler为例# 创建一台2核4G、磁盘20G的ARM64虚拟机 virt-install \ --name vm-test01 \ --memory 4096 \ --vcpus 2 \ --disk path/data/kvm-images/vm-test01.qcow2,size20,formatqcow2 \ --os-variant openeuler-unknown \ --network networkhost-bridge \ --cdrom /data/iso/openEuler-22.03-aarch64.iso \ --graphics vnc,listen0.0.0.0 \ --noautoconsole逻辑说明virt-install把命令行参数转换成libvirt XML再交给qemu-kvm执行。--memory 4096表示4096MB--vcpus 2表示两个vCPU--os-variant决定默认的设备类型和驱动如果libvirt没有对应openEuler变体用openeuler-unknown兜底。参数说明--graphics vnc,listen0.0.0.0只适合POC远程安装生产环境务必绑管理网IP否则任意主机都能连VNC安全基线必查这一项。启动后紧接着验证状态virsh list --all # 支取虚拟机IP地址做连通性测试 virsh domifaddr vm-test01逻辑说明virsh list --all会列出所有虚机状态是running还是shut off一眼就知道。domifaddr能拿到虚机接口IP前提是虚机内部已经配置了网络。如果这里拿不到地址先检查是不是没装cloud-init或网卡没启用DHCP。3.5 云平台控制面POC阶段不要一上来就铺OpenStack底层虚拟化通了之后会遇到一个选择到底要不要上OpenStack。如果只是给几台虚机做手动生命周期管理libvirt就够用但客户要“云平台”通常意味着要有多租户、自服务、镜像服务、计量计费这些能力这时候才轮到OpenStack。POC阶段最省事的做法是PackStack的一体机部署在管理节点执行# 部署all-in-one OpenStack省略Swift、Heat、Ceilometer packstack --allinone \ --os-swift-installn \ --os-heat-installn \ --os-ceilometer-installn逻辑说明--allinone把控制面和计算面装到同一台机器上适合低于10个节点的验证环境。关闭Swift是因为对象存储在POC里很少用关闭Heat和Ceilometer是为了减少服务数量和部署失败点。参数说明如果测试环境还有别的计算节点想加入不要直接跑allinone而是先用packstack --gen-answer-file生成配置文件再修改CONFIG_COMPUTE_HOSTS的地址列表然后带着配置文件执行。这里我要多说一句OpenStack部署跑完后第一件事不是登录网页而是等日志完全结束。PackStack跑完一般会输出一行以****开头的成功提示没看到它之前页面能开也是半残状态。很多人图快日志还没结束就去创建云主机结果一路报错。4. 信创迁移与兼容性适配五个高频踩坑记录与排查方法4.1 坑一从VMware迁到KVM后虚拟机蓝屏或卡在引导现象存量VMware里的Windows虚拟机用qemu-img convert导出成qcow2后放到KVM上启动直接蓝屏或者卡在Windows Logo。原因Windows安装时自带的是VMware的pvscsi磁盘控制器和Intel e1000网卡驱动KVM默认给虚机提供的是virtio块设备Windows没有对应驱动引导阶段找不到系统盘。解决迁移之前先在VMware虚机里安装virtio驱动镜像让Windows把virtio驱动装入系统转换后启动时按F8进入安全模式尝试修复驱动。如果是Linux虚机问题通常出在grub设备名变化需要进救援模式改grub.cfg。我每次迁移前都会先做客户端快照失败后能立即回滚这个动作一定别省。4.2 坑二KVM里套KVM时报“此平台不支持虚拟化的amd-v/rvi”现象宿主机已经开了KVM虚机也能正常运行但在虚机内部再装OpenStack或VMware Workstation时报“此平台不支持虚拟化的amd-v/rvi”或者VMware Workstation报“模块“hv”启动失败”。原因默认的libvirt CPU模型是qemu64或通用的custom模型没有把物理CPU的vmx/svm标志传给虚拟机虚机里看不到虚拟化能力自然没法再套一层。解决修改虚机XML里的CPU模式把host-passthrough用起来virsh edit vm-test01 # 找到 cpu 节点改成如下配置 # cpu modehost-passthrough checknone/然后在虚机里验证grep -Eo vmx|svm /proc/cpuinfo | sort -u逻辑说明host-passthrough会让QEMU把宿主CPU能力原样透传给虚机代价是热迁移时CPU兼容性变差。参数说明如果宿主机是ARM架构则要看/proc/cpuinfo里的KVM相关特性同样原理嵌套虚拟化必须逐层透传。4.3 坑三集群节点时间不同步云平台调度器开始发疯现象多个计算节点加入资源池后虚拟机创建速度忽快忽慢日志里频繁出现消息队列超时某个节点被标记为不可用重启服务后短暂恢复过一阵又复发。原因OpenStack组件之间靠消息队列和心跳维持状态各节点系统时间差超过一定范围后令牌失效、心跳超时调度器就会把节点踢出去。解决用chrony统一时间源指向公司内部NTP服务器不要用公网时间源。yum install -y chrony cat /etc/chrony.conf EOF server ntp.internal.example.com iburst local stratum 10 EOF systemctl enable --now chronyd chronyc tracking逻辑说明local stratum 10设置本地时钟级别适合没有外网环境的机房如果存在架构内跳变时间就以管理节点为主源。参数说明这一步每台物理机和每台虚机都要做尤其虚机重启后时间漂移会非常明显。4.4 坑四信创安全基线加固后OpenStack管理面直接不通现象交付现场执行完安全加固脚本控制节点的Horizon网页打不开Keystone、Nova的API端口无响应虚机却还活着。原因等保和信创安全基线的加固策略会把非白名单端口全部封掉而OpenStack内部服务之间用了大量高端口比如RabbitMQ的5672、Keystone的5000、Nova的8774。加固脚本不会自动识别这些端口。解决先别关防火墙按基线要求放行管理网内部网段再逐个验证服务端口# 放行管理网段对关键端口的访问 iptables -A INPUT -s 192.168.10.0/24 -p tcp -m multiport --dports 5000,5672,8774,8776,9292 -j ACCEPT # 验证端口连通性 curl -I http://controller:5000/v3/逻辑说明-s 192.168.10.0/24必须改成你自己的管理网段multiport一次放行多个端口。这个命令只是临时恢复正确流程是扫描服务实际监听端口整理成基线例外表再走配置变更。投标时“信创安全工程师”的支撑材料靠的就是这些记录。4.5 坑五ARM架构拿x86镜像硬跑启动变成玄学现象在鲲鹏或飞腾服务器上创建虚拟机镜像用的是网上随便下的qcow2启动日志里出现guest has not been initialized或者KVM内部报CPU不支持。原因镜像架构与宿主机架构不匹配。x86镜像在ARM平台的QEMU里会走纯软件模拟性能差还经常起不来反过来也一样。解决先查镜像架构再决定要不要用它qemu-img info /data/kvm-images/test.qcow2 # 输出里的architecture字段决定是否匹配 file /data/kvm-images/test.qcow2逻辑说明qemu-img info会显示镜像的虚拟磁盘大小、格式信息部分镜像会直接标明架构。经验是ARM环境从一开始就下载openEuler aarch64或麒麟ARM官方镜像不要拿x86镜像折腾。如果只有x86镜像短时间验证可以用qemu-system-aarch64配合-cpu host和machine virt试试但生产环境不建议数据库这类高负载应用会慢到怀疑人生。5. 把这份54页PPT用起来的两个技巧验证清单与方案应答5.1 三分钟快速验证硬件和虚拟化状态的清单交付验收和POC结束前我都会按固定顺序跑几组命令确保不是在PPT上看起来很完美、实际环境一碰就碎。建议把下面这张表打印出来贴到工位上检查项命令预期结果KVM设备节点ls -l /dev/kvm设备文件存在且有权限libvirt版本virsh version同时显示libvirt和QEMU版本CPU虚拟化透传grep -Eo vmx|svm /proc/cpuinfo有对应标记输出存储池状态virsh pool-list存储池actived且路径正确虚机启动状态virsh list --all期望运行的虚机都是running这套清单的价值不在于命令本身而在于顺序。先确认物理能力再看虚拟化层最后才看云平台可以避免在OpenStack页面里浪费一整天排查底层问题。5.2 投标和汇报时的素材组织套路到了答辩或者汇报场合不要把这54页从头到尾播一遍评审没时间听概念。我一般只挑两样东西讲技术路线为什么是KVM以及POC阶段实际跑出来的验证结果。前者用PPT里的选型对比表后者用自己环境里生成的日志、测试截图和命令输出。把这份解决方案PPT当成框架把你自己做实操产生的数据填进去。比如第3章里的virsh version输出、第4章的排障记录、第5章的验证清单都可以变成投标文件里的“实测结论”。这么做的好处是哪怕被问到细节你也不会心虚因为你真跑过。从那以后我每做一个信创虚拟化项目都强制自己先把/dev/kvm、virsh version、网络桥这三样底层排一遍再去看上面那些点不开的按钮。希望帮到你。本文还有配套的精品资源点击获取