03.KVM使用virt-manager创建虚拟机.md

如何识别物理机还是虚拟机

修改英文使virt-manager显示OK，此外virt-manager需要安装Xmanager显示工具。还有生成环境不要用这东西。

网桥查看

此处5G要理解

实际占用并没有5G

定制👆或不定制👇都可以

点击开始安装

AMD的报错处理

rokcy 的virt-manager打开处理

打开X-MANAGER看到1.0，就是我们的:1.0，然后IP就是VMworkstation的VM网卡了

192.168.126.1就是Vnet网卡，1.0就是Xmanager的1.0

故障案例1

e1000e

vm网卡默认的virtio，结果一开机(virtsh start不会，virt-manager的GUI开机会，其实就是有数据传递就会崩掉！)，把宿主机的网卡干断了，这是宿主的console进去报的错👇

这是vm里的卡住的界面

解决方法1，就是调整VM为e1000e就好了

解决方法2

参考：https://ovear.info/post/356

# 关闭 guest 内 VirtIO 网络 offloading
ifconfig vtnet0 -rxcsum -txcsum -tso -lro

# 或在宿主网络接口上关闭，
ethtool -K ens33 tso off gso off  # 有时候可以，很多次也不行，还需要加上下面
ethtool -K ens33 rx off tx off


# GPT推荐的完整版，但不是最终版，最终版要做成配置文件的永久生效。
ethtool -K ens33 \
  tso off gso off gro off lro off \
  rx off tx off

ethtool -k ens33 | egrep 'tso|gso|gro|lro|rx-checksumming|tx-checksumming'

意思是：

“别给我搞什么大包分段、硬件卸载， 老老实实按 MTU 发”

没有敲ethtool -K之前，virt-manager里vm设置为virtio的报错

这些网卡 offload 功能到底是什么，以及 关掉会不会影响业务。

一、这些功能到底是啥（ethtool 能关的 offload）

你用的命令涉及的主要功能有：

核心结论

这些功能都是“性能优化”功能，不是业务必需 关掉它们 不会影响业务正确性，只会让 CPU 多干一些工作。

二、为什么你在虚拟机里必须关掉

1. virtio / e1000e 这些半虚拟化网卡：

2. 有些 offload 特性在桥接或虚拟化环境里 不兼容

3. 会导致 TX queue hang / 宿主机断网

4. 真实网络 vs 虚拟化网络：

5. 在物理机上，开 offload 很稳定，性能好

6. 在虚拟机里，某些 offload 会触发 硬件/驱动 bug

三、业务影响

• 网络功能：完全不受影响（包还是能发能收）
• CPU 占用：会增加一点（通常微小，可忽略）
• 吞吐量：可能略低于硬件 offload，但在你的场景（KVM + e1000e/virtio + bridge） → 稳定比性能重要

✅ 所以在虚拟化环境里，关掉全部 offload 是安全做法 ✅ 这也是运维界的经验做法：稳定 > 微小性能提升

四、总结一句话

这些 offload 都是“性能优化开关”，在虚拟机桥接环境里容易炸网，把它们全部关掉不会影响业务，只会让 CPU 多做一点工作，换来的就是稳定可靠的网络。

如果你愿意，我可以帮你画一张 “virtio / e1000e 数据包路径 + offload 功能作用图”，直观看懂每个 offload 做了什么，为什么会导致 TX hang。

你想让我画吗？

明白，你现在想把这个 ethtool 关闭所有 offload 的命令改为 永久生效，不每次重启都手动执行。 我给你详细方案，Rocky Linux 10 / RHEL 10 上推荐做法。

一、系统启动自动执行方法

使用 NetworkManager 的 connection 配置

这是 官方推荐、最干净的方法：

1. 查看你的接口配置文件：

nmcli connection show

假设接口叫 ens33。

1. 编辑该连接的配置：正确的 CLI 永久设置写法要用 feature-xxx。

正确写法示例

nmcli connection modify ens33 \
  ethtool.feature-tso no \
  ethtool.feature-gso no \
  ethtool.feature-gro no \
  ethtool.feature-lro no \
  ethtool.feature-rx no \
  ethtool.feature-tx no

或者有些版本需要直接去掉 ethtool. 前缀：

nmcli connection modify ens33 \
  feature-tso no \
  feature-gso no \
  feature-gro no \
  feature-lro no \
  feature-rx no \
  feature-tx no

立即生效

nmcli connection down ens33
nmcli connection up ens33

