简介：CNware虚拟化平台解决方案是一份聚焦企业级虚拟化与云计算规划的技术演示PPT，适合IT决策者、云平台架构师及运维管理人员阅读。内容以航天云宏自研云操作系统为基础，系统梳理了虚拟化引擎、虚拟化管理、云服务管理三个核心层次，并依次覆盖方案背景、产品配置、客户价值、方案优势与公司简介，结构清晰、逻辑完整。压缩包内共1个文件，为1.32MB的pptx演示文稿，页数精炼且信息密度较高，可直接用于内部评审或方案汇报。目前已有164人浏览学习。借助这份PPT，读者可以快速了解国产虚拟化平台在电信、金融、大型企业、政府等领域的典型落地场景，理解从底层资源虚拟化到上层云服务运营的整体解决思路，也可用于对标自身虚拟化项目中的架构设计和产品选型，是一份具有实战参考价值的解决方案材料。

1. 从一份 PPT 讲到 CNware：国产化虚拟化平台不是把 VMware 换个名字

收到一份名为 CNware 虚拟化平台解决方案.pptx 的材料时，我第一反应是：又一个国产化替代的入场者。后来把里面的架构图和部署参数看完才发现，CNware 走的是 KVM/QEMU 这条完全开源的底座路线，它解决的问题很直接：企业或数据中心要换掉商用虚拟化平台，又要保留虚机迁移、存储池化、模板分发这些日常运维习惯，CNware 把这些能力收进一个可交付的解决方案里。说它不是把 VMware 换个名字，是因为它的管理面和计算面可以分开部署，硬件兼容性也宽松得多。适合谁？正在做国产化评估的甲方、IDC 运维团队，以及想用低成本把虚拟化平台跑起来的实施工程师。接下来我从这张 PPT 里的方案出发，把组件选型、安装步骤和参数设置拆成一份能照着做的落地笔记。

2. 先拆开解决方案里的黑匣子：CNware 的组件选型与最小实验环境

2.1 CNware 在方案里真正卖的是哪三样：计算、存储池和桥接网络

CNware 这类平台表面上是「虚拟化管理平台」，实际上交付的是三块东西。第一块是计算虚拟化，底层直接使用 KVM 内核模块和 QEMU 用户态进程，每台物理机变成一个计算节点，负责创建和管理虚拟机。第二块是存储池，它并不强制绑定分布式存储，而是采用了 LVM、本地目录、iSCSI、分布式存储多种后端并存的方式，这份 XXT 里的存储章节重点强调了「按业务场景选后端」，而不是像很多开源方案那样只推一种 Ceph。第三块是网络虚拟化，借助 Linux Bridge 和 Open vSwitch 两种模式，把物理网卡切成多个桥接网络，为虚拟机提供二层或三层网络能力。

这三块里最容易让新人误判的是存储。很多人看 PPT 首页会以为 CNware 自带一套完整的分布式存储，实际上它的架构是「存储接入层」，真正干活的后端可以是已有的集中式存储阵列，也可以是服务器内置磁盘组成的 LVM 池。这个设计有很实际的好处：如果机房已经采购了中端存储，CNware 不需要你重新买一套，直接通过 iSCSI 或者 FC 接进来就能用；如果没有独立存储，也可以用 LVM 把本地盘池化。方案 PPT 里的容量计算表一般会按「可用容量 = 裸容量 × RAID 效率 × 预留比例」来写，这个公式后面的章节我会展开算一个例子。

2.2 控制面与数据面分离：为什么管理网和业务网一定要拆开

CNware 的部署拓扑里有一个很明确的原则：管理面（Managment Plane）和数据面（Data Plane）必须分开。管理面承载的是管理节点、数据库、Agent 心跳、策略下发这些控制流量，数据面承载的是虚拟机之间、虚拟机与物理网络之间的真实业务流量。PPT 里的网络规划图通常会把物理机网卡分成三组：一组连接管理交换机，一组连接业务交换机，一组预留做存储网络。如果只有两块网卡，最差也要做成两个 VLAN 分隔的 trunk，把管理 VLAN 和业务 VLAN 分开走。

