虚拟化技术

真正有效压缩hyper-v虚拟磁盘文件VHDX
hyper-v迁移前开启winrm service
Windows Server 2022 Hyper-V 虚拟网卡参数查看及修改
银河麒麟高级服务器版V11+KVM+Libvirt+WebVirtCloud+OpenStack部署
rsync 实现每日增量备份 KVM 虚拟机磁盘
银河麒麟 + KVM + WebVirtCloud 虚拟机内存不足8G原因与解决方法
KVM安装win11
Hyper-V 实时迁移（Live Migration）的身份验证方式配置错误解决方法
管理QEMU虚拟化平台常用的运维命令
Hyper-V + Ubuntu 18.04 环境下尽最大可能阻止虚拟机被克隆
Hyper-V 解除IOPS限制的方法
在 Hyper-V 物理宿主机上把网卡的 Virtual Machine Queues（VMQ）设为 Disabled会产生以下实际后果
传统虚拟机管理工具 virsh、libvirt 已过时！更轻量、更安全、更易用的现代化跨平台替代利器来了
KVM 虚拟化（libvirt / virsh）常用命令清单
无法启动虚拟机，因为虚拟机监控程序未运行，实测解决方法
hyper-v ubuntu虚拟机测试网卡并发，含sar tcpdump抓包
在 TrueNAS SCALE（基于 Linux 的现代版本）中集成局域网 Active Directory（AD）域
阿里云 ECS（Ubuntu 18.04）把系统盘转换成 Hyper-V 可用的 VHD

真正有效压缩hyper-v虚拟磁盘文件VHDX

首先明确：hyper-v管理器里面“设置-硬盘驱动器-编辑-选择操作-压缩”并没有明显的效果。

然后区分几个关键词：

hyper-v里面的“压缩（compact）”：虚机里磁盘的可用空间不变，虚拟磁盘文件大小变小（因为是回收虚机因删除文件释放出来的磁盘空间，所以不可能压缩到比虚机里磁盘总已用空间还小）

hyper-v里面的“收缩”：虚机里磁盘的可用空间变小。（不可能影响已用空间）

磁盘管理工具（diskmgmt.msc）里面的“压缩卷”：使磁盘的可用空间变小。（不可能影响已用空间）

最后看方案：

1.有人给出的方案：碎片整理无效，还有反作用，应该先收缩，再压缩，再扩展。

如：先在磁盘管理工具里面“操作-附加VHD”，然后在有可用空间的分区上右键“压缩卷”（只支持NTFS，而且过程漫长，无进度条），然后分离VHD，在hyper-v管理器里面压缩，就有效果。

2.也有方案：建一个新的虚拟磁盘，使用diskgen或者Ghost11把原来磁盘的内容（按文件或者文件系统或者partition2partition拷过来），然后把新的虚拟磁盘当原来的磁盘用。

这两个感觉都不是很好，速度慢或根本没有进度条不知道过程如何了；或者不支持linux；或者新磁盘的有些硬件特征会改变。

看下面的：

3.对NTFS文件，用Windows Server PowerShell里面的Optimize-VHD小命令（cmdlet），操作如下：a.先在磁盘管理工具里面“操作-附加VHD”，记得勾选“read-only”（必不可少）b.打开PowerShell，输入Optimize-VHD -Path C:\YourVHDX.vhdx -Mode Full。运行后很快就OK了，磁盘文件显著变小了。关于Optimize-VHD详细一点的说明可参考：https://docs.microsoft.com/zh-tw ... e-vhd?view=win10-ps

4.Linux系统，压缩前，要在虚机层面将标记为DELETE的文件彻底删除，也就是将虚机磁盘上的位置0。（具体置零的方法：下载systemrescue cd，用该cd启动虚机，运行zerofree，如zerofree /dev/sda1），然后再压缩。这是国外论坛上给的方法，老外说这个systemrescuecd小巧好用，值得一试，下载网站：https://www.system-rescue.org/。然后Optimize-VHD -Path C:\YourVHDX.vhdx -Mode Prezeroed，这个不用在磁盘管理工具里面附加VHDX，不是NTFS，附加了对效率也没提升。

这两个方案应该是比较靠谱的，方案3亲测有效。

hyper-v迁移前开启winrm service

winrm service: 是windows 一种方便远程管理的服务；开启winrm service,便于在日常工作中，远程管理服务器，或通过脚本，同时管理多台服务器，来提高工作效率；

工具/原料

windows server

方法/步骤

winrm service 默认都是未启用的状态，先查看状态；如无返回信息，则是没有启动；

winrm enumerate winrm/config/listener

针对winrm service 进行基础配置：

winrm quickconfig

查看winrm service listener:

winrm e winrm/config/listener

为winrm service 配置auth:

winrm set winrm/config/service/auth @{Basic="true"}

为winrm service 配置加密方式为允许非加密：

winrm set winrm/config/service @{AllowUnencrypted="true"}

至此，winrm service 已经启用，可以正常使用；

Windows Server 2022 Hyper-V 虚拟网卡参数查看及修改

在 Windows Server 2022 Hyper-V 虚拟机中，虚拟网卡（vNIC）是通过 Hyper-V 虚拟交换机管理的，默认使用的虚拟网卡驱动是 Hyper-V Synthetic Network Adapter（即 hv_netvsc 驱动）。关于 TX/RX Buffer（发送/接收缓冲区）参数，有几个要点：

1️⃣ 查看网卡缓冲区大小

PowerShell 查看网卡队列和相关参数：

Get-NetAdapterAdvancedProperty -Name "vEthernet (VM Name)"

可以查看诸如 Receive Buffers、Transmit Buffers 之类的高级属性（如果驱动支持）。
如果显示为空或没有该选项，说明 Hyper-V Synthetic Adapter 不允许用户直接调整。

通过设备管理器查看高级属性：

打开 设备管理器 → 网络适配器 → Hyper-V 网络适配器 → 属性 → 高级
一些物理网卡的高级选项（如 Large Send Offload、Receive Buffers）可能可用，但大部分 vNIC 没有明显的 Buffer 调整项。

2️⃣ 修改网卡缓冲区

Hyper-V Synthetic Adapter 本身的 TX/RX Buffer 不可直接修改。
可选方案：
1. 修改宿主机物理网卡缓冲区：
  - 宿主机的物理 NIC 支持调整 TX/RX Buffer 时，Hyper-V vNIC 会间接受益。
  - PowerShell 示例：
```
Set-NetAdapterAdvancedProperty -Name "Ethernet0" -DisplayName "Receive Buffers" -DisplayValue 1024
```
2. 增加虚拟机 vNIC 数量：
  - 多队列 vNIC（RSS、多队列网卡）可以提升高并发情况下的吞吐量。
```
Set-VMNetworkAdapter -VMName "VM Name" -IovQueuePairs 4
```
  - 需要物理网卡和 Hyper-V 支持 SR-IOV。
3. 启用或调整虚拟机的 VMQ（Virtual Machine Queue）：
  - VMQ 可以将网络流量分配到多个虚拟 CPU 上，提高并发处理能力：
```
Get-VMNetworkAdapter -VMName "VM Name" | Set-VMNetworkAdapter -EnableVMQ $true
```

🔹 总结

Hyper-V 的 Synthetic Adapter 不支持直接修改 TX/RX Buffer。
提升高峰期网络性能的办法：
1. 调整宿主机物理网卡缓冲区。
2. 启用 VMQ 或 RSS。
3. 增加 vNIC 或使用 SR-IOV 支持的直通网卡。

如果你需要，我可以帮你写一个 PowerShell 脚本，自动检测 Hyper-V 虚拟机网卡的 TX/RX 缓冲能力并设置 VMQ / 多队列，方便在高并发下优化网络。

你希望我直接写这个脚本吗？

银河麒麟高级服务器版V11+KVM+Libvirt+WebVirtCloud+OpenStack部署

非常好的选择 👍
您要实现的目标是：
在 银河麒麟高级服务器版V10（Kylin V10） 上，构建一个完整的虚拟化管理平台，包含：

KVM：提供虚拟化能力（基于CPU硬件虚拟化）
Libvirt：提供虚拟机管理接口
WebVirtCloud：提供Web管理界面
OpenStack（可选）：提供私有云级别的资源调度与自服务管理

下面给出一份 详细、可直接执行的部署文档（生产可用），默认系统为 Kylin V10 x86_64 / aarch64，已启用 yum 或 dnf 源。

🚀 一、环境准备

1. 检查CPU是否支持虚拟化

egrep -c '(vmx|svm)' /proc/cpuinfo

返回值 > 0 表示支持。

2. 确保内核模块支持KVM

lsmod | grep kvm

若未加载，则手动加载：

modprobe kvm
modprobe kvm_intel   # Intel
modprobe kvm_amd     # AMD

3. 启用桥接网络（推荐虚拟机可直接联网）

创建网桥配置文件 /etc/sysconfig/network-scripts/ifcfg-br0：

DEVICE=br0
TYPE=Bridge
BOOTPROTO=static
IPADDR=192.168.3.15
NETMASK=255.255.255.0
GATEWAY=192.168.3.1
DNS1=202.96.209.5
ONBOOT=yes

修改物理网卡（如 ifcfg-eno2）：

DEVICE=ens33
TYPE=Ethernet
BOOTPROTO=none
ONBOOT=yes
BRIDGE=br0

实际如下：
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=eui64
NAME=eno2
UUID=5d9b10e9-49eb-4742-875a-0a6cbc268e9b
DEVICE=eno2
ONBOOT=yes
BRIDGE=br0
#IPADDR=192.168.3.15
#PREFIX=24
#GATEWAY=192.168.3.1
#DNS1=202.96.209.5

然后执行：

systemctl restart network
实际该命令无效，reboot或其他方法

🧩 二、安装KVM + Libvirt + QEMU

yum install -y qemu-kvm qemu-img virt-manager libvirt python3-libvirt libvirt-client bridge-utils virt-install

启用服务：

systemctl enable libvirtd --now
systemctl status libvirtd

验证：

virsh list --all

应能返回空虚拟机列表。

手动添加 EPEL 仓库

cp /etc/yum.repos.d/kylin-extra.repo /etc/yum.repos.d/kylin-extra.repo.bak
vi /etc/yum.repos.d/kylin-extra.repo

[epel]
name=EPEL for Kylin 11 (RHEL8 compatible)
baseurl=https://mirrors.aliyun.com/epel/8/Everything/x86_64/
enabled=1
gpgcheck=0

[powertools]
name=PowerTools for Kylin 11
baseurl=https://mirrors.aliyun.com/centos/8/PowerTools/x86_64/os/
enabled=1
gpgcheck=0

dnf clean all
dnf makecache

🌐 三、安装WebVirtCloud（Web管理界面）

1. 安装依赖

yum install -y wget git
wget http://mirrors.aliyun.com/epel/epel-release-latest-8.noarch.rpm
yum localinstall -y epel-release-latest-8.noarch.rpm --skip-broken
yum clean all
yum makecache

yum install -y git python3 python3-pip nginx supervisor
安装报错的话要用清华源安装
mkdir -p ~/.pip
cat > ~/.pip/pip.conf <<'EOF'
[global]
index-url = https://pypi.tuna.tsinghua.edu.cn/simple
timeout = 6000
EOF
pip3 install supervisor
pip3 install --upgrade pip

2. 克隆WebVirtCloud源码

cd /opt
git clone https://github.com/retspen/webvirtcloud.git
cd webvirtcloud

如果git失败可调高缓冲区再下载
git config --global http.postBuffer 524288000
git config --global http.lowSpeedLimit 0
git config --global http.lowSpeedTime 999999
git config --global core.compression 0

3. 安装Python依赖

yum install libvirt-devel gcc python3-devel openldap-devel

pip3 install -r conf/requirements.txt

4. 初始化数据库和配置

cp webvirtcloud/settings.py.template webvirtcloud/settings.py

python3 -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"
#生成一串字符 c*&2pu%e=m7&r*^r*zp3p*wr!(8w3a$-l^rq@*w5#7ekrwmtpd
vi webvirtcloud/settings.py
#找到或添加 SECRET_KEY 配置）
SECRET_KEY = 'c*&2pu%e=m7&r*^r*zp3p*wr!(8w3a$-l^rq@*w5#7ekrwmtpd'

python3 manage.py migrate
python3 manage.py createsuperuser   # 创建管理员账号
#web登录用的账号密码
#账号  shuncom  邮箱：8108@shuncom.com  密码：sh_clighting

5. 启动测试

方法 A：Gunicorn 自带 `--daemon`

python3 manage.py runserver 0.0.0.0:8000

#如果报错换以下方法
# 安装 gunicorn（你已经安装了）
pip3 install gunicorn

# 启动 WebVirtCloud
gunicorn --workers 3 --bind 0.0.0.0:8000 --daemon webvirtcloud.wsgi:application

#日志默认输出到 gunicorn.log，可通过 --access-logfile 和 --error-logfile 指定日志文件
gunicorn --workers 3 --bind 0.0.0.0:8000 \
  --daemon \
  --access-logfile /var/log/webvirtcloud_access.log \
  --error-logfile /var/log/webvirtcloud_error.log \
  webvirtcloud.wsgi:application

方法 B：使用 `systemd` 管理 WebVirtCloud

创建服务文件 /etc/systemd/system/webvirtcloud.service：

[Unit]
Description=WebVirtCloud Django service
After=network.target

[Service]
User=root
Group=root
WorkingDirectory=/opt/webvirtcloud
ExecStart=/usr/local/bin/gunicorn --workers 3 --bind 0.0.0.0:8000 webvirtcloud.wsgi:application
Restart=always

[Install]
WantedBy=multi-user.target

然后执行：

systemctl daemon-reload
systemctl enable --now webvirtcloud
systemctl status webvirtcloud


#防火墙放行web端口
firewall-cmd --add-port=8000/tcp --permanent
firewall-cmd --add-port=80/tcp --permanent
firewall-cmd --reload
firewall-cmd --list-all

访问 http://服务器IP:8000，使用创建的管理员账号登录。

⚙️ 四、配置Nginx反向代理（生产环境）

编辑 /etc/nginx/conf.d/webvirtcloud.conf：

如果没安装：yum install -y nginx

server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_redirect off;
    }
}

重启服务：

systemctl enable nginx --now

🧰 五、配置Supervisor守护WebVirtCloud

如果系统没有 /etc/supervisord.conf，可以创建：

内容示例：

[unix_http_server]
file=/tmp/supervisor.sock   ; UNIX socket 文件

[supervisord]
logfile=/var/log/supervisord.log
pidfile=/tmp/supervisord.pid
childlogdir=/var/log

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///tmp/supervisor.sock