验证1

nmcli connection show ens33 | grep feature
ethtool -k ens33

你应该看到：

tcp-segmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
rx-checksumming: off
tx-checksumming: off

验证2★，其实才是最佳实践入口

直接查看配置文件，是否有新的配置生成，其实也可以直接从配置文件里修改，然后reload up就行了

[root@localhost system-connections]# ll
total 4
-rw-------. 1 root root 344 Dec 22 16:41 ens33.nmconnection
[root@localhost system-connections]# cat ens33.nmconnection
[connection]
id=ens33
uuid=dbb81dea-080f-3308-8ae1-9de3034cd71b
type=ethernet
autoconnect-priority=-999
interface-name=ens33
timestamp=1766392474

[ethernet]

[ethtool]
feature-gro=false
feature-gso=false
feature-lro=false
feature-rx=false
feature-tso=false
feature-tx=false

[ipv4]
method=auto

[ipv6]
addr-gen-mode=eui64
method=auto

[proxy]

✅ 优点：

• 重启后自动生效
• 官方支持
• 不依赖额外脚本

virt-install    --name=10.5.2.39-mysql --ram=8192 --vcpus=4 --cpu host --cdrom=/iso/CentOS-7-x86_64-Minimal-1908.iso --os-type=linux  --disk /data/10.5.2.39-mysql.qcow2,size=500G,bus=virtio,cache=none --network bridge=br0,model=e1000 --network bridge=br1,model=e1000 --graphics vnc,port=5906,listen=0.0.0.0,password=t812pg2LrDOsyLlTBFJBPztd2PkeVO --hvm \

virt-manager最佳实践-win11

1、windows11

wsl2别用，要关闭干净，因为我电脑上有vmware workstaion的VM要开机CPU虚拟化。

👍 很好，这一步非常关键，而且你已经把最大的一颗雷拔掉了。

现在你的状态是：

适用于 Linux 的 Windows 子系统分发:
Ubuntu (默认值)

👉 docker-desktop / docker-desktop-data 已经完全清干净 👉 说明 WSL 这条线已经不再主动拉起 Hyper-V

但我要很直白地告诉你一句运维结论：

现在 VMware 还起不来 VT-x/EPT，只可能是 Windows 虚拟化功能或 VBS 还残留着

下面我们直接进入“最后清场阶段”。

一、先给你一个“判断点”（不用猜）

你现在立刻执行这条命令（管理员 PowerShell）：

systeminfo | findstr /i "Hyper-V"

理想输出（这是“完全干净”的状态）应该类似：

未检测到 Hyper-V 要求。

如果你看到类似下面任何一句（哪怕一行）👇

已检测到 Hyper-V 要求
虚拟机监控程序已检测到
需要启用虚拟机监控程序

👉 说明 Hypervisor 仍在运行 👉 VMware 继续报 VT-x/EPT 是“必然结果”

二、一步到位的“强制清空方案”（建议你直接照做）

即使你之前做过，我也建议完整再跑一遍（很多人漏一步）。

✅ 1️⃣ Windows 功能（一个都不能留）

控制面板 → 启用或关闭 Windows 功能

确认以下 全部未勾选：

☐ Hyper-V
☐ Virtual Machine Platform
☐ Windows Hypervisor Platform
☐ Windows Sandbox
☐ Microsoft Defender Application Guard

点【确定】→ 重启

✅ 2️⃣ bcdedit（强制不给 hypervisor 启动）

管理员 PowerShell：

bcdedit /set hypervisorlaunchtype off

执行完 必须重启

✅ 3️⃣ 关 VBS（这是最后 20% 的坑）

图形方式（推荐）

Windows 安全中心 → 设备安全 → 核心隔离

内存完整性 = 关闭

关闭后 重启

很多机器这里没关，哪怕没装 Hyper-V，VT-x 也会被吃掉

✅ 4️⃣ 再确认一次（非常重要）

重启后，再执行：

systeminfo | findstr /i "Hyper-V"

如果这一步是 干净状态，我们就赢了 90%。

三、VMware 里你必须确认的一处（容易被忽略）

虚拟机 → Settings → Processors

确保：

☐ Virtualize Intel VT-x/EPT or AMD-V/RVI

👉 这个是 嵌套虚拟化 👉 勾了反而更容易在 Windows 上报错

四、给你一个“终极判断法”（不用再怀疑）

方法 1：任务管理器

任务管理器 → 性能 → CPU

如果你看到：

虚拟化：已启用