为什么必须拆开？因为控制面一旦被业务流量挤满，最先掉链子的不是虚拟机性能，而是管理节点的 Agent 心跳。心跳超时后平台会认为计算节点失联，触发虚拟机 HA 迁移，如果只有一台物理机，这个操作反而可能导致误关机。我见过一个实际案例，部署时图省事把所有流量塞在同一张网卡上，视频业务一上来，管理面 ping 管理节点延迟到了 300 多毫秒，平台频繁告警，最后只能重新规划网络。CNware 的管理面一般走 TCP 8443 端口和 Agent 的 9000 端口，这些端口被防火墙误拦也会出现「节点离线」的假象，后面避坑章节会说。

2.3 用一台物理机搭出最小实验环境：CPU、内存、磁盘的底线参数

CNware 虽然是企业级方案，但做最小化验证并不需要三台服务器起步。如果你只是跑通流程、验证迁移和模板功能，一台物理机就够了，条件是这一台物理机同时跑管理节点和计算节点。底线参数可以参考下面的表：

这里要单独说一下 CPU 的坑。很多人在 Windwos 物理机里装 VMware Workstation 时遇到过「此平台不支持虚拟化」的提示，在 CNware 裸机部署时会遇到一模一样的现象：装完系统，启动 libvirt 检查 KVM 可用性，报错说 CPU 不支持虚拟化扩展。原因几乎都不是 CPU 真不支持，而是 BIOS 里的 Intel VT-x 或 AMD-V 开关默认关闭，或者被超线程和嵌套虚拟化配置干扰。实验环境里内存和磁盘都可以凑合，CPU 虚拟化开关是硬门槛，这一步不过，后面全都是白费。

3. 从裸机到进入管理面板：CNware 落地的四步安装过程

3.1 第一步：在 BIOS 里打开虚拟化开关，把「虚拟化不可用」挡在第一关

CNware 计算节点的宿主机安装操作系统前，有一个动作必须先做：确认 CPU 虚拟化已经启用。这个动作我很建议在装系统之前就完成，而不是装完之后再回头看报错。重启服务器，进入 BIOS，找到 Intel Virtualization Technology 或 AMD SVM Mode 选项，设置为 Enabled。Intel 平台还要顺带看一眼 VT-d，虽然 CNware 默认不强制使用直通设备，但开了之后后续做 PCIE 直通或 SR-IOV 会方便很多。

进入已装好的系统后，用下面的命令确认 KVM 模块是否加载正常：

# 确认 CPU 支持虚拟化扩展 grep -E "(vmx|svm)" /proc/cpuinfo # 加载 KVM 内核模块，并确认已经生效 modprobe kvm modprobe kvm_intel # AMD 平台换成 kvm_amd lsmod | grep kvm

逻辑说明：第一条命令在 Intel 平台上会看到 vmx 标志，AMD 平台上会看到 svm 标志。如果没有任何输出，不用往下走了，回到 BIOS 里重新检查开关；如果输出存在但加载模块时提示 Operation not permitted，多半是嵌套虚拟化没开或内核模块被禁用。参数说明中值得注意的是，lsmod 的结果里除了 kvm 本身，还应该能看到 kvm_intel 或 kvm_amd，只有 kvm 主模块而看不到平台模块，虚拟机创建时一样会报错。

3.2 第二步：给宿主机安装最小化系统：分区、网卡和主机名的决定

CNware 计算节点不推荐把系统装成带桌面的完整发行版，最小化安装能减少很多不必要的服务干扰。这里我一般会用 CentOS 7.9 的最小化安装镜像，安装时选择「Minimal Install」。分区方案建议做成下面的形式：/boot分区独立给 1 GB，根分区/用 LVM 管理，预留 30% 的剩余空间不分配，方便后续给 Docker 或大数据组件留余地。数据盘单独划分，不要把手动挂载的/data目录也放进根分区 LVM 里，后面创建存储池会用它。

网卡配置建议在安装阶段直接做掉。管理网卡配置静态 IP，网关指向管理交换机 VLAN 的网关；业务网卡可以暂时不配 IP，或者配置一个不冲突的网段地址，等到管理面板里添加网络时再统一管理。安装完成后，确认主机名并设置时钟同步：