[include]
files = /etc/supervisord.d/*.ini

mkdir -p /etc/supervisord.d

vi /etc/supervisord.d/webvirtcloud.ini

[program:webvirtcloud]
command=/usr/bin/python3 /opt/webvirtcloud/manage.py runserver 0.0.0.0:8000
directory=/opt/webvirtcloud
autostart=true
autorestart=true
stderr_logfile=/var/log/webvirtcloud.err.log
stdout_logfile=/var/log/webvirtcloud.out.log
user=root

启用并启动：

systemctl enable supervisord --now

supervisorctl restart webvirtcloud

验证：

supervisorctl status

🖥 六、配置WebVirtCloud连接KVM主机

登录WebVirtCloud后台（http://<服务器IP>）
“Compute > Add Connection”
填写：
- Label: KVM-Host
- Hostname/IP: 127.0.0.1
- Connection type: SSH
- Login user: root 或管理用户

确保 root 用户可以无密码SSH到本机：

ssh-keygen -t rsa
ssh-copy-id root@127.0.0.1

连接成功后，即可在Web界面创建和管理虚拟机。

☁️ 七、（可选）安装 OpenStack 实现云平台管理

如果您需要将虚拟化扩展为“云平台”，可以部署轻量级 OpenStack All-in-One。

1. 安装 DevStack（快速体验）

cd /opt
git clone https://opendev.org/openstack/devstack
cd devstack

创建配置文件 local.conf：

[[local|localrc]]
ADMIN_PASSWORD=admin
DATABASE_PASSWORD=admin
RABBIT_PASSWORD=admin
SERVICE_PASSWORD=admin
HOST_IP=192.168.1.100

启动安装：

./stack.sh

安装完成后访问：

http://192.168.1.100/dashboard

默认用户：admin 密码：admin

🧾 八、验证与维护

验证虚拟化运行状态

virsh list

查看libvirt网络和存储池

virsh net-list
virsh pool-list

检查服务状态

systemctl status libvirtd
systemctl status nginx
systemctl status supervisord

✅ 部署总结

模块	功能	服务端口	管理方式
KVM	提供虚拟化能力	-	命令行/Libvirt
Libvirt	虚拟机管理接口	16509	virsh/virt-manager
WebVirtCloud	Web虚拟机管理	80/8000	浏览器
OpenStack	云计算管理平台	80/5000/8774 等	Web仪表盘 Horizon

🧭 建议实践路线

目标	推荐方案
轻量虚拟化环境	KVM + Virt-Manager
Web管理多节点	WebVirtCloud
构建私有云平台	OpenStack on KVM
高级调度与计费	OpenStack + Ceph

是否希望我为您输出一份 可直接在Kylin V10执行的 Shell 自动化安装脚本（含Nginx+WebVirtCloud+Libvirt 一键部署）？
那样您可以直接运行即可完成全部环境配置。

你现在在 WebVirtCloud 创建虚拟机实例时，提示：

You haven't defined any storage pools

这是因为 Libvirt 还没有配置任何存储池，WebVirtCloud 依赖存储池来存放虚拟机磁盘镜像。

1️⃣ 查看现有存储池

在服务器上执行：

sudo virsh pool-list --all

输出可能类似：

 Name                 State      Autostart
------------------------------------------------
 default              inactive   no

如果没有存储池或状态为 inactive，就需要创建或激活。

2️⃣ 激活默认存储池（如果存在）

sudo virsh pool-start default
sudo virsh pool-autostart default

3️⃣ 创建新的存储池（如果没有）

假设你希望在 /var/lib/libvirt/images 存储虚拟机磁盘：

sudo mkdir -p /var/lib/libvirt/images

sudo virsh pool-define-as default dir - - - - "/var/lib/libvirt/images"
sudo virsh pool-build default
sudo virsh pool-start default
sudo virsh pool-autostart default

解释：

pool-define-as default dir ... "/var/lib/libvirt/images"：定义一个目录类型存储池

pool-build：准备池

pool-start：启动池

pool-autostart：开机自动启动

4️⃣ 在 WebVirtCloud 刷新

登录 WebVirtCloud
打开 Host → Storage Pools
应该能看到你刚创建或激活的存储池
现在就可以创建虚拟机实例了

💡 小提示：

存储池必须 可写，并且 WebVirtCloud 运行用户有权限访问
通常使用 root 或者 libvirt 用户运行 WebVirtCloud

非常好 👍 你已经能在 WebVirtCloud 里创建虚拟机了。
现在要“上传 ISO 文件并挂载到虚拟机 CD-ROM”，可以有两种常见方式（命令行或 WebVirtCloud 界面）。我详细说明一下：

🧩 一、命令行方式（推荐）

这种方法最直接、最稳定，尤其是初次配置时。

1️⃣ 把 ISO 文件上传到宿主机存储路径

假设你的默认存储池是 /var/lib/libvirt/images：

cd /var/lib/libvirt/images

然后上传 ISO 文件（有多种方式）：

# 方式1：通过scp从你的电脑上传
scp CentOS-7-x86_64-Minimal.iso root@<宿主机IP>:/var/lib/libvirt/images/

# 方式2：直接从宿主机下载
wget https://mirror.stream.centos.org/7/isos/x86_64/CentOS-7-x86_64-Minimal.iso -O /var/lib/libvirt/images/CentOS-7.iso

确保 ISO 文件有读权限：

chmod 644 /var/lib/libvirt/images/*.iso

2️⃣ 定义 ISO 文件所在目录为存储池（如果还没定义）

如果 /var/lib/libvirt/images 不是存储池，可用：

virsh pool-define-as iso-pool dir - - - - "/var/lib/libvirt/images"
virsh pool-build iso-pool
virsh pool-start iso-pool
virsh pool-autostart iso-pool

3️⃣ 让 WebVirtCloud 识别新 ISO

在 WebVirtCloud 界面：

打开左侧菜单 Host → Storage Pools
选中你定义的存储池（如 default 或 iso-pool）
点击右上角 Refresh（刷新）
然后点击进入该池，你会看到上传的 ISO 文件列表。

4️⃣ 在虚拟机中挂载 ISO 文件

在 WebVirtCloud 界面：

进入你的虚拟机 → CD-ROM 选项卡
选择 “Attach ISO”
从列表中选中你上传的 ISO 文件
点击 Connect / Attach

这时虚拟机的 CD-ROM 就加载了该 ISO。

5️⃣ 从 ISO 启动虚拟机

在虚拟机界面 → Boot Options

把 CD-ROM 调整为第一个启动项（在 WebVirtCloud 界面中可以拖动）
保存后启动虚拟机，即可从 ISO 安装系统。

🧩 二、WebVirtCloud 直接上传（如果开启了上传功能）

如果 WebVirtCloud 配置了上传权限（部分版本默认关闭），可以直接在：

Host → Storage Pools → 选中 default → Files

看到右上角有 “Upload ISO” 按钮，选择本地 ISO 文件上传。

如果没有这个按钮，可以在 settings.py 中启用：

UPLOAD_ENABLED = True

然后重启 WebVirtCloud 服务（或 supervisor）。

✅ 验证

查看 ISO 是否被虚拟机挂载：

virsh domblklist <虚拟机名>

输出示例：

Target   Source
------------------------------------------------
vda      /var/lib/libvirt/images/ubuntu.qcow2
hdc      /var/lib/libvirt/images/CentOS-7.iso

说明 ISO 已正确挂载。

是否希望我帮你写一个“一键上传 + 挂载 ISO”的命令脚本？
比如你输入 ISO 路径和虚拟机名，它自动完成 virsh 操作并刷新 WebVirtCloud。

非常好 👍，你提到的：

<input type='keyboard' bus='default'/>

是导致你报错的 根本原因之一。

✅ 是的，这一行需要修改。

你应该把它改成宿主机支持的输入总线类型。
在大多数情况下（尤其是 KVM/QEMU 的默认虚拟机），应该改为：

<input type='keyboard' bus='ps2'/>

或者，如果你的虚拟机配置里主要用 USB 设备，也可以：

<input type='keyboard' bus='usb'/>

🔧 修改步骤

导出虚拟机配置：

virsh dumpxml <虚拟机名> > /tmp/vm.xml

编辑：
```
vi /tmp/vm.xml
```

找到：

<input type='keyboard' bus='default'/>

修改为：

<input type='keyboard' bus='ps2'/>

如果有：

<input type='tablet' bus='default'/>

也改成：

<input type='tablet' bus='usb'/>

重新定义虚拟机：
```
virsh define /tmp/vm.xml
```
启动虚拟机：
```
virsh start <虚拟机名>
```

✅ 总结

原配置	修改后推荐
`<input type='keyboard' bus='default'/>`	`<input type='keyboard' bus='ps2'/>`
`<input type='tablet' bus='default'/>`	`<input type='tablet' bus='usb'/>`

如果你执行：

virsh capabilities | grep input -A2

看到有 ps2、usb 类型，那这两个选项都没问题。
修改完这个 XML 后，虚拟机即可正常启动，不会再出现 unknown input bus type 'default' 错误。

远程桌面实现方案xrdp

你这台机器运行的是 Kylin V10/V11（基于 RHEL8），系统源的兼容性有点特殊，EPEL 源里 xrdp 依赖的 xorgxrdp 模块和你当前的 Xorg ABI 版本不匹配（报错的关键信息是：xserver-abi(videodrv-24)）。
这种情况很常见，因为银河麒麟（尤其是 V11）对 EPEL 并不完全兼容。
下面我给你几种可行的解决方案：

✅ 方案 1：仅安装 xrdp，不装 xorgxrdp（最简单）

Kylin 默认带桌面环境（如 UKUI），xrdp 可以直接用系统自带的 Xorg 会话，无需 xorgxrdp。

dnf install -y xrdp --nobest --skip-broken

安装完成后：

systemctl enable xrdp --now
firewall-cmd --permanent --add-port=3389/tcp
firewall-cmd --reload

然后在 Windows 上用 “远程桌面连接（mstsc）” 输入服务器 IP 即可登录（默认端口 3389）。

⚠️ 用户要使用系统用户（如 root 或普通用户），如果登录闪退，可编辑 /etc/xrdp/startwm.sh：

vi /etc/xrdp/startwm.sh

在最后添加：

exec /usr/bin/startukui

（或根据桌面环境换成 exec /usr/bin/startlxde、exec /usr/bin/startxfce4）

✅ 方案 2：使用 Kylin 官方提供的 xrdp 包（推荐）

银河麒麟官方源其实已经内置了 xrdp 包，只是有时没启用。

先搜索看看：

dnf search xrdp

如果能看到：

xrdp.x86_64 : Remote Desktop Protocol (RDP) server

直接安装：

dnf install -y xrdp
systemctl enable xrdp --now

✅ 方案 3：手动构建或使用第三方 RPM 包

如果你需要特定版本（例如 EPEL 的不兼容），可以下载兼容的 RPM：

cd /tmp
wget https://rpmfind.net/linux/epel/8/Everything/x86_64/Packages/x/xrdp-0.9.21-1.el8.x86_64.rpm
dnf install -y ./xrdp-0.9.21-1.el8.x86_64.rpm

如果提示缺少依赖，可以加上 --skip-broken 或下载依赖包一并安装。

✅ 验证运行

安装完后，执行以下命令确保运行正常：

systemctl status xrdp
ss -tnlp | grep 3389

输出示例：

LISTEN 0 50 *:3389 *:* users:(("xrdp",pid=1234,fd=3))

此时可在 Windows 上用远程桌面连接输入：

服务器IP:3389

即可。

如果你贴一下以下命令的输出，我可以帮你判断当前环境最适合哪种方案👇

cat /etc/kylin-release
dnf repolist

很好！找到了 `novncd` 的位置：`/opt/webvirtcloud/console/novncd`

现在我们来创建 systemd 服务并启动它。

---

### 解决方案

#### 第1步：检查 novncd 是否可执行

```bash
# 检查文件权限
ls -la /opt/webvirtcloud/console/novncd

# 如果没有执行权限，添加它
sudo chmod +x /opt/webvirtcloud/console/novncd

# 检查是否依赖 Python
file /opt/webvirtcloud/console/novncd
head -n 5 /opt/webvirtcloud/console/novncd
```

#### 第2步：创建 systemd 服务文件

基于找到的路径创建服务文件：

```bash
sudo vi /etc/systemd/system/novncd.service
```

添加以下内容：

```ini
[Unit]
Description=WebVirtCloud NoVNC Proxy Server
After=network.target

[Service]
Type=simple
User=root
Group=root
WorkingDirectory=/opt/webvirtcloud
ExecStart=/opt/webvirtcloud/console/novncd
Restart=always
RestartSec=3
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
```

#### 第3步：启用并启动 novncd 服务

```bash
# 重新加载 systemd 配置
sudo systemctl daemon-reload

# 启动 novncd 服务
sudo systemctl start novncd

# 设置开机自启
sudo systemctl enable novncd

# 检查服务状态
sudo systemctl status novncd
```

#### 第4步：检查服务是否正常运行

```bash
# 检查进程
ps aux | grep novncd

# 检查端口监听（novncd 默认监听 6080 端口）
netstat -tlnp | grep 6080
ss -tlnp | grep 6080

# 查看服务日志
sudo journalctl -u novncd -f
```

---

### 如果服务启动失败，进行故障排除

#### 检查依赖项

```bash
# 检查 Python 环境
cd /opt/webvirtcloud
python3 -c "import django; print('Django OK')"
python3 -c "from console import novnc; print('novnc module OK')"

# 检查 requirements
if [ -f "/opt/webvirtcloud/requirements.txt" ]; then
echo "检查依赖包..."
pip3 list | grep -E "(websockify|django)"
fi
```

#### 手动测试 novncd

```bash
# 切换到目录
cd /opt/webvirtcloud

# 手动启动 novncd 进行测试
/opt/webvirtcloud/console/novncd

# 或者在后台启动
/opt/webvirtcloud/console/novncd &
```

#### 如果手动启动有错误，可能需要安装依赖

```bash
# 安装可能的依赖
sudo pip3 install websockify

# 或者安装所有 requirements
if [ -f "/opt/webvirtcloud/requirements.txt" ]; then
sudo pip3 install -r /opt/webvirtcloud/requirements.txt
fi
```

---

### 配置 WebVirtCloud

确保 WebVirtCloud 配置正确指向 novncd：

检查 WebVirtCloud 配置文件：

```bash
# 查找配置文件
find /opt/webvirtcloud -name "settings.py" -o -name "*.conf" | grep -v __pycache__

# 常见的配置路径
ls -la /opt/webvirtcloud/webvirtcloud/
```

在配置文件中应该有这样的设置：

```python
# 在 settings.py 或配置文件中
NOVNC_HOST = 'localhost' # 或您的服务器IP
NOVNC_PORT = 6080
```

---

### 测试连接

在 novncd 服务运行后，测试连接：

```bash
# 检查端口是否开放
curl -I http://localhost:6080/

# 使用 telnet 测试
telnet localhost 6080

# 或者使用 nc
nc -zv localhost 6080
```

---

### 完整的故障排除流程

如果上述步骤还有问题，请按顺序执行：

```bash
# 1. 停止可能运行的服务
sudo pkill -f novncd

# 2. 检查并安装依赖
sudo pip3 install websockify

# 3. 设置正确的权限
sudo chmod +x /opt/webvirtcloud/console/novncd

# 4. 手动测试运行
cd /opt/webvirtcloud
/opt/webvirtcloud/console/novncd

# 5. 如果手动运行成功，Ctrl+C 停止，然后创建服务
sudo systemctl daemon-reload
sudo systemctl start novncd
sudo systemctl status novncd

# 6. 检查防火墙
sudo firewall-cmd --list-ports
sudo firewall-cmd --add-port=6080/tcp --permanent
sudo firewall-cmd --reload
```

请按照这些步骤操作，然后在每个步骤后告诉我输出结果，这样我可以帮您进一步诊断问题。

太好了！`novncd` 服务现在已经成功运行了：

- ✅ **服务状态**: `active (running)`
- ✅ **进程运行**: PID 30720
- ✅ **端口监听**: `0.0.0.0:6080` 正常监听
- ✅ **开机自启**: 已启用

现在 `novncd` 服务已经正常运行，但 VNC 连接可能仍然有问题。让我们继续排查其他可能的环节。

---

### 下一步排查

#### 第1步：检查虚拟机VNC配置

虽然 `virsh vncdisplay 11` 显示 `:0`，但我们还需要确认VNC配置是否正确：

```bash
# 查看虚拟机的完整VNC配置
virsh dumpxml 11 | grep -A 10 -B 5 "<graphics"

# 或者查看完整的XML配置
virsh dumpxml 11 > /tmp/vm-11.xml
cat /tmp/vm-11.xml | grep -A 10 -B 5 "graphics"
```

**关键检查点：**
- 确认 `<graphics>` 标签中有 `listen='0.0.0.0'`
- 确认没有设置密码导致连接问题

#### 第2步：检查防火墙

确保 VNC 相关端口都开放：

```bash
# 检查防火墙状态（如果是firewalld）
sudo firewall-cmd --list-all

# 开放必要的端口
sudo firewall-cmd --add-port=6080/tcp --permanent
sudo firewall-cmd --add-port=5900-5959/tcp --permanent
sudo firewall-cmd --reload

# 如果是iptables，检查规则
sudo iptables -L -n | grep -E "(6080|5900)"
```

#### 第3步：测试VNC端口连通性

```bash
# 检查虚拟机VNC端口是否可达（:0 对应端口5900）
netstat -tlnp | grep 5900

# 测试本地连接
telnet localhost 5900

# 如果5900端口没有监听，检查其他可能的端口
netstat -tlnp | grep -E ":(59[0-9][0-9])"
```

#### 第4步：检查WebVirtCloud配置

确认WebVirtCloud正确配置了novncd连接：

```bash
# 查找WebVirtCloud配置文件
find /opt/webvirtcloud -name "settings.py" -o -name "*.py" | xargs grep -l "NOVNC\|novnc" | grep -v __pycache__

# 检查常见的配置文件
ls -la /opt/webvirtcloud/webvirtcloud/settings.py
```

在配置文件中应该有这样的设置：
```python
NOVNC_HOST = 'localhost' # 或者您的服务器IP
NOVNC_PORT = 6080
```

#### 第5步：测试novncd到虚拟机VNC的连接

```bash
# 使用websocat或其他工具测试novncd代理
curl -I http://localhost:6080/

# 或者使用wget测试
wget -O- http://localhost:6080/ 2>&1 | head -20
```

#### 第6步：检查SELinux状态

```bash
# 检查SELinux是否启用
getenforce

# 如果是Enforcing模式，尝试临时禁用测试
sudo setenforce 0

# 然后测试VNC连接，如果成功，说明是SELinux问题
```

---

### 快速诊断命令

请运行以下命令并分享输出：

```bash
# 1. 检查虚拟机VNC配置详情
virsh dumpxml 11 | grep -A 10 "<graphics"

# 2. 检查5900端口状态
netstat -tlnp | grep 5900

# 3. 检查防火墙规则
sudo firewall-cmd --list-all 2>/dev/null || sudo iptables -L -n | head -20

# 4. 测试novncd服务响应
curl -s http://localhost:6080/ | head -5

# 5. 检查SELinux
getenforce
```

---

### 如果以上都正常但仍然连接失败

尝试重启相关服务：

```bash
# 重启novncd服务
sudo systemctl restart novncd

# 重启WebVirtCloud服务（如果有）
sudo systemctl restart webvirtcloud # 或者gunicorn、nginx等

# 重启libvirtd服务
sudo systemctl restart libvirtd
```

现在 `novncd` 服务已经正常运行，问题很可能出现在：
1. **虚拟机VNC配置**（特别是listen地址）
2. **防火墙阻止了端口访问**
3. **WebVirtCloud配置**中的novncd地址设置
4. **SELinux策略**

请运行上面的诊断命令，我会根据输出帮您进一步定位问题。

rsync 实现每日增量备份 KVM 虚拟机磁盘

明白，你想用 rsync 实现 每日增量备份 KVM 虚拟机磁盘，并保留虚拟机配置。下面我帮你整理一个 完整可执行方案，适合银河麒麟 V11 + KVM + Libvirt + WebVirtCloud 环境。

1️⃣ 前提条件

两台服务器：
- 主机：/var/lib/libvirt/images/ 存放虚拟机磁盘
- 备份服务器：/backup/libvirt/
主机和备份服务器可通过 SSH 密钥免密登录。
安装 rsync：

dnf install -y rsync

2️⃣ 备份目录结构

建议在备份服务器上保持如下结构：

/backup/libvirt/
    YYYYMMDD/
        images/
        xml/

images/ 存放虚拟机磁盘（qcow2/raw）
xml/ 存放虚拟机配置文件（virsh dumpxml 导出）

3️⃣ 导出虚拟机配置（XML）

备份前导出所有虚拟机配置：

mkdir -p /var/lib/libvirt/backup/xml
for vm in $(virsh list --name); do
    virsh dumpxml "$vm" > /var/lib/libvirt/backup/xml/"$vm".xml
done

这样每台虚拟机的配置都有单独的 XML 文件，可在另一台服务器直接 virsh define vm.xml 恢复。

4️⃣ rsync 增量备份虚拟机磁盘

假设备份服务器 IP 为 192.168.0.100，用户名 backupuser，执行：

# 创建当天备份目录
BACKUP_DATE=$(date +%Y%m%d)
mkdir -p /var/lib/libvirt/backup/images/$BACKUP_DATE

# 同步虚拟机磁盘（增量）
rsync -avh --progress /var/lib/libvirt/images/ backupuser@192.168.0.100:/backup/libvirt/images/$BACKUP_DATE/

rsync 参数说明：

-a：归档模式（保留权限、时间戳、符号链接等）
-v：显示详细信息
-h：人类可读大小
--progress：显示传输进度

5️⃣ 自动化脚本示例

创建 /usr/local/bin/libvirt_backup.sh：

#!/bin/bash

# 备份日期
BACKUP_DATE=$(date +%Y%m%d)

# 本地临时目录
LOCAL_BACKUP_DIR=/var/lib/libvirt/backup
mkdir -p $LOCAL_BACKUP_DIR/xml
mkdir -p $LOCAL_BACKUP_DIR/images/$BACKUP_DATE

# 备份虚拟机 XML 配置
for vm in $(virsh list --name); do
    virsh dumpxml "$vm" > $LOCAL_BACKUP_DIR/xml/"$vm".xml
done

# 备份虚拟机磁盘
rsync -avh --progress /var/lib/libvirt/images/ backupuser@192.168.0.100:/backup/libvirt/images/$BACKUP_DATE/

# 输出完成信息
echo "Backup completed: $BACKUP_DATE"

赋予执行权限：

chmod +x /usr/local/bin/libvirt_backup.sh

6️⃣ 配置每日定时任务

使用 cron：

crontab -e

添加任务（每天凌晨 2 点执行）：

0 2 * * * /usr/local/bin/libvirt_backup.sh >> /var/log/libvirt_backup.log 2>&1

日志记录到 /var/log/libvirt_backup.log，方便排查。

7️⃣ 恢复虚拟机示例

在备份服务器或另一台服务器：

# 复制磁盘和 XML 文件回新服务器
scp backupuser@backupserver:/backup/libvirt/images/20251017/* /var/lib/libvirt/images/
scp backupuser@backupserver:/backup/libvirt/xml/* /var/lib/libvirt/backup/xml/

# 定义虚拟机
for xml in /var/lib/libvirt/backup/xml/*.xml; do
    virsh define "$xml"
done

# 启动虚拟机
virsh start vmname

✅ 特点：

增量备份：rsync 只同步变化文件，节省带宽和存储
自动化：cron 每日执行，无需人工干预
可迁移：备份包含虚拟机配置和磁盘，可直接恢复到另一台服务器

我可以帮你写一个 更智能的脚本，支持：

自动保留最近 7 天/30 天备份
支持在线虚拟机快照备份（减少停机时间）
支持多台虚拟机批量备份

你希望我帮你写这个增强版脚本吗？

银河麒麟 + KVM + WebVirtCloud 虚拟机内存不足8G原因与解决方法

非常好的问题，这种情况在 银河麒麟 + KVM + WebVirtCloud 环境里非常常见。你配置虚拟机为 4 核 8 GB 内存，但虚拟机内系统只显示 6.5 GB 左右，可能由以下几种原因造成👇

🧩 一、宿主机层面：内存超分配或 NUMA 限制

🔹 1. 宿主机可用内存不足

如果宿主机剩余可分配内存小于 8 GB，libvirt 会自动削减虚拟机内存上限。

👉 检查宿主机实际内存：

free -m

若宿主机内存使用已接近上限（例如总 16 GB、已被多台 VM 占用），则虚拟机可能只分到部分物理内存。

🔹 2. NUMA 分区未正确分配

某些 CPU 平台或 BIOS 启用 NUMA（非统一内存访问），虚拟机若被绑定到单个 NUMA 节点，可能只能访问节点局部内存。

👉 检查宿主机 NUMA 拓扑：

numactl --hardware

👉 查看虚拟机 NUMA 绑定情况：

virsh dumpxml vmname | grep -A5 numa

若看到 <numatune> 或 <vcpu placement='static'> 一类的限制，可以删掉或修改为动态。

🧩 二、虚拟机配置层面（Libvirt/QEMU）

查看虚拟机定义文件：

virsh dumpxml vmname | grep -A5 memory

可能会看到：

<memory unit='KiB'>8388608</memory>
<currentMemory unit='KiB'>6815744</currentMemory>

💡 关键区别：

memory 表示最大分配内存（8 GB）
currentMemory 表示当前生效内存（6.5 GB）

🛠️ 解决方法：
修改 XML 或使用命令同步：

virsh setmem vmname 8G --config
virsh setmaxmem vmname 8G --config

然后重启虚拟机：

virsh destroy vmname
virsh start vmname

🧩 三、模板或镜像层面

如果你使用的是 WebVirtCloud 模板镜像（内置系统模板）：

某些模板镜像里预设了 cloud-init 或 virt-sysprep 的限制，自动下调虚拟内存；
特别是从 qcow2 模板克隆出来时，currentMemory 通常被固定为镜像生成时的值。

👉 你可以用以下命令验证：

grep -A5 "<memory" /etc/libvirt/qemu/*.xml | grep -B1 currentMemory

如发现模板都只配置 6815744 KiB（≈ 6.5 GB），需要更新模板 XML。

🧩 四、虚拟机内部系统

确认不是系统层限制：

dmesg | grep -i memory

如果看到类似：

Memory limited to 6G due to ACPI or BIOS setting

说明虚拟 BIOS (OVMF/SeaBIOS) 或 grub 配置限制了内存。

检查：

cat /proc/cmdline

若存在 mem=6G，删除此参数并更新 grub：

vi /etc/default/grub
grub2-mkconfig -o /boot/grub2/grub.cfg

✅ 综合建议（推荐修复顺序）

检查虚拟机 XML 配置：
```
virsh dumpxml vmname | grep -A5 memory
```
若 currentMemory < memory → 按上面方法调整。
确认宿主机资源是否足够（free -m）。
重新启动虚拟机后再查看：
```
free -mh
```

如果仍不对，可清理模板继承：

virsh undefine vmname
virsh define /path/to/vmname.xml

如果你愿意，我可以帮你写一个 自动检测+修复虚拟机内存配置的小脚本（一键同步 currentMemory 和 memory），以便后续新建虚拟机不再出现这种情况。是否帮你生成？

非常好，你提供的关键信息说明问题不在宿主机资源或 libvirt 配置层面。
我们来逐步分析你的情况👇

✅ 一、已确认情况

项目	状态
宿主机内存	62 GiB 可用，非常充足
虚拟机定义	`<memory>` 与 `<currentMemory>` 都是 8 GiB (8388608 KiB)
CPU 配置	4 核
NUMA	没定义（正常）
实际虚拟机内内存	6.5 GiB 左右

👉 说明：
宿主机和 libvirt XML 都是正确的，虚拟机内部显示 6.5 GiB，极可能是虚拟机系统内部（guest OS）限制了内存识别。

🧩 二、在虚拟机内部进一步检查

请进入虚拟机内部执行以下命令排查：

1️⃣ 检查内核参数是否限制内存

cat /proc/cmdline

如果输出中包含：

mem=6G

说明 grub 启动参数限制了内存识别。

🔧 解决：
编辑 /etc/default/grub，去掉 mem= 参数，例如：

GRUB_CMDLINE_LINUX=""

然后更新 grub 配置并重启：

grub2-mkconfig -o /boot/grub2/grub.cfg
reboot

2️⃣ 检查系统是否识别全部内存

dmesg | grep -i memory

关注是否出现：

Memory limited to 6G due to ACPI or BIOS setting

或

usable memory = 6815744k

如果出现类似日志，说明虚拟 BIOS 报告的内存有限。

🧩 三、检查虚拟机 BIOS（QEMU 机器类型）

你虚拟机的定义中是：

<type arch='x86_64' machine='pc-q35-8.2'>hvm</type>

在某些银河麒麟 V11（基于 RHEL8 内核）环境中，
Q35 机型 + 某些 BIOS 版本（SeaBIOS/OVMF）会导致内存映射 bug，
导致 guest 系统只能识别 6.x GB。

🔧 解决办法：改成传统 i440fx 机型。

执行：

virsh edit rulr-1

找到：

<type arch='x86_64' machine='pc-q35-8.2'>hvm</type>

改为：

<type arch='x86_64' machine='pc-i440fx-8.2'>hvm</type>

保存退出，然后重启虚拟机：

virsh destroy rulr-1
virsh start rulr-1

之后进入系统再执行：

free -mh

通常就会显示 8 GiB 了。

🧩 四、确认虚拟机使用的是标准 BIOS 而非 OVMF（UEFI）

部分模板在 WebVirtCloud 中默认启用了 OVMF (UEFI) 固件，
而部分旧内核（尤其是银河麒麟桌面内核）在 UEFI 模式下存在 ACPI table truncation bug。

👉 检查方式：

virsh dumpxml rulr-1 | grep loader

如果你看到：

<loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>

说明使用的是 OVMF。

🔧 改为传统 BIOS 启动：
在 XML 文件中删除 <loader> 和 <nvram> 段落，重启虚拟机。

🧩 五、建议最终检查项

如果以上修改后仍显示 6.x GB：

尝试换一个 Linux 镜像（如 CentOS 8/Ubuntu 20.04）验证是否识别 8 GB；
如果识别正常，说明是 银河麒麟 guest 内核 bug；
可尝试升级内核或应用官方补丁（yum update kernel）。

✅ 总结

可能原因	检查项	修复建议
Guest grub 参数限制	`/proc/cmdline` 有 `mem=`	删除参数、重建 grub
BIOS 报告内存错误	`dmesg` 中有 ACPI 提示	改为 i440fx 机型
UEFI/OVMF 映射 bug	XML 中含 `<loader>`	删除 loader 段，改用传统 BIOS
银河麒麟内核 bug	特定版本	更新内核或换标准机型

非常好，这两段输出信息已经能说明问题所在。我们来仔细分析👇

✅ 一、关键日志分析

从你的 dmesg 输出中有两行非常重要：

[    0.013838] kexec_core: Reserving 256MB of low memory at 1776MB for crashkernel (System low RAM: 2047MB)
[    0.013839] Reserving 1024MB of memory at 9200MB for crashkernel (System RAM: 8191MB)

这表明：

系统识别到了 8 GB 内存（8191MB）；
但是因为启用了 crashkernel=1024M,high，有 1 GB 内存被保留；
再加上一些 BIOS/显存保留区，你最终看到的 “可用内存” 大约就是 6.5 GB 左右。

也就是说：

虚拟机的内存没问题，只是被 crashkernel（内核崩溃转储保留区）占用了。

🧩 二、为什么会这样？

银河麒麟（Kylin V10/V11）默认启用了 kdump 崩溃转储机制，
在 grub 启动参数中会自动加上：

crashkernel=1024M,high

这会强制预留 1 GB 的内存供 kdump 使用。

🛠 三、解决办法（释放这 1 GB 内存）

如果你只是实验或测试环境，不需要启用内核转储功能，可以直接关闭这一项。

1️⃣ 编辑 grub 配置

vi /etc/default/grub

找到这行：

GRUB_CMDLINE_LINUX="... crashkernel=1024M,high ..."

将 crashkernel=1024M,high 删除或注释掉：

GRUB_CMDLINE_LINUX="ro rhgb quiet audit=0"

保存退出。

2️⃣ 重新生成 grub 配置

如果是 BIOS 启动：

grub2-mkconfig -o /boot/grub2/grub.cfg

如果是 UEFI 启动：

grub2-mkconfig -o /boot/efi/EFI/kylin/grub.cfg

3️⃣ 重启系统

reboot

然后再次查看内存：

free -mh

应该能看到大约 7.5 ~ 7.8 GiB 的可用内存。

✅ 四、补充建议

如果你仍想保留 crashkernel，可以适当减小保留内存，例如：
```
crashkernel=256M,high
```
这样只占用 256 MB，不影响 kdump 功能。
若是批量模板虚拟机，可以在母盘模板中修改 /etc/default/grub 后重新制作镜像。

🔍 总结

问题根因	解决方案
银河麒麟默认启用 crashkernel=1024M 保留区，导致内存少 1 GB+	删除或减小 crashkernel 参数后更新 grub 并重启

是否希望我帮你写一个脚本，一键自动检测并修复（删除 crashkernel、重建 grub、提示是否重启）？

KVM安装win11

win11安装

1、创建空磁盘
2、新建xml文件，cdrom启动
3、下载驱动virtio-win-0.1.225.iso 访问密码: 2344
4、启动虚拟机，开始安装
5、无法识别磁盘，挂载驱动
virsh domblklist bendi(虚拟机名称) 查看磁盘分配

virsh change-media win11-1 sda /var/lib/libvirt/images/virtio-win-0.1.225.iso 挂载驱动镜像，镜像路径要绝对路径
6、安装界面加载驱动
7、加载完驱动，重新挂载安装镜像
virsh change-media win11-1 sda /var/lib/libvirt/images/win11_24h2.iso

8、选择磁盘安装系统
因为上面的操作，win10和win11安装步骤差不多，所有就把win10的笔记弄过来了****
这个报错是因为Windows11强制要求安装的机器上必须开启TPM2.0

在虚拟机中按住快捷键Shift+F10打开终端界面
输入regedit打开注册表，在HKEY_LOCAL_MACHINE\SYSTEM\Setup右击新建一个项，命名为LabConfig，在该项右击新建三个DWORD (32位) 值，分别命名为BypassTPMCheck、BypassRAMCheck、BypassSecureBootCheck，并将这三个值都设置为1

切换驱动ISO

[root@localhost images]# virsh change-media win11-1 sda /var/lib/libvirt/images/win11_24h2.iso
Successfully updated media.
[root@localhost images]# virsh domblklist win11-1
 Target   Source
--------------------------------------------------
 vda      /var/lib/libvirt/images/win11-1.qcow2
 sda      /var/lib/libvirt/images/win11_24h2.iso

切换完成后，加载驱动

根据芯片和系统版本找到对应的驱动安装

安装完成驱动后，切换回镜像ISO，继续安装系统

如果到了“让我们为你连接到网络”这步，我们需要联网才可以进行下一步操作，不联网的情况下，无法像win10系统一样跳过，其实我们可以通过命令来跳过联网激活页面，

在“让我们为你连接到网络”的页面中，在电脑键盘上同时按下快捷键“Shift+F10”，或者是“Shift+Fn+F10”，便可打开命令提示符，如下图所示。

在命令提示符中，我们输入"oobe\BypassNRO.cmd"，按下回车执行命令即可。

重新设置到网络页面，选择"我没有Internet连接"，再选择"继续执行受限设置，即可直接进入系统，跳过win11联网激活。
安装后

安装完成且VM已启动后，下一步是安装来宾代理并解决所有丢失的驱动程序。

客座代理

必须安装来宾代理。

虚拟机管理程序使用来宾代理直接与VM通信。
在任务栏上，单击“文件资源管理器”。请添加图片描述
选择“此PC”，然后双击“ CD驱动器（D 😃 virtio-win-0.1.225”。
访客代理是干净VM关机和启用VM映像实时快照所必需的
打开“来宾代理”文件夹。
virtio-win-gt-x64.msi 访问密码: 2344
右键单击“ qemu-ga-x64”文件，然后选择“安装”
安装后，必须先完全关闭VM，然后才能运行代理。

再次启动VM时，访客代理服务将自动启动

右键单击“以太网控制器”，然后选择“更新驱动程序软件…

选择“浏览我的计算机以获取驱动程序软件

选择“ CD驱动器（D 😃 virtio-win-0.1.225”，然后单击“确定”
安装好后是这样的

Hyper-V 实时迁移（Live Migration）的身份验证方式配置错误解决方法

非常好，这个错误日志很完整，我可以明确告诉你：
这是 Hyper-V 实时迁移（Live Migration） 的 身份验证方式配置错误 引起的，根本原因是：

🧩 “Credential Guard 开启 → CredSSP 不可用 → 迁移凭据验证失败 (0x8009030E)”

⚠️ 错误分析简要说明

错误核心：

安全包中没有可用的凭证 (0x8009030E)
CredentialGuard 不兼容 CredSSP

说明：

默认情况下，Hyper-V 的迁移认证机制是 CredSSP（基于交互登录的凭证传递）；
但在 Windows Server 2022 / 2025 上，Credential Guard 默认启用，会阻止 CredSSP；
所以要迁移成功，你必须改为使用 Kerberos 身份验证，并配置 受限委派 (Constrained Delegation)。

✅ 正确启用 Hyper-V 迁移（Kerberos 模式）

一、确保两台主机在同一域中

例如：

SC-S1.SHUNCOM.LOCAL
S-FACTORY02.SHUNCOM.LOCAL

都加入同一个域 SHUNCOM.LOCAL，并能互相解析主机名（DNS 正常）。

二、在“Hyper-V 设置”中启用迁移

在两台主机上都执行：

1️⃣ 打开 Hyper-V 管理器
2️⃣ 点击左侧主机名 → 右键 → “Hyper-V 设置”
3️⃣ 选择左侧 “实时迁移”

勾选 “允许此计算机发送和接收实时迁移的虚拟机”
4️⃣ 点击 “高级功能”：
选择 使用 Kerberos 身份验证
迁移性能 → 允许 TCP/IP 连接（默认 6600 端口）

三、在 Active Directory 中启用受限委派

在域控上执行（或在 AD 用户和计算机中操作）：

1️⃣ 打开 Active Directory 用户和计算机 (dsa.msc)
2️⃣ 找到源主机帐户，例如：S-FACTORY02$
3️⃣ 右键 → 属性 → “委派”选项卡
4️⃣ 选择：

信任此计算机仅委派指定服务到指定用户或计算机（仅 Kerberos）

5️⃣ 点击 “添加”：

选择目标主机 SC-S1

勾选服务类型：

cifs
Microsoft Virtual System Migration Service

即同时选中这两个服务。

6️⃣ 确认保存，等待 AD 同步。

四、配置防火墙（如有开启）

在两台主机上都执行（管理员 PowerShell）：

Enable-NetFirewallRule -DisplayGroup "Hyper-V"

或手动开放：

TCP 6600

五、重启 Hyper-V 服务

两台主机都执行：

Restart-Service vmms

六、使用 Kerberos 模式发起迁移

在 Hyper-V 管理器中：
1️⃣ 右键虚拟机 → “移动”
2️⃣ 选择 “将虚拟机移至另一台计算机”
3️⃣ 输入目标主机 FQDN（例如 SC-S1.shuncom.local）
4️⃣ 完成迁移向导

如果配置正确，此时迁移应成功完成，不再报 (0x8009030E)。

🧰 备用方案（临时迁移）

如果你只想临时完成一次迁移，不想动域策略：
你可以使用 导出 / 导入 方式：

在源主机：

Export-VM -Name "VMName" -Path "D:\Export"

在目标主机：

Import-VM -Path "D:\Export\VMName"

这种方式绕过了实时迁移认证机制。

✅ 总结要点

项目	默认设置	推荐修复
身份验证模式	CredSSP	✅ 改为 Kerberos
Credential Guard	默认启用	✅ 保留启用，无需关闭
委派配置	无	✅ 启用受限委派 (cifs + migration service)
防火墙	可能阻挡	✅ 开放 Hyper-V 相关规则

我可以帮你生成一份 域控受限委派配置的 PowerShell 脚本（自动完成步骤3）
是否要我帮你生成？

管理QEMU虚拟化平台常用的运维命令

管理QEMU虚拟化平台，确实需要熟悉一些常用的运维命令。为了让你能快速了解和掌握，下面这个表格汇总了核心的管理领域及其关键命令：

### 🖥 虚拟机日常管理（virsh）

`virsh` 是一个功能强大的命令行工具，用于管理使用libvirt创建的虚拟机。

- **查看虚拟机状态**：使用 `virsh list --all` 可以列出所有虚拟机，包括它们的ID、名称和当前状态（运行中、关闭等）。
- **启动与停止**：
- `virsh start <虚拟机名>` 启动一个虚拟机。
- `virsh shutdown <虚拟机名>` 优雅地关闭虚拟机。
- `virsh reboot <虚拟机名>` 重启虚拟机。
- `virsh destroy <虚拟机名>` 强制关闭虚拟机（相当于直接断电，慎用）。
- **挂起与恢复**：
- `virsh suspend <虚拟机名>` 挂起（暂停）虚拟机。
- `virsh resume <虚拟机名>` 恢复被挂起的虚拟机。

### 💾 虚拟磁盘操作（qemu-img）

`qemu-img` 专门用于处理虚拟机的磁盘镜像文件。

- **创建磁盘**：`qemu-img create -f <格式> <文件名> <大小>`。例如，`qemu-img create -f qcow2 ubuntu-server.qcow2 20G` 会创建一个20GB、使用qcow2格式的磁盘镜像。qcow2格式支持快照和动态扩容，非常常用。
- **检查磁盘**：`qemu-img check <文件名>` 可以检查磁盘镜像的一致性，确保没有损坏。
- **转换格式**：`qemu-img convert -f <原格式> -O <目标格式> <输入文件> <输出文件>`。例如，将RAW格式转换为QCOW2：`qemu-img convert -f raw -O qcow2 disk.img disk.qcow2`。
- **调整大小**：`qemu-img resize <文件名> <新大小>` 可以调整磁盘镜像的容量。例如，`qemu-img resize disk.qcow2 +5G` 为磁盘增加5GB空间。**注意**：调整磁盘镜像大小后，通常还需要在虚拟机内部调整分区和文件系统大小才能使用新增空间。

### 🔧 高级运维技巧

- **使用QEMU Monitor**：QEMU Monitor是一个与QEMU实例交互的控制台。如果你直接使用`qemu-system-x86_64`命令启动虚拟机，可以按**Ctrl+Alt+2**（或使用`-monitor stdio`参数）切换到Monitor界面。在这里可以执行许多高级操作：
- **设备热添加**：使用 `device_add` 命令可以在虚拟机运行时添加新的设备，如硬盘。
- **内存气球**：如果虚拟机使用了virtio-balloon设备，可以通过 `balloon <内存大小(MB)>` 命令动态调整分配给虚拟机的内存。
- **信息查询**：使用 `info` 系列命令（如 `info block`、`info cpus`）可以详细查看虚拟机的硬件状态和运行信息。
- **创建虚拟机**：虽然可以使用 `virt-install` 命令方便地创建新虚拟机，但理解其参数有助于更灵活地管理：
```bash
virt-install --name myvm --memory 2048 --vcpus 2 --disk size=20 --cdrom /path/to/iso --network bridge=br0 --graphics vnc
```
- **快照管理**：快照可以保存虚拟机在某一时刻的状态，便于回滚。
- **创建快照**：`virsh snapshot-create-as <虚拟机名> <快照名>`。
- **查看快照**：`virsh snapshot-list <虚拟机名>`。
- **恢复快照**：`virsh snapshot-revert <虚拟机名> <快照名>`。

### 💎 运维实践建议

1. **定期检查磁盘镜像**：使用 `qemu-img check` 定期检查重要的磁盘镜像，防患于未然。
2. **调整磁盘大小时务必谨慎**：**强烈建议**在调整磁盘大小前先关闭虚拟机并备份磁盘镜像，因为此操作有一定风险。
3. **善用监控和日志**：结合QEMU Monitor的 `info` 命令和系统日志（如`journalctl`），可以更好地诊断虚拟机运行中的问题。

希望这些命令和技巧能帮助你更高效地管理QEMU虚拟化平台。如果你在具体操作中遇到问题，或者想了解某个命令的更多细节，欢迎随时告诉我。

Hyper-V + Ubuntu 18.04 环境下尽最大可能阻止虚拟机被克隆

在 Hyper-V + Ubuntu 18.04 环境下，你可以采取多层手段来尽最大可能阻止虚拟机被克隆或被克隆后继续正常使用。
要说明的是：完全 100% 防止克隆是不可能的（因为管理员永远可以复制 VHDX）。
但我们可以做到：

✔ 克隆后自动失效
✔ 克隆后业务无法运行
✔ 让克隆无意义

以下给你最有效、最实用的方案组合。

✅ 方案一：使用系统级唯一 ID 校验（最通用、最有效）

思路：
每次开机时脚本检查系统硬件 ID 是否与预设一致。
如果被克隆到其他机器（UUID/MAC 变化），则自动停机或锁定系统。

1）生成当前系统的 UUID、MAC

cat /sys/class/dmi/id/product_uuid
ip link show | grep ether

2）把这些值保存到一个文件，比如：

/etc/vm_protect.conf：

UUID=4C4C4544-0056-3110-804B-B6C04F39324A
MAC=00:15:5D:22:33:44

3）创建校验脚本

/usr/local/bin/check_clone.sh：

#!/bin/bash

CONF="/etc/vm_protect.conf"
UUID_NOW=$(cat /sys/class/dmi/id/product_uuid)
MAC_NOW=$(ip link show eth0 | grep ether | awk '{print $2}')

UUID_OK=$(grep UUID $CONF | cut -d= -f2)
MAC_OK=$(grep MAC $CONF | cut -d= -f2)

if [[ "$UUID_NOW" != "$UUID_OK" ]] || [[ "$MAC_NOW" != "$MAC_OK" ]]; then
    echo "Cloned or moved VM detected!" >> /var/log/clone_detect.log
    shutdown -h now
fi

4）加入 systemd 开机检查

/etc/systemd/system/checkclone.service：

[Unit]
Description=Clone Detection Service
Before=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/check_clone.sh

[Install]
WantedBy=multi-user.target

启用：

chmod +x /usr/local/bin/check_clone.sh
systemctl enable checkclone.service

📌 效果

✔ 虚拟机克隆后 UUID / MAC 不一致
✔ 会在启动阶段自动 shutdown
✔ 克隆的副本永远无法正常运行

这类方法是企业私有云最常用的反克隆策略。

✅ 方案二：使用 TPM + Secure Boot + BitLocker / LUKS

如果你使用 第二代 Hyper-V 虚拟机（Generation 2）
你可以：

启用 虚拟 TPM（vTPM）
启用 Secure Boot
使用 Ubuntu 的 LUKS 全盘加密

原理：

虚拟机克隆后：

vTPM 状态不完整
BitLocker/LUKS 解密失败
系统无法正常启动

✔ 是最难绕过的方式之一。

✅ 方案三：在业务层做反克隆（尤其适用于服务器）

例如：

1）程序启动时校验机器指纹

✔ hostname
✔ UUID
✔ 虚拟网卡 MAC
✔ 公钥指纹
✔ CPU 序列号（虚拟 CPU 也能读到虚拟序列）

并生成一个 授权文件

授权文件与硬件绑定，被克隆后：

❌ 没有授权
❌ 无法运行业务
✔ 比系统层更灵活

❌ 方案四：禁用“复制 VHDX” —— 不可行

Hyper-V 本身不提供禁止管理员复制 VHDX 的功能，因此底层无法阻止克隆。

🔥 最推荐方案（最佳组合）

如果你希望 极难被克隆、克隆后一定无法用，用下面组合：

✔（1）系统 UUID + MAC 开机校验

✔（2）Hyper-V Generation 2 + vTPM + Secure Boot

✔（3）LUKS 加密并绑定 vTPM

✔（4）业务启动授权校验（最高级别）

这样克隆出来的虚拟机基本上：

无法解密磁盘
无法通过授权
无法开机/无法运行业务
克隆者无意义

如果你愿意，我可以为你的 Ubuntu 18.04 Hyper-V 虚拟机

✦ 自动生成完整反克隆脚本
✦ 自动绑定你的当前 UUID/MAC
✦ 给你 systemd 单元文件
✦ 给你 TPM + LUKS 加密方案
✦ 或者实现业务级别授权机制

告诉我你目前使用 Generation 1 还是 2？
我可以给你最合适的方案。

Hyper-V 解除IOPS限制的方法

下面是对你这段 iostat -x 输出的深入分析，以及 是否可以解除 Hyper-V 限制 的结论。

✅ 一、iostat 输出说明了什么？

从多次采样来看，关键指标如下：

指标	数值	说明
w/s	430～460 次/s	写操作 QPS，很低
wkB/s	4300～5900 KB/s（≈4–6 MB/s）	吞吐量极低
svctm	2.0～2.3 ms	单次 IO 服务时间偏慢
await	2.3～2.8 ms	IO 等待时间偏慢
%util	90%～99%	磁盘已跑满（队列挤爆）
aqu-sz	1.0～1.2	队列排队明显
wrqm/s	500～580	合并写非常多 → 超过 50%

✔ 结论：你的磁盘（虚拟磁盘）读写能力极弱，被 Hyper-V 虚拟化能力完全限制住了

因为：

物理 SSD 最起码应该能提供几十万 IOPS（NVMe）或至少 5k–10k IOPS（SATA SSD）
但你这里只能跑到 ~450 IO/s（写），属于 机械硬盘都嫌丢人的速度。
util 达到 90%～99% → 表示 磁盘队列已经满了，磁盘瓶颈已出现。
Hyper-V 默认给虚拟机的磁盘 严重受限（存储 QoS 默认值、虚拟磁盘类型、控制器类型等）。

⚠ 这不是 fio 的问题，而是 Hyper-V 层限制虚拟机磁盘性能

✅ 二、为什么 fio 测试只有 17k IOPS，而 iostat 中只有 450 IOPS？

因为：

fio 测的是随机读 IOPS

→ Hyper-V 读缓存 影响非常大

iostat 测的是真实落盘写 IOPS

→ Hyper-V 关闭写缓存（默认）+ VHDX 文件 + virtual SCSI 单队列
→ 写性能极差

读（fio）与写（iostat）完全不是同一类型 I/O，不会表现一致。

🚫 三、是否可以解除 Hyper-V 限制？— 可以！

下面给你完整的解锁方案，从影响最大到最小排序。

⭐ 方案 1：关闭 Hyper-V 存储 QoS 限制（最重要）

检查当前限制：

Get-VM | Get-VMHardDiskDrive | Get-StorageQoSFlow

如果看到 I/O Read/Write Limit（如 500 IOPS），说明被限速了。

关闭限速：

Set-VMHardDiskDrive -VMName "YourVM" -ControllerType SCSI -QoSPolicyID $null

⭐ 方案 2：使用固定大小 VHDX（Fixed VHDX）

千万不要用动态扩展的 VHDX（Dynamic），会严重影响 IOPS

查看 VHD 类型：

Get-VHD -Path "D:\VM\xxx.vhdx"

如果是 Dynamic → 性能差

转换为 Fixed：

Convert-VHD -Path "xxx.vhdx" -DestinationPath "xxx-fixed.vhdx" -VHDType Fixed

⭐ 方案 3：使用 NVMe 直通（如果物理机支持）

Hyper-V 支持 “PCIe Pass-through（DDA）”，可直通 NVMe 到虚拟机

性能 = 物理盘性能 × 100%

⭐ 方案 4：给虚拟机磁盘启用写缓存

Set-VMHardDiskDrive -VMName VMName -DiskNumber X -SupportPersistentReservations $True

宿主机设备管理器中：

存储控制器 → 属性 → 策略
✔ 勾选 启用写缓存

⭐ 方案 5：使用 SCSI 控制器而不是 IDE

Hyper-V 建议：

IDE：仅用于引导盘（性能差）
SCSI：用于数据盘（多队列支持更好）

⭐ 方案 6：提高虚拟机队列深度

在 VM 中：

echo 1024 | sudo tee /sys/block/sdb/queue/nr_requests

⭐ 方案 7：把 VHD 放在独立 NVMe 或 RAID10 上

如果 VHD 在 SATA 盘或 NAS 上 → 性能必然差

🧪 四、判断 Hyper-V 是否仍然限制的方法

运行：

fio --name=readtest --filename=/dev/sdb --rw=randread --bs=4k --iodepth=64 --numjobs=4 --runtime=10 --ioengine=libaio --direct=1

如果 IOPS < 50k（NVMe）或 < 8k（SATA SSD） → 仍然存在虚拟化限制

📌 五、你的情况总结

你的真实表现：

● fio 随机读：17k IOPS

可以，但偏低（NVMe 应 300k+）

● iostat 实际写入：460 IOPS

极低 → 大概率原因：

虚拟磁盘为 动态 VHDX
Hyper-V 存储 QoS 默认限速
宿主写缓存被禁用
虚拟磁盘挂在 IDE 控制器上

✅ 我可以根据你的 Hyper-V 配置（VM 设置截图或 Get-VHD 输出）为你制定解除限速的精准方案。

如果方便，请贴出：

Get-VHD -Path yourdisk.vhdx
Get-VMHardDiskDrive -VMName YourVM
Get-StorageQoSFlow

我可以直接告诉你哪一项限制了性能、如何解除。

下面我给你 最完整的一套操作指南，用于 解除 Hyper-V 本地虚拟机的 IOPS 限制，包含所有你提到的内容，并且按优先级排序（从提升效果最大到次要）。
这套方法尤其适用于：单台物理机 + 本地磁盘阵列 + Hyper-V 虚拟化。

✅ 一、把 VHDX 从动态扩展改为固定大小（最重要 / 提升 3~10 倍 IOPS）

✔ 固定大小 VHDX 带来的提升

动态扩展 VHDX 每写一次要：
扩展元数据 → 写入数据 → 更新内部块结构
这是 Hyper-V 最慢的部分。
固定大小 = 物理文件已分配 = IO 路径最短

📌 操作步骤

# 把动态扩展 VHDX 转换为固定大小
Convert-VHD -Path "D:\hyperv\rulr-7-mysqldb-sys\disk.vhdx" -DestinationPath "D:\hyperv\rulr-7-mysqldb-sys\disk_fixed.vhdx" -VHDType Fixed

转换后：

修改虚拟机使用固定盘

关机虚拟机
Hyper-V 管理器 → 虚拟机 → 设置
找到“硬盘” → 选择新 fixed.vhdx
启动即可

✅ 二、关闭 Windows 防病毒（Defender）对 VHDX 的实时扫描（提升 IOPS 1～3 倍）

Defender 会导致：

写 VHDX 时触发全盘扫描
IOPS 降低 50~80%（微软官方已确认）

✔ 排除 VHDX 目录：

Add-MpPreference -ExclusionPath "D:\hyperv"

也可关闭实时保护（不推荐生产，但可测试性能）：

Set-MpPreference -DisableRealtimeMonitoring $true

✅ 三、Host 主机磁盘策略改为 “High Performance”（非常关键）

Hyper-V 使用 Windows Storage Stack，默认是 Balanced。

修改策略

Get-PhysicalDisk | Set-PhysicalDisk -MediaType HDD
Get-StorageSetting | Set-StorageSetting -NewDiskPolicy OnlineAll

✅ 四、优化 Hyper-V NUMA 与 vCPU（很关键）

方法：

✔ 检查当前 NUMA 拓扑

Get-VMHostNumaNode

✔ 给单虚拟机分配 CPU < NUMA 节点上限

例如：你的 CPU 单节点 16 核 → VM 不超过 16 vCPU

避免跨 NUMA = 延迟下降 30～200 微秒

Hyper-V 设置：

Hyper-V 管理器 → 虚拟机 → 设置 → 处理器
取消勾选  “将虚拟机跨 NUMA 节点运行”

✅ 五、虚拟机内部优化 I/O Scheduler（Ubuntu / Debian）

默认 scheduler 为 mq-deadline，一般 OK
但针对数据库或高 IOPS：

✔ 查看当前 scheduler：

cat /sys/block/sda/queue/scheduler

✔ 推荐：`none`（虚拟化最佳）

echo none | sudo tee /sys/block/sda/queue/scheduler

永久生效：

sudo nano /etc/default/grub

加入：

GRUB_CMDLINE_LINUX_DEFAULT="scsi_mod.use_blk_mq=1 elevator=none"

更新：

sudo update-grub

✅ 六、正确压测虚拟机 IOPS（fio 完整参数）

你的目标是测 IOPS 上限：

✔ 随机读取 IOPS

fio --name=randread --ioengine=libaio --rw=randread --bs=4k --numjobs=4 --iodepth=32 \
--size=1G --runtime=30 --direct=1 --time_based --filename=/testfile

✔ 随机写 IOPS

fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=4k --numjobs=4 --iodepth=32 \
--size=1G --runtime=30 --direct=1 --time_based --filename=/testfile

✔ 混合读写（数据库负载）

fio --name=mix --ioengine=libaio --rw=randrw --rwmixread=70 \
--bs=4k --numjobs=4 --iodepth=32 --size=1G --runtime=30 --direct=1 \
--time_based --filename=/testfile

摄入注意：

--direct=1 绕过缓存
iodepth=32 Hyper-V 最优
numjobs=4 接近 CPU core 数效果最好

✅ 七、关闭 Hyper-V 的 Host Cache（避免 IOPS 被吞）

虚拟机 → 硬盘 → 禁用“主机 I/O 缓存”
否则 IOPS 会抖动，测不准。

🔥 最终可达 IOPS（本地 HDD/SSD 阵列）

存储配置	动态 VHDX	固定 VHDX 优化后
RAID1 HDD	150~300 IOPS	500~1200 IOPS
RAID5 HDD	50~200 IOPS	400~900 IOPS
SSD RAID10	10k~20k	30k~60k+

你的环境（RAID1 / RAID5）优化后都能提升 3～6 倍。

如果你愿意，我可以帮你：

✔ 根据你的 CPU NUMA 拓扑
✔ 根据你硬盘型号
✔ 根据你 VHDX 类型
✔ 根据你 Hyper-V 配置
👉 给你生成一套定制化的优化脚本（PowerShell + Linux）

只要你把以下信息给我：

1. Get-VMHostNumaNode
2. Get-VM | fl Name,ProcessorCount,MemoryAssigned
3. Get-VHD -Path *你的vhdx路径*
4. RAID盘的型号、RAID模式、阵列卡型号

我可以让你的 Hyper-V 性能发挥到极限。

在 Hyper-V 物理宿主机上把网卡的 Virtual Machine Queues（VMQ）设为 Disabled会产生以下实际后果

在 Hyper-V 物理宿主机 上把网卡的 Virtual Machine Queues（VMQ）设为 Disabled，会产生以下实际后果，我给你讲最关键、最贴近实战的点：

一、VMQ 的作用一句话说明

VMQ 的作用：
让物理网卡直接把数据包分发到对应虚拟机的队列，减少 CPU 参与，提高吞吐量和并发能力。

简化理解：

状态	数据路径
VMQ 启用	网卡 → 虚拟机专属队列 → 虚拟机
VMQ 禁用	网卡 → CPU 软中断 → 软件分发 → 虚拟机

二、禁用 VMQ 的直接后果

1. 网络性能明显下降

禁用后会出现：

网络延迟变高
单虚机带宽变窄
PPS（包转发能力）下降

特别明显的场景：

大量小包业务（数据库、缓存、MQ）
高并发 Web
虚拟交换机负载较高的宿主机

2. CPU 负载上升

禁用 VMQ 后：

网络中断会集中消耗 宿主机 CPU
Rx 软中断明显升高
CPU Interrupt / DPC 时间变高

你可能会看到：

宿主机 CPU Usr 不高，但 System Interrupts 明显
性能监视器里 Processor(_Total)\% DPC Time 偏高

三、什么时候反而建议禁用 VMQ

不是所有场景都“必须开 VMQ”，以下情况禁用反而更稳：

1. 网卡驱动对 VMQ 支持不稳定

老型号网卡 / 某些驱动版本常见问题：

丢包
网卡重置
虚机周期性断网
EventLog 出现：

Microsoft-Windows-Hyper-V-VmSwitch
The network adapter has reset (原因：VMQ)

2. 虚机数量很少、带宽压力不大

例如：

只有 1～2 台虚机
都是管理用途或轻负载系统

3. 配合 SR-IOV / RSS 场景

如果你已经启用：

SR-IOV
RSS（接收端缩放）

VMQ 的收益会变小，有时会冲突。

四、禁用 VMQ 最典型的“症状表现”

如果你已经禁用了 VMQ，常见现象是：

✅ 宿主机更“稳定”，断流丢包问题减少
❌ 虚拟机带宽比以前变小
❌ 高并发时延迟增加
❌ CPU 中断时间上升

五、你的场景给你一句实战建议

根据你之前的使用习惯（Hyper-V + 高 IOPS + 多虚机 + 性能调优），我给你一个很实用的判断标准：

✅ 如果你追求 最大性能 → 不建议关闭 VMQ
✅ 如果你追求 稳定性，曾遇到虚机断网 / 丢包 → 可以关闭 VMQ

六、推荐的稳妥配置组合（生产环境常用）

在 Hyper-V 里比较稳的组合是：

功能	推荐状态
VMQ	✅ 启用
RSS	✅ 启用
SR-IOV	视网卡支持情况
网卡中断调节	适当降低

七、快速查看当前 VMQ 状态（给你个常用命令）

Get-NetAdapterVmq

启用 VMQ：

Set-NetAdapterVmq -Name "Ethernet0" -Enabled $true

禁用 VMQ：

Set-NetAdapterVmq -Name "Ethernet0" -Enabled $false

总结一句给你：

禁用 VMQ 的核心后果是：
稳定性可能更好，但吞吐量和并发能力会明显下降，同时 CPU 中断负载会上升。

如果你愿意告诉我你宿主机型号 + 网卡型号（比如 X710、82599、Mellanox CX4 等），我可以帮你给出更精准的优化建议。

你这个信息很好 —— X722 for 1GbE 说清楚后，结论可以讲得很明确了。

一、先给你结论（针对 Intel X722 1GbE + Hyper-V）

不建议长期关闭 VMQ。

这个型号的特性是：

✅ 主打虚拟化
✅ 专门为 Hyper-V / vSwitch 优化
✅ VMQ 稳定性比老的 8257x/8258x 好很多

你把 VMQ 设为 Disabled 后，真实后果是：

方面	实际影响
吞吐量	下降 20%～40%
延迟	略增
并发	明显变弱
CPU DPC 开销	上升明显
稳定性	变化不大（X722 本身已经比较稳）

二、为什么 X722 不建议关 VMQ（说点硬核的）

X722 属于 Intel 为服务器平台专门做的虚拟化 NIC 核心：

它对以下功能支持最好：

✅ VMQ
✅ RSS
✅ vRSS（虚拟 RSS）
✅ SR-IOV（部分型号支持）

这意味着：

你关闭 VMQ，相当于废掉了这张卡最有价值的“硬件卸载能力”。

三、在 X722 上关闭 VMQ，什么情况下才有意义

只有遇到下面问题，你才值得关 VMQ 测试：

虚机在高流量下偶发断网

Event Viewer 中出现：

Hyper-V-VmSwitch - Packet drops due to VMQ buffer starvation

网卡驱动有 Bug（旧版 Intel 驱动）

如果你只是“担心稳定性”，而实际上没遇到问题，那么关 VMQ 反而是负优化。

四、X722 最推荐的生产级配置（给你一份实战建议）

这是我给使用 X722 + Hyper-V 的标准推荐：

1）VMQ：保持启用 ✅

Set-NetAdapterVmq -Name "Ethernet*" -Enabled $true

2）RSS：必须开启 ✅

Get-NetAdapterRss
Enable-NetAdapterRss -Name "Ethernet*"

3）关闭无用的节能特性（非常关键）

在设备管理器 → 网卡高级属性：

建议这样设置：

项目	建议值
Interrupt Moderation	Enabled
Receive Side Scaling	Enabled
Virtual Machine Queues	Enabled
Energy Efficient Ethernet	Disabled
Flow Control	Disabled
UDP/TCP Checksum Offload	Enabled

五、如果你想“稳 + 快”的折中方案

可选方案（适合生产环境）：

保持 VMQ 开启
固定 VMQ CPU 亲和性：

Set-NetAdapterVmq -Name "Ethernet0" -BaseProcessorNumber 2 -MaxProcessors 8

这样可以避免 VMQ 把中断全部压到 CPU0。

六、一句适合你硬件的结论

在 Intel X722 1GbE + Hyper-V 场景下：

✅ 关闭 VMQ = 降性能，换来的稳定性收益非常小
✅ 开启 VMQ + RSS 才是你这张卡的正确用法

如果你愿意告诉我：

你的 CPU 型号
虚机数量
是否跑数据库 / 存储业务

我可以给你一套 真正压榨 X722 性能的参数组合。

传统虚拟机管理工具 virsh、libvirt 已过时！更轻量、更安全、更易用的现代化跨平台替代利器来了

说起 Linux 虚拟化，那我们就不得不提到 KVM 虚拟机了。

KVM（Kernel-based Virtual Machine）是 Linux 内核内置的硬件辅助虚拟化解决方案，通过将 Linux 内核转换为 Hypervisor，实现高效、低延迟的虚拟机管理。

既然需要用 KVM 虚拟机，那管理工具肯定也是必要的。

众所周知，传统的 KVM 虚拟机管理工具主要包括 virsh、virt-manager、libvirt 及相关工具链。但是，这些工具基本都具有：管理配置复杂性、性能损耗高、兼容性挑战及安全风险等缺点。

那么，有没有一款更轻量、更简单、高效的管理工具呢？

答案是肯定的，必须有。

轻量化、现代化的替代利器来了：Flint！

Flint 简介

Flint 是一个轻量级、多功能的 KVM 管理工具，以极简设计和高效运维为核心，重新定义了 KVM 虚拟机的管理方式。

它通过集成 Web UI、CLI 和 API 接口，摒弃 XML/容器依赖，以极简设计和全场景覆盖实现了更现代、更轻量的 KVM 管理方式。

可以这么说，在虚拟化管理领域，Flint 是专为 KVM 设计的轻量级工具。

核心特性

轻量化架构

单文件二进制：体积小于 11MB，集成 Web UI、CLI 和 API 接口，无需复杂依赖（如容器、XML 配置）。

跨平台支持：兼容 x86 和 ARM 架构，安装脚本自动识别系统环境，一键部署至 /usr/local/bin。

多维度管理方式

Web UI：基于 Next.js 和 Tailwind 构建，界面简洁直观，支持虚拟机创建、快照管理、资源监控等操作。

CLI 命令行：覆盖 Web UI 功能，支持批量操作与脚本化调用（如 flint vm list 列出虚拟机）。

API 接口：提供完整的 RESTful API，便于与第三方运维平台集成（如通过 curl 调用 API 管理虚拟机）。

安全设计

多层认证机制：Web UI 通过密码认证，API 使用 Bearer Token，所有接口均需身份验证。

会话管理：支持会话超时和强制登出，降低未授权访问风险。

高效资源与镜像管理

原生支持 Cloud-Init：简化虚拟机初始化配置（如网络、用户密码）。

基于快照的模板系统：快速克隆和部署标准化虚拟机环境。

极简设计

传统工具（如 virt-manager）依赖 XML 配置和繁琐的 GUI 操作，而 Flint 摒弃 XML，通过模板化设计实现“一键部署”。

示例：创建虚拟机仅需一条 CLI 命令：

flint vm launch --name test --memory 2G --disk /var/lib/flint/images/test.qcow2

快速入门

安装

curl -fsSL https://raw.githubusercontent.com/ccheshirecat/flint/main/install.sh | bash

启动 Web UI

flint serve --set-passphrase

访问管理界面

浏览器打开 http://localhost:5550，输入密码后即可操作。

核心功能介绍

Flint 作为专为 KVM 设计的轻量级管理工具，其核心功能围绕高效、安全、易用三大目标构建，覆盖虚拟机全生命周期管理、资源优化、安全防护及生态扩展。

虚拟机全生命周期管理

创建与配置

模板化部署：支持通过 JSON/YAML 模板一键创建虚拟机，预定义内存、CPU、磁盘等参数，示例模板：

{
  "name": "web_server",
  "memory": "4G",
  "cpus": 2,
  "disk": "/var/lib/flint/images/web.qcow2",
  "network": "bridge=br0",
  "cloud_init": "/var/lib/flint/cloud-init/web.iso"
}

Cloud-Init 集成：自动化完成主机名设置、SSH 密钥注入、网络配置等初始化操作。

启动与控制

批量操作：支持通过 CLI 或 API 批量启动/停止/重启多台虚拟机，例如：

flint vm start --all  # 启动所有虚拟机
flint vm stop --name=db1,db2  # 停止指定虚拟机

状态监控：实时显示虚拟机运行状态（运行中、暂停、关闭）、资源占用（CPU、内存）及网络流量。

快照与回滚

一键快照：快速创建虚拟机状态快照，支持命名和标签管理：

flint vm snapshot --name=test --snapshot=pre_upgrade

快速回滚：通过快照恢复虚拟机到指定状态，保障业务连续性。

镜像管理

镜像下载：Flint 支持从远程仓库下载镜像，例如 Ubuntu 24.04：

flint image download ubuntu-24.04

下载的镜像默认存储在 /var/lib/flint/images/ 目录下，便于后续虚拟机创建时直接调用。

镜像列表查看：通过命令行快速查看可用镜像列表：

flint image list

输出示例：

NAME               SIZE    PATH
ubuntu-24.04       2.5GB   /var/lib/flint/images/ubuntu-24.04.qcow2
centos-9           1.8GB   /var/lib/flint/images/centos-9.qcow2

Cloud-Init 集成

Flint 原生支持 Cloud-Init，允许通过镜像管理实现虚拟机的自动化初始化：

创建 Cloud-Init 镜像：将用户数据（如 SSH 密钥、网络配置）注入镜像。

示例命令：

flint vm launch --name=web_server --image=ubuntu-24.04 --cloud-init=/var/lib/flint/cloud-init/web.iso

虚拟机启动时会自动应用 Cloud-Init 配置，无需手动干预。

存储卷管理

Flint 支持为镜像关联存储卷，实现数据持久化：

#查看默认存储卷
flint storage volume list default

#创建存储卷
flint storage volume create --name=data_vol --size=10G

创建的存储卷可挂载至虚拟机，作为独立磁盘使用。

镜像管理操作示例

基于镜像创建虚拟机

使用下载的 Ubuntu 24.04 镜像创建虚拟机：

flint vm launch --name=ubuntu_vm --image=ubuntu-24.04 --memory=4G --cpus=2

//参数说明
--name：#虚拟机名称。
--image：#指定镜像路径。
--memory/--cpus：#分配资源。

镜像与快照结合

通过快照快速备份镜像状态：

flint vm snapshot --name=ubuntu_vm --snapshot=pre_update

快照可保存虚拟机当前状态，后续可通过快照恢复镜像至指定版本。

镜像删除与清理

删除不再使用的镜像以释放存储空间：

flint image delete ubuntu-24.04

删除前需确保无虚拟机依赖该镜像。

网络管理

Flint 的网络管理操作聚焦于虚拟网络的高效配置与运维，核心功能包括虚拟网络桥接、VLAN/VXLAN 支持、网络自动化配置等。

若需管理 KVM 虚拟机网络，建议优先使用 Flint 的 CLI 或 Web UI，通过模板化配置快速部署虚拟网络，结合 Cloud-Init 实现初始化自动化。

虚拟网络桥接配置

创建虚拟网桥

Flint 支持通过命令行或 Web UI 创建虚拟网桥（如 br0），作为虚拟机与外部网络通信的桥梁。例如，使用命令行创建网桥并绑定物理网卡：

brctl addbr br0          # 创建网桥
brctl addif br0 eth0     # 将物理网卡 eth0 绑定到网桥
ifconfig br0 up          # 启动网桥

虚拟机连接网桥

在虚拟机创建时指定网桥名称，实现虚拟机与外部网络的互联：

flint vm launch --name=vm1 --image=ubuntu-24.04 --network=br0

VLAN 与 VXLAN

VLAN 划分

Flint 支持通过 VLAN 标签隔离不同业务流量。例如，为虚拟机分配 VLAN ID 100：

flint vm network-config --name=vm1 --vlan=100

VXLAN 隧道配置

对于跨主机虚拟网络，Flint 支持 VXLAN 封装，实现二层网络扩展。配置示例：

flint vxlan create --vni=1001 --local-ip=192.168.1.100 --remote-ip=192.168.1.101

此命令在主机间建立 VXLAN 隧道（VNI 1001），实现虚拟机跨主机通信。

网络自动化配置

批量网络配置

Flint 支持通过模板批量配置虚拟机网络参数（如 IP 地址、子网掩码）。例如，使用 Cloud-Init 模板自动化配置：

flint vm launch --name=web_server --image=ubuntu-24.04 --cloud-init=/var/lib/flint/cloud-init/network.iso

模板文件 network.iso 中可定义静态 IP 或 DHCP 配置，减少手动操作。

网络监控与日志

Flint 提供网络流量监控接口，可集成至 Prometheus 或 Grafana 实现实时可视化。例如，通过 API 获取网桥 br0 的流量统计：

curl http://<flint-host>:8081/api/network/br0/stats

安全与隔离

防火墙规则管理

Flint 支持为虚拟机绑定安全组规则，限制入站/出站流量。例如，仅允许 SSH（22 端口）和 HTTP（80 端口）：

flint vm firewall-add --name=vm1 --rule="allow tcp port 22,80"

MAC 地址绑定

防止 MAC 地址欺骗，Flint 支持静态绑定虚拟机 MAC 地址：

flint vm mac-bind --name=vm1 --mac=00:16:3e:xx:xx:xx

API 接口

Flink 提供 RESTful API 接口，支持对作业、资源及集群状态的动态管理，核心操作包括：

作业生命周期管理

提交作业：通过 POST 请求向 JobManager 提交 Flink 作业（JAR 包或 SQL 脚本），例如：

curl -X POST -H "Content-Type: application/json" -d @job.json http://<jobmanager-host>:8081/jars/upload

查询作业状态：通过 GET 请求获取作业运行状态、指标及异常信息：

curl http://<jobmanager-host>:8081/jobs/<job-id>

动态资源调整

扩缩容 TaskManager：通过 API 动态调整 TaskManager 数量，适应负载变化：

curl -X POST -H "Content-Type: application/json" -d '{"slots":4}' http://<jobmanager-host>:8081/taskmanagers/scale

监控与日志获取

实时指标监控：通过 Prometheus 或 Grafana 集成，获取作业吞吐量、延迟等指标。

日志下载：通过 API 获取 TaskManager 或 JobManager 日志，辅助问题排查：

curl http://<taskmanager-host>:8081/taskmanagers/<tm-id>/logs/taskmanager.log

对比传统工具

对比维度	传统 KVM 管理工具（如 virsh/virt-manager/libvirt）	Flint 管理工具
安装部署	依赖复杂依赖库（如 Python/libvirt），安装包体积大（50MB+）	单文件二进制（<11MB），无外部依赖，一键部署
管理方式	CLI（virsh）+ GUI（virt-manager）割裂，需多工具协同操作	统一 Web UI/CLI/API 三合一，全场景覆盖
性能优化	上下文切换开销大（CPU 虚拟化损耗 10-30%），内存管理效率低	轻量级调度内核模块，资源利用率提升 50%，支持内存气球驱动
安全机制	粗放权限管理（如 libvirtd 守护进程风险），无细粒度 RBAC	多层认证（密码+Token），RBAC 模型，TLS 1.3 加密
资源管理	依赖 XML 配置，手动编辑易出错，不支持动态资源分配	模板化部署（JSON/YAML），动态 CPU/内存调整，存储卷精简配置
扩展性	插件生态薄弱，社区支持有限	插件机制（存储/网络/监控），GitHub 社区活跃，模板库丰富
学习曲线	需掌握 libvirt API、命令行参数及虚拟化概念，学习成本高	极简设计，Web UI 直观操作，CLI 参数自动补全
典型场景适配	适合传统企业级环境，但旧硬件兼容性差	轻量级（家庭实验室/边缘计算），跨平台（x86/ARM）
自动化能力	需结合脚本或第三方工具（如 Ansible）实现自动化	内置 Cloud-Init 集成，API 支持 CI/CD 流水线
安全加固	需手动配置防火墙/安全组，易遗漏风险点	默认禁用 root 操作，会话超时强制登出，传输加密

结语

Flint 重新定义 KVM 管理的「轻量级核弹」！

10 秒部署，1个文件搞定。轻量级内核调度，CPU 虚拟化损耗直降 50%，内存利用率翻倍！

企业级安全防护，多层认证（密码+Token）+ RBAC 权限控制，操作可追溯。

内置 Cloud-Init，批量部署虚拟机像「复制粘贴」一样简单。API 直接对接 CI/CD，流水线触发自动化测试/部署，DevOps 神器！

原来 KVM 管理可以这么爽！

1 分钟下载 + 1 条命令启动，让你的虚拟化环境秒变高效、安全、智能的「六边形战士」！

GitHub：https://github.com/ccheshirecat/flint

KVM 虚拟化（libvirt / virsh）常用命令清单

下面按生产运维常用频率，系统性整理 KVM 虚拟化（libvirt / virsh）常用命令清单。内容以 Linux 服务器环境（Ubuntu / CentOS / Rocky） 为基准，适合你这种长期做虚拟化与运维的场景。

一、基础环境与服务状态

1️⃣ 检查是否支持虚拟化

egrep -c '(vmx|svm)' /proc/cpuinfo

返回 ≥1 即支持 VT-x / AMD-V

lsmod | grep kvm

2️⃣ libvirt 服务管理

systemctl status libvirtd
systemctl start libvirtd
systemctl enable libvirtd
systemctl restart libvirtd

二、虚拟机（Domain）管理 —— 核心命令

1️⃣ 查看虚拟机列表

virsh list            # 运行中的 VM
virsh list --all      # 所有 VM

2️⃣ 启动 / 关闭 / 重启

virsh start vm1
virsh shutdown vm1    # 正常关机
virsh reboot vm1
virsh destroy vm1     # 强制断电（慎用）

3️⃣ 自动启动控制

virsh autostart vm1
virsh autostart --disable vm1

4️⃣ 删除虚拟机

virsh undefine vm1

⚠️ 仅删除定义，不删除磁盘

删除磁盘：

rm -f /var/lib/libvirt/images/vm1.qcow2

三、虚拟机配置与信息查看

1️⃣ 查看详细信息

virsh dominfo vm1

2️⃣ 查看 XML 配置（非常关键）

virsh dumpxml vm1

编辑配置：

virsh edit vm1

3️⃣ 查看 CPU / 内存

virsh vcpuinfo vm1
virsh vcpucount vm1
virsh dommemstat vm1

四、磁盘管理（生产常用）

1️⃣ 查看磁盘挂载

virsh domblklist vm1

2️⃣ 在线扩容磁盘（qcow2）

qemu-img resize vm1.qcow2 +50G

让 VM 识别：

virsh blockresize vm1 vda 100G

3️⃣ 创建磁盘

qemu-img create -f qcow2 vm2.qcow2 50G

查看磁盘信息：

qemu-img info vm1.qcow2

五、快照管理（qcow2）

1️⃣ 创建快照

virsh snapshot-create-as vm1 snap1 "before update"

2️⃣ 查看快照

virsh snapshot-list vm1

3️⃣ 回滚快照

virsh snapshot-revert vm1 snap1

4️⃣ 删除快照

virsh snapshot-delete vm1 snap1

六、网络管理（libvirt）

1️⃣ 查看网络

virsh net-list --all

2️⃣ 启动 / 停止网络

virsh net-start default
virsh net-autostart default

3️⃣ 查看网络配置

virsh net-dumpxml default

七、控制台与远程访问

1️⃣ 控制台登录

virsh console vm1

退出：

Ctrl + ]

2️⃣ VNC/SPICE 信息

virsh vncdisplay vm1
virsh domdisplay vm1

八、资源热调整（在线）

1️⃣ CPU 热调整

virsh setvcpus vm1 8 --live

2️⃣ 内存热调整

virsh setmem vm1 16G --live

永久生效：

virsh setmem vm1 16G --config

九、宿主机层面（排障必会）

1️⃣ 查看 qemu 进程

ps -ef | grep qemu

2️⃣ 查看 VM 日志

/var/log/libvirt/qemu/vm1.log

3️⃣ 查看宿主资源

virsh nodeinfo
free -h
lsblk

十、批量与自动化常用

1️⃣ 批量关机

for vm in $(virsh list --name); do
    virsh shutdown $vm
done

2️⃣ 批量启动

virsh list --all | awk '/shut off/ {print $2}' | xargs -n1 virsh start

十一、`virt-install`（创建虚拟机）

virt-install \
  --name vm1 \
  --memory 8192 \
  --vcpus 4 \
  --disk path=/var/lib/libvirt/images/vm1.qcow2,size=50 \
  --os-variant ubuntu20.04 \
  --network bridge=br0 \
  --graphics vnc \
  --cdrom ubuntu-20.04.iso

十二、运维级建议（给你这种场景）

日常必会 10 个命令：

virsh list
virsh start / shutdown / destroy
virsh dumpxml / edit
virsh domblklist
qemu-img info / resize
virsh snapshot-*
virsh console

生产建议：
- 统一使用 qcow2 + snapshot
- VM XML 做版本备份
- 禁止直接 kill qemu
- 网络桥接优先 br0

如果你需要，我可以进一步给你：

KVM 运维速查表（Markdown / PDF）
Hyper-V vs KVM 运维命令对照表
高性能 KVM 调优清单（NUMA / hugepage / IO）
libvirt + Ansible 批量管理模板

你直接告诉我下一步想深入哪一块即可。

无法启动虚拟机，因为虚拟机监控程序未运行，实测解决方法

从报错内容来看，这是 Hyper-V 虚拟机监控程序（Hypervisor）未能运行 导致的典型问题，并非单个虚拟机配置错误。需要从 宿主机层面 排查。

下面按最常见 → 最有效的顺序给你一套处理清单。

一、先明确报错本质

关键报错点是：

“无法启动虚拟机，因为虚拟机监控程序未运行”

这说明：

Hyper-V 角色可能已安装
但 Hyper-V Hypervisor 没有在宿主机启动阶段加载
所有 VM 都会无法启动（不是单个 VM 问题）

二、第一优先级检查（90% 问题在这里）

1️⃣ BIOS / UEFI 是否开启硬件虚拟化（必须）

进入 BIOS，确认以下选项 全部开启：

项目	状态
Intel VT-x / AMD-V	Enabled
Intel VT-d / IOMMU	Enabled（强烈建议）
Execute Disable Bit / NX	Enabled
SVM Mode（AMD）	Enabled

注意：

改完 BIOS 后，必须 完全关机 → 断电 → 再开机
不能只重启（Windows 会缓存虚拟化状态）

2️⃣ Windows 是否真的加载了 Hyper-V Hypervisor

在 管理员 CMD / PowerShell 执行：

bcdedit /enum {current}

重点看这一行：

hypervisorlaunchtype    Auto

如果是 `Off`，执行：

bcdedit /set hypervisorlaunchtype auto

然后：

➡ 关机（不是重启） → 再开机

三、检查是否被“其他虚拟化组件”占用

3️⃣ 是否启用了以下功能（会占用虚拟化）

进入：

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

重点检查：

❌ 如果你不用它们，全部关闭

Windows Hypervisor Platform
Virtual Machine Platform
Windows Sandbox
Windows Subsystem for Linux（WSL）
Containers

保留：

✔ Hyper-V（完整角色）

关闭后重启。

4️⃣ 是否安装过 VMware / VirtualBox / Android 模拟器

这些组件常见冲突源：

VMware Workstation
VirtualBox
BlueStacks / 雷电 / 夜神
Docker Desktop（WSL2 模式）

临时验证方法（推荐）

在管理员 CMD 执行：

systeminfo

如果看到：

A hypervisor has been detected. Features required for Hyper-V will not be displayed.

➡ 说明 虚拟化被其他 Hypervisor 占用

解决方式：

卸载第三方虚拟化软件
或关闭其 Hypervisor 功能（VMware 要关 Hypervisor）

四、确认 Hyper-V 服务是否正常

5️⃣ 检查 Hyper-V 服务状态

services.msc 中确认以下服务：

服务名	状态
Hyper-V Virtual Machine Management	正在运行
Hyper-V Host Compute Service	正在运行

如果服务无法启动 → 说明 Hypervisor 根本没加载，继续回查 BIOS / bcdedit。

五、虚拟机本身的关键配置检查（次要）

如果 宿主机 Hyper-V 正常，再检查 VM：

6️⃣ Generation 选择是否正确

Linux / Win Server 新系统 → Generation 2
老系统 / Legacy → Generation 1

7️⃣ CPU 数量 & 内存

先保守配置测试：

CPU：1
内存：2048 MB
关闭动态内存（先排错）

六、如果这是虚拟化里的虚拟机（嵌套虚拟化）

如果你是在：

VMware / KVM / 云服务器
再装 Windows → 再跑 Hyper-V

那必须满足：

宿主虚拟化平台支持 Nested Virtualization
且明确开启

例如 VMware 需要：

vhv.enable = "TRUE"

否则 Hyper-V 一定无法启动

七、快速定位总结（给你一个判断路径）

你可以按这个顺序快速判断：

bcdedit → hypervisorlaunchtype 是否 auto
BIOS 虚拟化是否开启（关机断电）
是否装过 VMware / 模拟器 / Docker
systeminfo 是否提示 hypervisor 冲突
Hyper-V 服务是否能启动

八、我需要你补充的信息（可精确定位）

如果你愿意，我可以直接给你最终解决方案，请回复：

宿主机系统版本（如：Win Server 2019 / 2022 / Win11）
是否运行在 物理机还是虚拟机
CPU 型号（Intel / AMD，具体型号）
是否安装过 VMware / VirtualBox / Docker

我可以按你的环境直接给出 一步到位的修复命令。

hyper-v ubuntu虚拟机测试网卡并发，含sar tcpdump抓包

在 Hyper-V 中运行的 Ubuntu 18.04 虚拟机里，没有直接命令能“检测网卡当时的并发量”或“并发上限”，因为“并发量”在网络领域通常不是一个标准指标。但我们可以从以下几个角度理解你的需求，并提供对应的监控和分析方法：

✅ 一、澄清概念：什么是“网卡并发量”？

在网络上下文中，“并发”一般指：

同时建立的 TCP/UDP 连接数（如 netstat 或 ss 统计的连接数）
单位时间内的数据吞吐量（如 Mbps、pps）
网卡队列/中断处理能力（底层性能）

而“并发上限”可能指：

系统最大允许的 socket 连接数（受 ulimit、net.core.somaxconn 等限制）
网卡或虚拟交换机的带宽上限（如 1 Gbps）
Hyper-V 虚拟网卡的性能瓶颈

✅ 二、常用命令与工具（Ubuntu 18.04）

1. 查看当前网络连接数（模拟“并发连接”）

# 查看所有 TCP 连接数
ss -t | wc -l

# 查看 ESTABLISHED 状态的连接数（更接近“活跃并发”）
ss -t state established | wc -l

# 按进程统计连接数
ss -tulpn

⚠️ 注意：这反映的是应用层连接数，不是网卡本身的“并发”。

2. 实时监控网络带宽（吞吐量）

使用 iftop、nethogs、bmon 等工具：

# 安装 iftop（需 root）
sudo apt update && sudo apt install iftop

# 实时查看 eth0 的流量（按连接显示）
sudo iftop -i eth0

输出示例：

192.168.1.100 => 10.0.0.50    8.2Mb  12Mb  9.1Mb

→ 表示当前每秒收发速率（近似“瞬时并发负载”）

3. 查看网卡理论带宽上限

Ubuntu 虚拟机中的网卡通常是 hyperv_netvsc 驱动（Hyper-V 虚拟网卡）：

# 查看网卡速率（注意：虚拟网卡可能显示为 "unknown" 或 10000Mb/s）
ethtool eth0 | grep Speed

# 如果 ethtool 未安装：
sudo apt install ethtool

💡 在 Hyper-V 中，虚拟网卡速率由 虚拟交换机配置 和 主机物理网卡 决定，通常可达 10 Gbps（逻辑值），实际受限于主机 I/O。

4. 查看系统网络连接限制（“并发上限”相关参数）

# 最大监听队列长度（影响 accept() 并发）
cat /proc/sys/net/core/somaxconn

# 最大跟踪的连接数（netfilter）
cat /proc/sys/net/netfilter/nf_conntrack_max

# 当前已跟踪连接数
cat /proc/sys/net/netfilter/nf_conntrack_count

若 nf_conntrack_count 接近 nf_conntrack_max，说明连接数已达系统上限。

5. 压力测试网卡极限（主动探测上限）

使用 iperf3 测试实际吞吐能力：

# 在另一台机器运行服务端
iperf3 -s

# 在 Ubuntu 虚拟机运行客户端
iperf3 -c <server_ip> -t 30 -P 8

可测出 实际 TCP/UDP 吞吐上限（Mbps）和并发流性能。

✅ 三、Hyper-V 特别注意事项

集成服务（Integration Services）必须启用
确保 Ubuntu 安装了 linux-virtual 内核或启用了 Hyper-V 集成：
```
lsmod | grep hv_
```
应看到 hv_netvsc、hv_storvsc 等模块。
虚拟交换机类型影响性能
- 外部虚拟交换机：性能最佳（直通物理网卡）
- 内部/NAT：有额外开销

关闭不必要的功能提升性能
在 Ubuntu 中可尝试：

# 关闭 GRO（Generic Receive Offload）有时可提升小包性能
sudo ethtool -K eth0 gro off

✅ 总结：如何回答你的问题？

你想知道的	实际可用命令/方法
当前“并发连接数”	`ss -t state established \| wc -l`
网卡实时流量（近似负载）	`iftop -i eth0`
系统连接数上限	`cat /proc/sys/net/netfilter/nf_conntrack_max`
网卡理论带宽	`ethtool eth0`（可能不准确）
实际吞吐上限	`iperf3` 压力测试

📌 结论：没有单一命令能直接告诉你“网卡并发量”，但通过组合上述工具，你可以全面评估网络负载、连接数和性能瓶颈。

如需进一步分析（如丢包、重传），可使用 sar -n DEV 1（来自 sysstat 包）或 tcpdump 抓包分析。

当然可以！以下是针对 Ubuntu 18.04 系统，用于深入分析网络性能问题（如丢包、重传、吞吐瓶颈）的实用命令，特别适用于你当前在 Hyper-V 虚拟机中排查 iperf3 异常的场景。

✅ 一、使用 `sar` 监控网卡实时流量与错误（来自 `sysstat`）

1. 安装 sysstat（如未安装）

sudo apt update
sudo apt install sysstat

⚠️ 注意：Ubuntu 默认可能禁用 sysstat 数据收集。
编辑配置文件启用：
sudo sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl restart sysstat

2. 实时监控网卡统计（每秒刷新）

# 监控所有网卡，每1秒输出一次
sar -n DEV 1

# 只监控 eth0
sar -n DEV 1 | grep eth0

🔍 关注字段含义：

字段	说明
`rxpck/s`	每秒接收的数据包数
`txpck/s`	每秒发送的数据包数
`rxkB/s`	每秒接收的千字节数（≈带宽）
`txkB/s`	每秒发送的千字节数
`rxerr/s`	每秒接收错误包数（关键！）
`txerr/s`	每秒发送错误包数（关键！）
`rxdrop/s`	接收丢包数（因缓冲区满等）
`txdrop/s`	发送丢包数

✅ 如果 rxerr/s 或 rxdrop/s > 0，说明网卡或驱动层存在丢包！

✅ 二、使用 `tcpdump` 抓包分析 TCP 行为（丢包、重传、窗口等）

1. 基础抓包（保存到文件）

# 抓取与 10.2.2.227 的通信，保存为 pcap 文件
sudo tcpdump -i eth0 host 10.2.2.227 -w iperf_test.pcap

在另一个终端运行 iperf3 -c 10.2.2.227 -P 8 -t 10，结束后按 Ctrl+C 停止抓包。

2. 实时分析重传和丢包（命令行快速诊断）

# 显示 TCP 重传（Retransmission）
sudo tcpdump -i eth0 host 10.2.2.227 -nn -q | grep -i "retrans"

# 或更精确地过滤 dup ack 和 fast retransmit
sudo tcpdump -i eth0 host 10.2.2.227 -nn -q 'tcp[tcpflags] & (tcp-rst|tcp-syn) != 0 or tcp[13] & 8 != 0'

3. 使用 `tshark`（Wireshark 命令行版）分析（推荐）

先安装：

sudo apt install tshark

然后分析重传比例：

# 统计 TCP 重传包数量
tshark -r iperf_test.pcap -Y "tcp.analysis.retransmission" | wc -l

# 查看 TCP Window Full（接收方缓冲区满）
tshark -r iperf_test.pcap -Y "tcp.analysis.window_full"

# 查看重复 ACK（暗示丢包）
tshark -r iperf_test.pcap -Y "tcp.analysis.duplicate_ack"

✅ 三、查看内核 TCP 统计（高级诊断）

1. 使用 `ss` 查看连接状态和重传

# 查看所有 TCP 连接的重传次数（重点看 rto、retrnsmt）
ss -i state established

# 示例输出片段：
# cubic rto:204 rtt:4/2 cwnd:10 send 1.2Mbps rcv_space:14600
# → 如果 rto 很大或 retrnsmt > 0，说明有重传

2. 查看全局 TCP 错误统计

# 显示 TCP 重传、丢包等累计计数器
cat /proc/net/netstat | grep TcpExt

# 关键字段（第二行对应值）：
# TCPLostRetransmit, TCPFastRetrans, TCPSlowStartRetrans, TCPRenoRecovery, TCPSACKRecovery
# TCPTimeouts, TCPLossProbes, TCPRenoFailures

例如：

awk '/TcpExt/ {getline; print}' /proc/net/netstat

输出类似：

TcpExt: ... 0 5 0 0 12 ...

→ 第 2 个数字是 TCPFastRetrans（快速重传次数），非零即有问题。

✅ 四、综合诊断建议（针对你的场景）

由于你 sender 是 Ubuntu，receiver 是 Windows（推测），且 telnet 通但 iperf3 数据收不到：

📌 推荐操作流程：

在 Ubuntu sender 端运行：

# 开启 sar 监控
sar -n DEV 1 > sar_log.txt &

# 同时抓包
sudo tcpdump -i eth0 host 10.2.2.227 -w debug.pcap &

# 运行 iperf3
iperf3 -c 10.2.2.227 -P 8 -t 10

# 停止后台任务
killall sar tcpdump

分析结果：
- 查看 sar_log.txt：是否有 rxerr/s 或 rxdrop/s？
- 用 tshark 分析 debug.pcap：
```
tshark -r debug.pcap -Y "tcp.analysis.retransmission" -T fields -e frame.time -e ip.src -e tcp.seq
```
- 如果 只有 sender 发包，receiver 无 ACK → 数据被中间设备丢弃（Windows 防火墙）。
- 如果 有大量重传 → 网络拥塞或接收端处理慢。

✅ 五、附加：快速检查驱动和中断（Hyper-V 特有）

# 确认使用的是 hv_netvsc 驱动
ethtool -i eth0 | grep driver

# 查看中断是否均衡（多 vCPU 时）
cat /proc/interrupts | grep eth0

在 Hyper-V 中，若虚拟机分配了多个 vCPU，但网络中断集中在 CPU0，可能导致瓶颈。

总结：关键命令速查表

目的	命令
实时带宽+错误	`sar -n DEV 1`
抓包保存	`tcpdump -i eth0 host 10.2.2.227 -w test.pcap`
检查重传	`tshark -r test.pcap -Y "tcp.analysis.retransmission"`
查看连接重传	`ss -i`
全局 TCP 错误	`cat /proc/net/netstat \| grep TcpExt`

通过以上工具组合，你可以精准定位是 丢包、重传、接收端不响应、还是驱动瓶颈。
结合你之前的现象（receiver 收 0 字节），最可能仍是 Windows 防火墙拦截，但 tcpdump 能提供决定性证据。

如需进一步分析抓包文件，可将 .pcap 导出并在 Wireshark GUI 中打开，查看“Statistics → TCP Stream Graphs” 更直观。

你当前想分析 昨天（2026年1月14日）18:00–19:00 的网络设备（-n DEV）性能数据，但遇到了 sar -n DEV 1 -f sar14 报错：

Invalid system activity file: sar14

这是因为 sar 命令读取的是 saXX 文件，而不是 sarXX 文件。

✅ 正确理解 sysstat 文件命名规则

在 Ubuntu/Debian 系统中：

saDD：二进制格式的原始系统活动数据文件（sar 命令读这个）
- 例如：sa14 → 代表 14 日的数据
sarDD：通常是 sar 命令输出的文本日志（供人阅读），不能被 sar -f 直接解析

📌 所以你应该使用 sa14 来分析 1月14日 的数据。

✅ 正确命令：分析 1月14日 18:00–19:00 的网卡流量

# 查看 1月14日 全天的网卡统计（每10分钟一条，默认采集间隔）
sar -n DEV -f /var/log/sysstat/sa14

# 只查看 18:00 到 19:00 之间的数据（注意：时间格式为 HH:MM:SS）
sar -n DEV -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14

⚠️ 注意：

-s 和 -e 指定起止时间（24小时制）

如果系统 sysstat 配置的采集间隔是 10分钟（默认），那么你只能看到 18:00、18:10、18:20……18:50 这些时间点的数据，不会有秒级精度。

若需 1 秒粒度，必须当时用 sar -n DEV 1 实时记录（你没做，所以无法回溯秒级数据）。

🔍 示例输出解读

运行后你会看到类似：

06:10:01 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
06:20:01 PM        eth0     12000      8000     15000      9000         0         0         0      12.3
...
06:50:01 PM        eth0     50000     48000     62000     60000         0         0         0      48.7

重点关注：

rxkB/s / txkB/s：接收/发送带宽（KB/s）
%ifutil：网卡利用率（部分驱动支持）
如果 rxerr/s 或 txerr/s 出现（需加 -n EDEV），说明有错误

✅ 补充：查看错误和丢包（如果需要）

# 查看 1月14日 18-19点的网卡错误（如 CRC、丢包）
sar -n EDEV -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14

字段说明：

rxerr/s：接收错误包/秒
txerr/s：发送错误包/秒
coll/s：冲突（半双工才有）
rxdrop/s：因缓冲区满丢弃的接收包
txdrop/s：发送丢包

❓ 为什么没有 `sa15` 完整文件？

你看到：

-rw-r--r-- 1 root root 485428 Jan 15 16:45 sa15

这是因为 今天（1月15日）还没结束，sa15 是当天正在写入的临时文件。
通常在 每日 23:59 由 sysstat 的 cron 任务 finalize 成完整文件。

✅ 所以分析历史数据请用 sa01 到 sa14。

✅ 总结：你要的命令

# 分析 2026-01-14 18:00–19:00 网卡流量
sar -n DEV -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14

# 如需错误统计
sar -n EDEV -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14

💡 提示：如果输出为空，说明那段时间没有采集到数据（可能服务未运行，或采集间隔跳过了该时段）。

如有其他需求（如分析 CPU、内存同期负载），也可用：

sar -u -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14  # CPU
sar -r -s 18:00:00 -e 19:00:00 -f /var/log/sysstat/sa14  # 内存

希望这能帮你精准定位昨天的网络性能状况！

在 TrueNAS SCALE（基于 Linux 的现代版本）中集成局域网 Active Directory（AD）域

在 TrueNAS SCALE（基于 Linux 的现代版本）中集成 局域网 Active Directory（AD）域，可以实现使用域账号（如 DOMAIN\user）来管理 SMB 共享文件的权限（ACL），从而实现企业级集中身份认证与精细化权限控制。

以下是 完整配置流程（适用于 TrueNAS SCALE 22.12 及以上版本）：

✅ 前提条件

局域网中已部署 Active Directory 域控制器（如 Windows Server 2016/2019/2022）
- 域名示例：corp.local
- DC IP：192.168.1.10
TrueNAS 主机已加入同一局域网，能解析域名、ping 通 DC
DNS 配置正确：
- TrueNAS 的 DNS 服务器应指向 AD 域控（或能递归解析 _ldap._tcp.dc._msdcs.corp.local 的 DNS）
防火墙允许以下端口（TCP/UDP）：
- 53（DNS）、88（Kerberos）、135（RPC）、139/445（SMB）、389（LDAP）、636（LDAPS）

🔧 步骤一：配置网络与主机名（关键！）

AD 对主机名和 DNS 解析极其敏感。

进入 Network > Global Configuration
- Hostname: 设置为符合规范的名称（如 truenas）
- Domain: 留空（不要填 AD 域名！）
- Nameserver 1: 填写 AD 域控 IP（如 192.168.1.10）
保存后，测试 DNS 解析：
```
# 在 Shell 中执行
nslookup corp.local
nslookup truenas.corp.local  # 应能解析到 TrueNAS IP
```
⚠️ 如果 truenas.corp.local 无法解析，需在 AD 域控的 DNS 中手动添加 A 记录。

🔐 步骤二：加入 Active Directory 域

进入 Directory Services > Active Directory
填写参数：
- Domain Name: corp.local（你的 AD 域名）
- Account Name: administrator 或有“加入计算机到域”权限的账户
- Password: 对应密码
- Site Name: 留空（除非你有 AD 站点）
- Enable: ✅ 勾选
（可选）高级设置：
- Use default domain account: ✅ 建议勾选（自动创建机器账户）
- Disable password expiration: ✅ 建议勾选（避免机器账户过期）
点击 SAVE

✅ 成功后，状态应显示 HEALTHY，且 TrueNAS 会在 AD 中注册为计算机对象（如 TRUENAS$）。

🧪 步骤三：验证 AD 集成是否成功

进入 Shell（System Settings > Shell）

执行命令测试：

# 查看域用户
wbinfo -u

# 查看域组
wbinfo -g

# 测试 Kerberos 认证（应返回票据）
kinit administrator@CORP.LOCAL
klist

若报错（如 NT_STATUS_NO_TRUST_SAM_ACCOUNT），说明未真正加入域，需检查 DNS 和时间同步。

确保时间同步（AD 要求时间偏差 < 5 分钟）：
- TrueNAS 应启用 NTP，并与域控时间一致。
- 域控通常作为权威时间源。

📁 步骤四：创建数据集并启用 SMB + ACL 模式

Storage > Pools > Add Dataset
- Name: ad_share
- Share Type: SMB
- ACL Type: NFSv4（这是支持 Windows ACL 的关键！）
- 其他默认 → Save

💡 NFSv4 ACL 模式才能映射 Windows 的精细权限（读/写/删除子文件夹等）。

🌐 步骤五：创建 SMB 共享（使用 AD 身份）

Sharing > Windows Shares (SMB) > Add
- Path: /mnt/tank/ad_share
- Name: AD_Share
- Purpose: Default share parameters
- ✅ Enabled
高级设置（重要）：
- Auxiliary Parameters（可选但推荐）：
```
vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes
```
- 其他保持默认 → Save

👥 步骤六：配置 ACL 权限（使用域用户/组）

回到 Storage > Pools
找到 tank/ad_share，点击 ⋮ > Edit ACL
ACL Type: 确保是 NFSv4
点击 Add Item 添加权限条目：
- Who: 输入域用户或组，格式为：
  - 用户：CORP\\alice 或 alice@corp.local
  - 组：CORP\\domain users 或 domain users@corp.local
- Type: ALLOW
- Permissions: 勾选所需权限（如 READ, WRITE, EXECUTE）
- Apply permissions recursively: ✅ 勾选
点击 Save

✅ 此时，Windows 客户端用域账号登录后，访问 \\truenas\AD_Share 将自动应用对应权限。

🖥️ 客户端测试（Windows）

用域账号（如 alice@corp.local）登录 Windows
访问：\\<TrueNAS_IP>\AD_Share
尝试创建/删除文件 → 验证权限是否生效

🔧 常见问题排查

问题	解决方案
“无法加入域” / “NT_STATUS_LOGON_FAILURE”	检查账户密码、DNS 解析、时间同步
wbinfo -u 无输出	检查 SSSD 服务状态：`systemctl status sssd`
ACL 保存时报错“Invalid user”	确保输入格式正确（如 `CORP\\username`），且用户存在于域中
权限不生效	确认数据集 ACL 类型为 NFSv4，而非 POSIX
中文用户名乱码	在 SMB 全局设置中添加： `fruit:encoding = UTF-8` `dos charset = CP936`

✅ 总结：关键要点

项目	要求
DNS	必须能正向/反向解析 TrueNAS 主机名
时间同步	与域控偏差 < 5 分钟
数据集 ACL 类型	必须选 NFSv4
用户格式	`DOMAIN\\username` 或 `username@domain.com`
SMB 共享	无需单独创建本地用户，直接使用域身份

通过以上配置，TrueNAS 即可作为 AD 域成员服务器，无缝使用域账号管理文件权限，适用于企业文件服务器、部门共享等场景。

📌 提示：如需更高级功能（如 LDAP 同步、组策略映射），可结合 SSSD 或 Winbind 进行调优，但对大多数 SMB 共享场景，上述配置已足够。

阿里云 ECS（Ubuntu 18.04）把系统盘转换成 Hyper-V 可用的 VHD

可以，阿里云 ECS（Ubuntu 18.04）把 系统盘转换成 Hyper-V 可用的 VHD，标准做法是：

👉 新增一块临时云盘 → dd 克隆系统盘 → qemu-img 转换 VHD

下面给你一套 运维可直接执行流程（适合 Linux 运维）。

一、前提确认（非常重要）

先确认磁盘：

lsblk

假设：

磁盘	作用
/dev/vda	40G 系统盘
/dev/vdb	新增临时云盘

⚠️ 后面全部按这个示例写，实际请替换。

二、安装转换工具

Ubuntu18 默认没有 qemu-img：

apt update
apt install -y qemu-utils

确认：

qemu-img --version

三、临时云盘分区 + 挂载

1️⃣ 分区

fdisk /dev/vdb

操作：

n
p
1
回车
回车
w

2️⃣ 格式化

3️⃣ 挂载

mkdir /mnt/tempdisk
mount /dev/vdb1 /mnt/tempdisk

确认：

df -h

四、克隆系统盘（生成 RAW）

⚠️ 必须用整盘 /dev/vda，不是分区

dd if=/dev/vda of=/mnt/tempdisk/system.raw bs=16M status=progress

参数说明：

参数	作用
if	输入磁盘
of	输出文件
bs=16M	提升复制速度
status=progress	显示进度

预计时间：

40G SSD ECS
约 5～15 分钟

五、转换为 Hyper-V VHD

1️⃣ 固定大小 VHD（强烈推荐）

Hyper-V 兼容性最好：

qemu-img convert -f raw -O vpc -o subformat=fixed,force_size \
/mnt/tempdisk/system.raw \
/mnt/tempdisk/system.vhd

2️⃣ 可扩展 VHD（可选）

qemu-img convert -f raw -O vpc \
/mnt/tempdisk/system.raw \
/mnt/tempdisk/system.vhd

六、验证 VHD

qemu-img info /mnt/tempdisk/system.vhd

应该看到：

file format: vpc

七、压缩（强烈建议）

tar -czvf system_vhd.tar.gz system.vhd

八、下载回本地

方式：

方案1（推荐）

阿里云：

上传 OSS
再下载

方案2

直接 scp：

scp root@ecs-ip:/mnt/tempdisk/system_vhd.tar.gz .

九、Hyper-V 启动注意事项（90%人会踩坑）

创建 VM 时：

Generation 选择

👉 Ubuntu18 建议：

Generation 1

不要选 Gen2（UEFI可能无法启动）。

启动前修复（强烈建议在 ECS 先做）

apt install -y linux-image-virtual linux-tools-virtual

安装：

hv_vmbus
hv_storvsc
hv_netvsc

十、企业级推荐方案（比 dd 更专业）

如果你是生产环境迁移，我更建议：

阿里云镜像导出 → qcow2 → vhd

优点：

不停机
一致性好
可自动修复分区

如果你愿意，我可以给你：

1️⃣ ✅ 一键系统盘转 Hyper-V VHD 脚本（生产级）
2️⃣ ✅ 阿里云 ECS → Hyper-V 无法启动的修复大全（90%问题覆盖）
3️⃣ ✅ Gen1 / Gen2 选择与 grub 修复流程图
4️⃣ ✅ Hyper-V 启动蓝屏/Kernel Panic 专业排查手册

直接告诉我 👍

虚拟化技术

真正有效压缩hyper-v虚拟磁盘文件VHDX

hyper-v迁移前开启winrm service

Windows Server 2022 Hyper-V 虚拟网卡参数查看及修改

1️⃣ 查看网卡缓冲区大小

2️⃣ 修改网卡缓冲区

🔹 总结

银河麒麟高级服务器版V11+KVM+Libvirt+WebVirtCloud+OpenStack部署

🚀 一、环境准备

1. 检查CPU是否支持虚拟化

2. 确保内核模块支持KVM

3. 启用桥接网络（推荐虚拟机可直接联网）

🧩 二、安装KVM + Libvirt + QEMU

🌐 三、安装WebVirtCloud（Web管理界面）

1. 安装依赖

2. 克隆WebVirtCloud源码

3. 安装Python依赖

4. 初始化数据库和配置

5. 启动测试

方法 A：Gunicorn 自带 --daemon

方法 B：使用 systemd 管理 WebVirtCloud

⚙️ 四、配置Nginx反向代理（生产环境）

🧰 五、配置Supervisor守护WebVirtCloud

🖥 六、配置WebVirtCloud连接KVM主机

☁️ 七、（可选）安装 OpenStack 实现云平台管理

1. 安装 DevStack（快速体验）

🧾 八、验证与维护

验证虚拟化运行状态

查看libvirt网络和存储池

检查服务状态

✅ 部署总结

🧭 建议实践路线

1️⃣ 查看现有存储池

2️⃣ 激活默认存储池（如果存在）

3️⃣ 创建新的存储池（如果没有）

4️⃣ 在 WebVirtCloud 刷新

🧩 一、命令行方式（推荐）

1️⃣ 把 ISO 文件上传到宿主机存储路径

2️⃣ 定义 ISO 文件所在目录为存储池（如果还没定义）

3️⃣ 让 WebVirtCloud 识别新 ISO

4️⃣ 在虚拟机中挂载 ISO 文件

5️⃣ 从 ISO 启动虚拟机

🧩 二、WebVirtCloud 直接上传（如果开启了上传功能）

✅ 验证

✅ 是的，这一行需要修改。

🔧 修改步骤

✅ 总结

远程桌面实现方案xrdp

✅ 方案 1：仅安装 xrdp，不装 xorgxrdp（最简单）

✅ 方案 2：使用 Kylin 官方提供的 xrdp 包（推荐）

✅ 方案 3：手动构建或使用第三方 RPM 包

✅ 验证运行

现在我们来创建 systemd 服务并启动它。

rsync 实现 每日增量备份 KVM 虚拟机磁盘

1️⃣ 前提条件

2️⃣ 备份目录结构

3️⃣ 导出虚拟机配置（XML）

4️⃣ rsync 增量备份虚拟机磁盘

rsync 参数说明：

5️⃣ 自动化脚本示例

6️⃣ 配置每日定时任务

7️⃣ 恢复虚拟机示例

银河麒麟 + KVM + WebVirtCloud 虚拟机内存不足8G原因与解决方法

🧩 一、宿主机层面：内存超分配或 NUMA 限制

🔹 1. 宿主机可用内存不足

🔹 2. NUMA 分区未正确分配

🧩 二、虚拟机配置层面（Libvirt/QEMU）

🧩 三、模板或镜像层面

🧩 四、虚拟机内部系统

✅ 综合建议（推荐修复顺序）

✅ 一、已确认情况

🧩 二、在虚拟机内部进一步检查

1️⃣ 检查内核参数是否限制内存

2️⃣ 检查系统是否识别全部内存

🧩 三、检查虚拟机 BIOS（QEMU 机器类型）

🧩 四、确认虚拟机使用的是标准 BIOS 而非 OVMF（UEFI）

🧩 五、建议最终检查项

✅ 总结

✅ 一、关键日志分析

🧩 二、为什么会这样？

方法 A：Gunicorn 自带 `--daemon`

方法 B：使用 `systemd` 管理 WebVirtCloud

rsync 实现每日增量备份 KVM 虚拟机磁盘

Hyper-V 实时迁移（Live Migration）的身份验证方式配置错误解决方法

fio 测的是随机读 IOPS

iostat 测的是真实落盘写 IOPS

✅ 我可以根据你的 Hyper-V 配置（VM 设置截图或 Get-VHD 输出）为你制定解除限速的精准方案。

✅ 一、把 VHDX 从动态扩展改为固定大小（最重要 / 提升 3~10 倍 IOPS）