并且 VMware 虚拟机能正常启动 ✅ 问题解决

方法 2：VMware 报错是否消失

• 不再出现 Intel VT-x/EPT is not supported
• 客户机能启动

✅ 100% 成功

五、站在你这个“搞虚拟化 + 讲课”的角度，给你一句建议

你这个环境，我建议你长期保持：

Windows:
  ❌ Hyper-V
  ❌ WSL2
  ❌ Docker Desktop
  ❌ VBS
  ✅ VMware Workstation

Linux:
  ✅ VMware 虚拟机里玩 KVM / Docker / EVE-NG

这是最稳、最可控、最少踩坑的组合。

六、下一步我可以直接“接管式排查”

你可以直接把 下面这一条的完整输出原样贴出来（不用截图）：

systeminfo

我可以直接告诉你一句：

“现在是谁在占 VT-x” 或者 “已经 100% 干净，VMware 哪一步该怎么点”

你现在这个状态，已经离成功 只差最后一道门槛。

非常好，这一行输出等于“最终判决书”，我们现在可以100%确定原因了。

你这句是：

Hyper-V 要求: 已检测到虚拟机监控程序。将不显示 Hyper-V 所需的功能。

一、这句话翻译成运维人话就是一句

Windows 的 Hypervisor 现在仍然在运行，并且已经抢占了 Intel VT-x/EPT。

所以结论非常明确：

❌ 不是 VMware 的问题 ❌ 不是 BIOS 的问题 ❌ 不是 WSL 的问题 ✅ 是 Windows 启动时仍然拉起了 hypervisor

二、为什么会这样（关键认知）

即使你已经做到：

• 卸载 Docker Desktop ✅
• WSL 只剩 Ubuntu（WSL1）✅
• Windows 功能里关了 Hyper-V（可能）✅

只要下面任意一条成立，hypervisor 仍然会启动：

1. hypervisorlaunchtype 不是 off
2. VBS / 内存完整性 还开着
3. 曾启用过某些“隐形虚拟化功能”，BCD 里还在

👉 你现在正是 第 1 或第 2 种情况（几乎肯定）

三、一步到位：100% 关闭 Hypervisor（照抄）

✅ 第一步（最关键，强制级）

管理员 PowerShell / CMD：

bcdedit /set hypervisorlaunchtype off

如果返回：

操作成功完成

👉 继续

✅ 第二步（必须重启）

立刻重启 Windows ⚠️ 这一步不能省，否则下面判断全是假的

✅ 第三步（重启后立刻验证）

重启后，第一件事执行：

systeminfo | findstr /i "Hyper-V"

🎯 正确结果必须是（或类似）：

未检测到 Hyper-V 要求。

或者：

Hyper-V 要求: 虚拟机监控程序未检测到

只要不再出现「已检测到虚拟机监控程序」这句话，就成功了。

四、如果你执行了 bcdedit 仍然不行（兜底方案）

这个情况 只会出现在 VBS 没关干净

再确认一次（非常重要）：

Windows 安全中心 → 设备安全 → 核心隔离

内存完整性 = 关闭

关闭后 → 重启

然后再跑一次：

systeminfo | findstr /i "Hyper-V"

五、到这一步，VMware 必然恢复（不是“可能”）

只要：

• systeminfo 不再显示虚拟机监控程序
• VMware 虚拟机 不再报 VT-x/EPT

那就是：

✅ 物理 VT-x 已完全回到 VMware 手里

六、再帮你确认一个“不会再踩坑”的点

VMware 虚拟机 → Settings → Processors

确保：

☐ Virtualize Intel VT-x/EPT or AMD-V/RVI

这是嵌套虚拟化 Windows 宿主 + VMware 场景下，先别碰它

七、一句“老运维结论”，你可以直接记住

看到 已检测到虚拟机监控程序 → VMware 必死 → 只看 bcdedit + VBS → 和 WSL1 / WSL2 已经没关系了

八、下一步你可以直接回我一句

你现在可以直接回我 二选一 的结果即可：

1️⃣

systeminfo 现在已经不显示“已检测到虚拟机监控程序”

2️⃣

执行了 bcdedit + 重启，systeminfo 还是显示虚拟机监控程序

我可以根据你这一句，直接给你最后一刀（如果还需要的话）。

2、virt-manger要调字体

virt-manager调大菜单字体

export GDK_SCALE=2就行了

3、virt-manger 远程管理要配置ssh，wsl1之呢用用key登录