# 设置主机名，建议包含节点角色，例如 cnware-node01 hostnamectl set-hostname cnware-node01 # 安装 chrony 并配置 NTP 同步，防止管理节点和计算节点时钟偏差 yum install -y chrony systemctl enable --now chronyd # 验证时间同步状态 chronyc tracking

逻辑说明：主机名和时钟同步是很多实施工程师会跳过的步骤，但这恰恰是后面集群能正常工作的基础。CNware 管理节点会基于时间戳做任务调度，如果计算节点和管理节点的时间差超过 30 秒，Agent 上报的数据会出现冲突，虚拟机的 HA 策略也会被误触发。参数上值得留意的细节是，chronyc tracking输出里的System time字段如果显示超过 1000 微秒，建议检查 NTP 服务器配置，而不是继续往后走。

3.3 第三步：初始化管理节点：加载平台服务并创建管理员账号

管理节点是 CNware 的入口，安装包里通常是一个可执行的安装脚本，常见做法是把整个安装包传上服务器后，解压进入目录直接运行。为了保证可复现性，我一般会在执行安装前手动检查几个前置条件：防火墙放行 8443 端口、SELinux 设为 permissive 或 disabled、磁盘空间满足要求。以下命令是在管理节点上执行的标准流程：

# 关闭 SELinux，并临时设置当前会话 setenforce 0 sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config # 开放管理端口 8443 和数据库端口 3306 firewall-cmd --permanent --add-port=8443/tcp firewall-cmd --permanent --add-port=3306/tcp firewall-cmd --reload # 执行平台初始化脚本，参数为管理网段的 IP 和网段掩码 ./install.sh --mgmt-ip 192.168.10.10 --mgmt-bits 24

脚本执行完成后，终端会输出一个管理页面地址和临时管理员密码。首次登录时需要修改密码并创建新的管理员账号。这里的核心参数是--mgmt-ip：必须使用管理网卡的地址，不能图省事写成 127.0.0.1，否则计算节点从业务网络访问不到管理面，后面注册节点时就会出现 Agent 在线异常。

3.4 第四步：把计算节点接入管理面板：注册与验证 Agent 心跳

计算节点接入管理面板的方式分为两种：一种是在管理页面的 Web 界面里点击「添加计算节点」，填入节点 IP 和用户名密码，平台会自动下发 Agent 安装包；另一种是从安装包中提取 Agent 安装文件，在计算节点上手工安装。手工安装更直观，也能把安装日志留在本地排查，命令如下：

# 计算节点上安装 agent 包，参数指向管理节点的 IP 和端口 tar -xzf cnware-agent.tar.gz cd cnware-agent ./install.sh --server 192.168.10.10 --port 9000 # 启动 agent 服务并检查运行状态 systemctl start cnware-agent systemctl status cnware-agent # 查看 agent 日志，确认与管理节点的长连接已建立 tail -n 50 /var/log/cnware/agent.log

逻辑说明：Agent 安装的核心参数是--server，它必须指向管理节点的管理网 IP，而不是计算节点自己的 IP。很多实施人员在手工安装时把这里的地址写错，导致 Agent 一直处于重连状态。验证成功的标志是，管理面板上节点状态从「未注册」变成「在线」，同时 agent.log 里出现心跳上报成功的记录。这一步完成后，平台的最小编排环路已经打通：管理节点下发任务，计算节点执行虚拟机的创建和销毁。

4. 虚拟机的三个必调参数：存储、网络和模板的坑一次说清楚

4.1 存储池：LVM 还是文件目录，一张表解决大多场景

CNware 管理面板里创建虚拟机之前，必须先有存储池。很多新手在这一步会纠结选哪种存储池类型，其实不需要纠结，按场景判断：如果只有一台计算节点且数据盘是本地盘，直接用目录池或者 LVM 池是最省事的；如果有多台计算节点且数据要漂移，就必须让存储后端落在共享存储上。下表是三种常用存储池的适用判断：

这里特别提醒一点：LVM 池在创建之后，虚拟机的系统盘会生成一个逻辑卷，这个逻辑卷的默认分配策略是立即全量分配还是精简分配，会直接影响后续虚拟机克隆的体验。如果面板里存在「精简配置」选项，建议开启，否则创建 10 台虚拟机就会占满整个卷组。开启精简配置后，虚拟机实际使用了多少空间才是占用的空间，而初始创建只需要很小的元数据开销。

4.2 业务网络：vSwitch、VLAN 和多网卡绑定的取舍

CNware 的网络部分采用的是「物理网卡 → 桥接设备 → 虚拟交换机」的层级。在管理面板里添加网络时，会要求选择桥接模式：Linux Bridge 模式适合大多数常规业务，Open vSwitch 模式适合需要流量监控、QoS 和隧道封装的场景。如果虚拟机需要和物理机在同一网段通信并对外提供服务，选择 Linux Bridge 并指定一个物理网卡作为 uplink 就行。

计算节点的业务网卡可能存在多块，这时候建议先做绑定再桥接，避免虚拟机流量只走单网卡。常见做法是让两块物理网卡做 mode 4（LACP）绑定，然后把绑定口加入桥接设备。注意，不要在绑定口上配置 IP，否则 Linux Bridge 会把 IP 流量和桥接流量混在一起。VLAN 方面，如果业务网是一个 trunk 端口，需要在面板上为不同租户或不同业务创建独立的 VLAN 网络，虚机网卡关联到对应网络即可。

4.3 镜像模板：从 qcow2 到 Windows 驱动，哪一步最容易被卡住

模板可以说是虚拟化平台里「后悔药」最多的地方，但也是最容易出问题的地方。CNware 的镜像模板通常使用 qcow2 格式，创建模板的方式有两种：一种是从一个安装好的虚拟机直接「转换为模板」，另一种是上传现成的 qcow2 镜像文件。第一种方式最稳妥，因为虚拟机的系统配置、网卡驱动、主机名已经正确处理，模板分发出去不会有「水土不服」的问题。

Windows 虚拟机模板是重灾区。很多人在创建 Windows 模板时没有安装 VirtIO 驱动，导致模板分发后虚拟机网卡无法识别、磁盘识别异常。解决方法是创建 Windows 虚拟机时必须挂载 VirtIO 驱动 ISO，并在系统安装过程中加载对应驱动。经过多次实践，我发现最省时间的做法是：先把 Windows 系统装好，装完 VirtIO 驱动，再更新系统补丁，最后做 sysprep 清理系统标识，然后才转成模板。省略 sysprep 的模板，批量克隆后会出现计算机名重复、SID 冲突这些网络连接问题，排错成本比重新做模板高得多。

5. 避坑：CNware 落地最容易翻车的 6 个现场（现象、原因、解决）

5.1 虚拟机起不来，终端报「KVM 不可用」

现象：在管理面板上创建虚拟机后，任务秒失败，查看计算节点日志提示kvm: disabled by bios或operation not supported。原因：BIOS 中虚拟化开关处于关闭状态，或者内核 kvm 模块未加载。解决：重启进入 BIOS 打开 Intel VT-x/AMD-V，确认/proc/cpuinfo里有 vmx/svm 标志，再执行modprobe kvm_intel。这一条和 Windows 上跑 VMware 提示「此平台不支持虚拟化」是同一个底层问题，尽早排查能省下大量时间。

5.2 Agent 显示离线，但计算节点的网络是通的

现象：计算节点注册成功后，第二天在管理面板里显示离线，但该节点可以正常 ping 通其他设备。原因：Agent 服务进程崩溃或心跳端口被防火墙拦截，最常见的是管理平台升级后，Agent 版本不匹配，导致心跳数据格式异常。解决：先看systemctl status cnware-agent是否还在运行，如果服务在但离线，查看/var/log/cnware/agent.log最后一段日志，确认连接是否被服务端重置。一般重启 Agent 能解决，如果反复离线，重启顺序是：管理节点的平台服务先重启，等管理页面可访问后再启动计算节点 Agent 服务。

5.3 虚拟机硬件配置特别高，性能却跑不满物理机

现象：一台 32 核 64 GB 的物理机只跑了 2 台虚拟机，但 CPU 使用率就是上不去。原因：CPU 的调度策略默认使用kvm线程的默认权重，或者在创建虚拟机时没有开启 CPU 绑定和 NUMA 感知；另一个常见原因是物理机的 CPU 超频被 BIOS 关掉，性能模式被设成了省电模式。解决：在虚拟机配置里绑定虚拟 CPU 到物理 CPU 核心，开启 NUMA 自动均衡；同时在 BIOS 里把 CPU 电源管理设置为 Performance 模式。

5.4 存储池空间充足，虚拟机创建却提示「卷创建失败」

现象：LVM 存储池显示剩余空间有 200 GB，但创建一台 50 GB 磁盘的虚拟机时报错。原因：LVM 的总空间是卷组空间，但逻辑卷默认使用lvcreate的连续分配策略，物理卷上剩余的连续空闲区域不足，尤其是在测试环境里反复创建删除虚拟机之后，碎片化严重。解决：修改 LVM 分配策略为--alloc cling或--alloc anywhere；如果面板不支持这个参数，可以在存储池所在宿主机上手动用lvcreate -n vm-disk -L 50G vg-data --alloc anywhere创建逻辑卷，再在面板上挂载为既有磁盘。这个坑在频繁测试和删卷的实验室里非常常见。

5.5 虚拟机迁移后网络变慢，丢包明显

现象：通过在线迁移把虚拟机从节点 A 挪到节点 B，迁移后虚拟机内 ping 网关延迟变高，甚至有 1% 的丢包。原因：迁移前后的宿主机不在同一个二层网络内，或者虚拟机网卡的桥接设备发生了漂移。迁移时 CNware 只迁移了内存和磁盘状态，但网络前端类型如果不同，就会触发降级。解决：迁移前确认两台计算节点的业务网络都用同一个网桥，且虚拟机网卡的驱动类型一致；如果是 Linux Bridge，迁移后手动在面板上「断电重启网络」重新关联到目标节点的桥接设备就能恢复。

5.6 管理节点重启后，虚拟机全部关机，没有自动拉起

现象：管理节点做了一次计划内重启，恢复后发现所有计算节点上的虚拟机都是关机状态。原因：CNware 的 HA 策略默认只在「计算节点意外掉线」时生效，管理节点主动重启不会触发迁移；同时虚拟机的「开机自启动」策略默认是关闭状态。解决：在每台虚拟机的电源管理设置里勾选「宿主机启动后自动开机」；如果是集群环境，配置管理节点的高可用，让管理面本身具备故障转移能力，而不是依赖单台管理节点。

6. 用命令行验证集群健康：把「能开能关」变成「可度量」

管理面板能做的事情，命令行几乎都能做，而且命令行更适合巡检脚本。这里分享一个我每次维护完 CNware 都会跑一遍的检查链路：先看物理节点状态，再看虚拟机的实际运行状态，最后检查存储和网络的关键指标。

# 查看所有计算节点的 CPU 和内存占用 virsh nodeinfo virsh dominfo <vm-name> # 查看单台虚机的运行配置 # 查看存储池剩余空间和虚拟磁盘状态 virsh pool-list --all virsh vol-list --pool default # 检查桥接设备是否正常工作 ip link show br0 bridge link show br0

单个命令的说明可能不够，我把输出结果怎么看列出来：virsh nodeinfo最后的CPU model和CPU socket如果出现与物理机规格不符的情况，说明 BIOS 识别有问题；bridge link show里如果某个虚机网卡显示state DOWN，而对应虚机是正常运行状态，说明网卡前端和后端有状态漂移，需要检查 VirtIO 驱动。这些检查不出问题，平台的健康度就有了一个大致的证明。

我自己的维护习惯是：每次升级管理平台或修改存储配置后，不直接去 Web 界面创建一堆虚拟机来测试，而是先用命令行跑一遍virsh list --all，确认所有虚机状态没有变成paused；再手动触发一次在线迁移，把一台测试虚机从此节点迁到彼节点，迁完立刻看virsh domblklist和virsh domiflist，确认磁盘和网卡路径都正确。这套流程看起来慢，实际上比在面板里反复点鼠标快得多，也能在第一时间暴露平台级的配置偏差。

CNware 虚拟化平台这套方案，最重要的一块拼图不是功能有多少，而是遇到问题的时候能不能快速定位到底是哪一层出了状况。把前五章讲到的架构、参数和坑都过一遍之后，再用命令行巡检去验证每一步的成果，整个平台的可维护性会有明显提升。希望这份笔记里的经验和教训能帮你在自己的环境里少走一些弯路。

本文还有配套的精品资源，点击获取