文章目录

前言

写这篇文章花了我几天的时间，我把过程中遇到的坑都解决了，相信我这篇文章最少能带你入门incus。。。毕竟incus还是非常强大的，功能太多了，一时半会也折腾不完。。。

文章标题已经特地注明了是OVH的机器，为什么要特地注明一下，其原因有二：

1.OVH网络比较特殊，尤其是IPv6，稍后详细说明。

2.这台服务器的Debian13系统是通过OVH控制面板安装的，即系统内默认使用的是netplan+systemd-networkd而非Debian默认的ifupdown。

所以这篇文章的配置我只能保证目前适用于OVH，文章可能会写的有点长，因为我想在开始前先吐槽一些东西。。。

吐槽OVH

OVH的工单支持（客服）这帮人真的是带薪摸鱼。虽然我知道OVH的工单支持一直都是垃圾，但是没想到可以拉到如此地步。。。这事情还得从10个多月前说起，起因是因为我发现了一个OVH控制面板的BUG：

我通过多个方法验证过，现在新购的OVH独立服务器，其实都是分配了/56 IPv6地址的，而且是全段路由，不需要用NDP代理，即使是Kimsufi这个系列的独立服务器也是如此。（并不是OVH面板上显示的/128。）这也就意味着/56的IPv6都可以把OVH面板上那个ff:ff:ff:ff结尾的IPv6当作网关使用，我当时在服务器上这么配置一点问题都没有。然而就在我从OVH面板购买了一个附加IPv4后，事情就变的没那么简单了。

我当时使用的是PVE桥接网络，OVH出于安全考虑，严格要求所有附加IPv4都必须申请一个虚拟MAC地址才能用在桥接网络上。（其实很多商家都是这样做的，比如Hetzner）这本来没什么问题对吧，我也成功将这个附加IPv4配置到虚拟机上用了。但是后面我就发现除了这台配置了虚拟MAC地址的虚拟机外，其他使用随机MAC地址的虚拟机IPv6都不通了。

到目前为止你还可以说它是一个预期行为对吧，在没有申请虚拟MAC地址前，服务器没有启用MAC地址过滤，所以那些使用随机MAC地址的虚拟机都能联网。现在是启用了MAC地址过滤的状态，那就只有OVH允许的MAC地址才能联网。但问题来了，OVH没有给IPv6也配备申请虚拟MAC地址的功能啊，这意味着如果你还想在虚拟机上用IPv6的话就得为每个虚拟机都购买一个附加IPv4，因为只有附加IPv4才能申请虚拟MAC地址。。你就说这操作sb不sb吧。。原本我能够开非常多的IPv6 Only虚拟机，但现在不行了，要用IPv6就必须买附加IPv4。。

更离谱的还在后面，即便我后续把这个虚拟MAC地址删除了，哪怕连这个附加IPv4服务取消了都无法关闭MAC地址过滤，我这台服务器的网络永远回不到最初的样子了。按正常的逻辑来说，MAC地址过滤是因为申请了虚拟MAC地址才启用的，现在我把虚拟MAC地址删除了，那MAC地址过滤也应该关闭才对吧，然而OVH不是这样的，这个MAC地址过滤只要开了就没地方关了。。我在OVH面板找不到任何关闭的地方，我还看了它们的API文档，压根就没有MAC地址过滤的API。。

我甚至多次测试过，每当我在OVH面板给一个附加IPv4添加或者删除虚拟MAC地址的时候，那些使用随机MAC地址的虚拟机都能够短暂联网。所以根据这个现象和我的经验判断：肯定是OVH在我删除了虚拟MAC地址后，它们的上游路由器或者是什么设备依旧在过滤MAC地址，导致我的虚拟机无法联网。

因此这摆明就是OVH的BUG，当时我就给OVH发了一个工单，结果等了几天的时间，过来处理的这个B一上来就是答非所问，敷衍了事，不解决我的问题，然后我也懒得鸟他了，我告诉你们的面板有BUG，你爱修不修，然后我就把工单关了。其实这BUG对我来说也没多大影响，我还有其他变通的方法可以继续开IPv6 Only虚拟机（我后面会说具体的方法），只是觉得已经有全段路由了，还去用那些方法有点膈应。。

时隔10个多月，我突然想起来我还有这样一台吃灰的机器，顺便我就想再发一个工单，看看换个客服能不能给我解决了，结果你猜怎么着？这个吊毛比上次那个更离谱，这是它回复我的内容，我竟然无言以对：

他好像说了又好像什么都没说，他好像说的很对又好像说的都不对，我还能说啥？能有这样的员工真是OVH的福份啊=-=你要从OVH官方的角度来说，确实Kimsufi系列官方一直只承认/128的IPv6，但现在实际都是/56。再者退一步，现在是虚拟MAC地址和MAC地址过滤的问题，和有多少可用IP也没关系吧。

我估计OVH真正核心的开发人员到现在都还不知道这个BUG，我在这里提醒一下用OVH服务器的人别踩我这个坑。如果你有使用IPv6的需求，同时又要使用OVH的附加IPv4，其实有几个变通的办法：

1.考虑将桥接网络改成路由网络，路由网络不需要虚拟MAC地址。（至于路由网络怎么配置这篇文章不做介绍，有机会单独用另外一篇文章说明）

2.已经申请了虚拟MAC地址了那IPv6还可以用NDP代理。类似的工具很多比如NDPPD，还有Linux内核本身就支持NDP代理，只是内核不支持代理整个子网，只能代理单个地址。

3.富哥专属：就如我之前说的为每台虚拟机都购买一个附加IPv4并且申请虚拟MAC地址。我甚至都怀疑OVH是不是故意的了=-=

这个问题我已经说的差不多了，但是接下来我还想吐槽OVH屎上雕花的技术那真是一绝。还是这台服务器，里面有4块HDD，其中有1块刚交付的时候我就发现是有问题的，我当时主动发了个工单要求把这块硬盘换掉，他们也很爽快，说换就换了。

没过多久哈，又有一块盘有问题了，我的邮箱也一直收到smart的报警邮件，但是因为这台服务器一直吃灰，我也懒得管就一直没处理，直到最近因为我想拿来用，索性我就把这台服务器的系统给重装了（通过OVH面板重装的）结果重装进度就一直卡着不动，取消也取消不了。就当我准备再次发工单的时候，我突然发现工单系统里面有一个我重装系统时，他们OVH自动发的一个硬件检查的工单，然后你猜怎么着？过了大约5小时，我发现不但系统重装好了，那块有问题的硬盘也被他们换掉了。一时间我竟不知所措：

我心想按OVH的尿性，工单都懒得回的，它竟然还会主动给我把坏掉的硬盘换了？我当真恰了一惊=-=

咱就是说OVH你能不能先把你那屎山代码堆起来的面板优化一下啊，能不能把精力放在重要的功能上啊，这种装系统时的硬件检查不能说完全没用吧，但基本没用吧。。有这个闲工夫搞这些花里胡哨的，不如先把屎山清理下？？？或者把IPv6也能申请虚拟MAC地址的功能给实装下？看看别人多少年前提的issue了。

我说个题外话啊，其实OVH整体给人的感觉就是乱七八糟的，面板布局乱，产品线也乱，工单系统更不用说了。然后还搞他妈一大堆分站，什么US区、IE区、CA区，哎哟看了脑壳都是大的，新人要注册个账号不看攻略连个网址都找不对。。与之能够相提并论的，我到目前为止也就只发现个甲骨文，甲骨文那个网页一看也是屎山。。

安装incus

以上吐槽仅代表我个人的观点，如有错误欢迎指正=-=，好了步入本文的正题。。。安装incus，推荐使用zabbly的存储库来安装。

导入存储库密钥：

mkdir -p /etc/apt/keyrings/
curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc

添加稳定版本的存储库：

nano /etc/apt/sources.list.d/zabbly-incus-stable.sources

写入如下内容：

Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/stable
Suites: trixie
Components: main
Architectures: amd64
Signed-By: /etc/apt/keyrings/zabbly.asc

安装inucs：

apt update
apt install incus btrfs-progs

初始化：

incus admin init

下面的步骤除了“存储池大小”要根据自己的服务器硬盘容量来配置，其他的都可以按回车保持默认：

Would you like to use clustering? (yes/no) [default=no]: 
Do you want to configure a new storage pool? (yes/no) [default=yes]: 
Name of the new storage pool [default=default]: 
Name of the storage backend to use (btrfs, dir, lvm, lvmcluster) [default=btrfs]:
Where should this storage pool store its data? [default=/var/lib/incus/storage-pools/default]: 
Would you like to create a new local network bridge? (yes/no) [default=yes]: 
What should the new bridge be called? [default=incusbr0]: 
What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: 
What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: 
Would you like the server to be available over the network? (yes/no) [default=no]: 
Would you like stale cached images to be updated automatically? (yes/no) [default=yes]: 
Would you like a YAML "init" preseed to be printed? (yes/no) [default=no]:

安装Web UI：

apt install incus-ui-canonical

配置Web UI监听地址：

incus config set core.https_address :8443

现在就可以通过：https://serverip:8443访问到Web UI。

这个Web UI的鉴权方式有点特殊，用的是证书认证。首次打开后，先在页面上生成证书（crt）：

生成证书（crt）的时候会让你输入一个密码，这个密码可以不输入直接跳过：

然后把证书（crt）传到服务器内，例如我传到服务器的/home/debian路径下，执行如下命令信任证书：

incus config trust add-certificate /home/debian/incus-ui.crt

回到Web UI下载证书（pfx），打开浏览器的证书管理界面：

chrome://certificate-manager/

点击如图所示选项：

点击导入：

点击下一步：

选择刚下载的pfx文件：

如果一切正常，现在就能登录到Web UI了：

incus网络配置

现在来配置网络。我们要知道inucs实际上有一个开箱即用的网络，也就是在刚才初始化的时候就配置好的，一般是incusbr0。这个网络具有NAT IPv4和NAT IPv6。NAT IPv4通过DHCPv4分发地址，NAT IPv6通过SLAAC分发地址。如果你对这个配置满意，那么不需要做任何修改直接就能拿来用。

这里有一个小坑，如果你的服务器安装了docker，docker会阻止incusbr0的通信，导致后续创建的虚拟机没有网络，在这种情况下必须修改docker配置：

nano /etc/docker/daemon.json

加入如下内容：

{
  "ip-forward-no-drop": true
}

重启服务器生效：

systemctl reboot

这样你就可以将docker和incus共存在一台服务器上了。

我现在想的是保留这个网络的NAT IPv4不做更改，将NAT IPv6改成独立IPv6，并且通过有状态（stateful）DHCPv6来分发地址。

简单说一下为什么用有状态（stateful）DHCPv6。首当其冲的原因是因为OVH这个睿智BUG，导致我只能用NDP代理，其次我又不想用NDPPD，因为这个软件有时候会有问题，有些IPv6邻居请求它代理不到，而且就算代理到了，它还有一个到期时间，如果到期后没人往你这个IPv6发送数据，这个IPv6就失联了，你还需要去PING一下才能代理到。然后我看了下systemd-networkd的文档，发现它是支持NDP代理的，但是它和Linux内核一样，只支持代理单个地址不支持子网，我们知道SLAAC分配地址是需要一个/64子网的，并且是根据机器MAC地址来生成最终的IPv6地址的，在这种情况下我不能保证/64子网下的每一个IPv6都能用，所以自然就不能用SLAAC。

在文章开头的时候就说了，这台Debian服务器使用的是netplan+systemd-networkd来管理网络，netplan本身是不支持配置NDP代理的，但是netplan使用的后端systemd-networkd是支持的，所以接下来我们可以创建一个覆盖配置（override），来增加我们需要的NDP代理功能。

你可以通过ip a命令先确定主机使用的接口名，这里假设主机的接口名是eno1，那么创建一个带有主机接口名的目录：

mkdir /etc/systemd/network/10-netplan-eno1.network.d

接着在目录内新建一个conf：

nano /etc/systemd/network/10-netplan-eno1.network.d/proxy.conf

写入如下配置，可根据自己的需要增加或者删除IPv6地址：

[Network]
IPv6ProxyNDP=true
IPv6ProxyNDPAddress=2607:5300:60:8401::1
IPv6ProxyNDPAddress=2607:5300:60:8401::2
IPv6ProxyNDPAddress=2607:5300:60:8401::3
IPv6ProxyNDPAddress=2607:5300:60:8401::4
IPv6ProxyNDPAddress=2607:5300:60:8401::5
IPv6ProxyNDPAddress=2607:5300:60:8401::6
IPv6ProxyNDPAddress=2607:5300:60:8401::7
IPv6ProxyNDPAddress=2607:5300:60:8401::8
IPv6ProxyNDPAddress=2607:5300:60:8401::9
IPv6ProxyNDPAddress=2607:5300:60:8401::a
IPv6ProxyNDPAddress=2607:5300:60:8401::b
IPv6ProxyNDPAddress=2607:5300:60:8401::c
IPv6ProxyNDPAddress=2607:5300:60:8401::d
IPv6ProxyNDPAddress=2607:5300:60:8401::e
IPv6ProxyNDPAddress=2607:5300:60:8401::f
IPv6ProxyNDPAddress=2607:5300:60:8401::10

使配置生效：

netplan generate
netplan apply

验证NDP代理是否启用：

sysctl -a | grep proxy_ndp

如果正常的话应该在eno1接口看到proxy_ndp值为1：

net.ipv6.conf.all.proxy_ndp = 0
net.ipv6.conf.default.proxy_ndp = 0
net.ipv6.conf.docker0.proxy_ndp = 0
net.ipv6.conf.eno1.proxy_ndp = 1
net.ipv6.conf.eno2.proxy_ndp = 0
net.ipv6.conf.incusbr0.proxy_ndp = 0
net.ipv6.conf.lo.proxy_ndp = 0
net.ipv6.conf.tap5ac79f9f.proxy_ndp = 0
net.ipv6.conf.vethb2d8638f.proxy_ndp = 0

验证NDP代理是否生效：

ip -6 neighbor show proxy

如果正常的话应该能够回显在systemd-networkd内配置的IPv6地址：

回到Web UI，编辑这个incusbr0网络，配置IPv6地址：

还是在这个页面往下翻，把IPv6 NAT关闭，把IPv6 DHCP打开，把IPv6 DHCP expiry改成一个特别大的值，例如15年（稍后我会说明原因）。把IPv6 DHCP ranges配置为你启用NDP代理的IPv6地址范围，例如：2607:5300:60:8401::2-2607:5300:60:8401::10。把IPv6 DHCP stateful打开，所有配置如下图所示：

也可以复制下面的YAML配置进行修改：

project: default
name: incusbr0
description: ''
type: bridge
config:
  ipv4.address: 10.38.58.1/24
  ipv4.nat: 'true'
  ipv6.address: 2607:5300:60:8401::1/64
  ipv6.dhcp: 'true'
  ipv6.dhcp.expiry: '473353890'
  ipv6.dhcp.ranges: 2607:5300:60:8401::2-2607:5300:60:8401::10
  ipv6.dhcp.stateful: 'true'
  ipv6.nat: 'false'

incus Web UI支持YAML配置：

incus网络安全

接下来我想简单说一下关于incus网络安全的配置。只使用上面这个配置的话，实例确实拥有了访问网络的能力，如果这只是一个测试环境，或者说这些实例只有你自己一个人用的话，那没什么问题。但是如果这是一个生产环境，这些实例创建了之后还要给其他人用，那么上面的这个配置就不够了，因为连最基本的MAC地址过滤都没有，你怎么能够保证网络内没有人搞坏事，比如MAC地址欺骗，又或者有坏B把实例的IP瞎坤8乱改，导致和别的实例IP冲突？这些都是要解决的问题。

好在incus的桥接网络原生支持这些安全功能，所以我们可以很简单的进行配置，首先在主机加载br_netfilter模块（ipv6_filtering所需）：

modprobe br_netfilter
lsmod | grep br_netfilter # 检查模块是否加载成功

配置开机自动加载br_netfilter模块：

nano /etc/modules-load.d/modules.conf

写入如下内容：

br_netfilter

接着在Web UI找到Profiles–>Default–>Configuration，启用YAML配置：

在network: incusbr0加入如下配置，这样就可以防止MAC地址欺骗、IPv4地址欺骗、IPv6地址欺骗：

name: default
description: Default Incus profile
devices:
  eth0:
    network: incusbr0
    security.ipv4_filtering: 'true'
    security.ipv6_filtering: 'true'
    security.mac_filtering: 'true'
    type: nic
...

你还可以加入如下配置用于阻止实例到实例的流量，也就是网络隔离：

security.port_isolation: 'true'

到这里我就要解释一下为什么之前要把IPv6 DHCP expiry（DHCP租约）改成一个特别大的值，原因是目前incus的ipv6_filtering功能有BUG，它往nftables里面添加的规则有问题，这些规则会阻止正常的dhcp6 reply流量。

incus是通过dnsmasq来实现dhcp功能的，默认情况下只配置了1小时的租约时间，这会导致虚拟机在租约过期后丢失IPv6地址。我已经在incus的论坛发过帖子了，开发者说会尽快找到原因并解决，所以这里临时想到这个办法解决。

其实这个问题真的很玄学，目前连incus的作者都不知道问题到底在哪=-=，有大佬知道的，也可以去incus论坛交流下。。。~~当然实际上哈，dnsmasq对有状态（stateful）DHCPv6的支持本身就不好，如果环境允许，最好还是用SLAAC。这也是incus目前针对IPv6地址分配的默认方案。~~

cloud-init配置

接下来讲一下incus与cloud-init的配置。我们要知道cloud-init要想正常工作的话，要满足2个基本条件：

1.实例内的系统安装了cloud-init软件包。实例指：容器（LXC）或虚拟机（KVM）

2.虚拟化平台（例如incus、Proxmox VE）自身要支持cloud-init的配置。

这两个条件incus都是满足的，而且可以做到开箱即用。incus官方提供的系统镜像（模板），无论是容器（LXC）还是虚拟机（KVN）都已经预装了cloud-init软件包。

现在我们来到incus Web UI的Profiles–>Default–>Cloud-init页面：

可以看到这里有3个配置项Network config、User data、Vendor data。这分别代表什么意思呢？让我简单介绍一下。

Network config顾名思义就是用来配置实例网络的，如果你不需要修改实例的网络配置可以留空。这里我还是给出一个配置示例，默认情况下cloud-init仅在第一个接口启用dhcp，如果你给实例添加了第二个接口，要让第二个接口也启用dhcp，可以使用下面的配置：

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      dhcp6: true
    eth1:
      dhcp4: true
      dhcp6: true

重点在于Vendor data（供应商数据）、User data（用户数据），这两者都是给cloud-init提供cloud-config-data的，但主要区别如下：

1.Vendor data（供应商数据）一般用于默认配置，而User data（用户数据）用于特定实例的配置。

2.Vendor data（供应商数据）默认情况下，仅在实例首次启动时运行。

打个比方，现在你是一个VPS商家，你作为一个VPS商家就相当于是一个供应商，你在给你的系统镜像做定制化内容的时候，应该使用Vendor data（供应商数据）。而你的客户购买了你的VPS，他们就是你的用户，用户如果要给自己的VPS系统做定制化内容，应该使用User data（用户数据）。

假设你想给系统镜像修改默认时区、预装一些软件包、启用ssh的root用户登录，这些配置应该写在Vendor data（供应商数据）内：

#cloud-config
timezone: Asia/Shanghai
packages:
  - sudo
  - git
  - wget
  - curl
  - htop
  - nano
  - openssh-server
runcmd:
  - sed -i 's/#PermitRootLogin.*/PermitRootLogin yes/g' /etc/ssh/sshd_config
  - sed -i 's/PasswordAuthentication.*/PasswordAuthentication yes/g' /etc/ssh/sshd_config
  - systemctl reload sshd

假设用户想为自己的VPS系统配置ssh密钥登录，他们应该将ssh公钥写在User data（用户数据）内：

#cloud-config
users:
  - name: imlala
    groups: sudo
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC2NzaX1lZDI1NTE5AAAXIPZTKfl2X7TWJZmvok/+6qHzKceuGpXzst+nN77NMu05

注意配置的格式，Vendor data（供应商数据）和User data（用户数据）开头必须指定#cloud-config，而Network config无须指定。你可以在实例内使用如下命令对配置进行检查，如果有错误会提示你：

cloud-init schema --system --annotate

现在想象一下，如果一开始你把某个客户（用户）的ssh公钥错误的配置在了Vendor data（供应商数据）内，那拥有这个ssh私钥的人不是就可以登录你所有的VPS了？又或者说你故意在Vendor data（供应商数据）内配置一个自己的ssh公钥，那这就等于放了个后门，这是很可怕的，所以一定要谨慎配置。

另外，我们还需要注意在incus中，实例创建的时候必须指定一个Profiles，一个实例的默认配置是由Profiles提供的。按正常逻辑来说，我们只应该在Profiles内配置cloud-init的Vendor data（供应商数据），在特定的实例中单独配置User data（用户数据）。

如果你在Profiles同时配置了Vendor data（供应商数据）、User data（用户数据），那么即便遵循了上面的配置指南，也无法真正做到供应商和用户配置的分离。这是因为Profiles会同时把Vendor data（供应商数据）、User data（用户数据）都当作默认配置提供给实例。所以最好的做法是在Profiles内保持User data（用户数据）为空。

当然如果这个incus只有你自己一个人用，上面举例的这些配置写到Vendor data（供应商数据）还是User data（用户数据）都没什么区别，具体还是要看自己的实际使用环境。

创建一台Linux实例

在做好上面的配置后，现在就可以尝试创建一台实例了，这里以创建Debian13为例：

选择系统镜像，Variant选择cloud，Type这里选择all，这种镜像是同时支持容器（LXC）、虚拟机（KVM）的：

就如同之前说的，每个实例必须指定一个Profiles：

可以看到每个实例是可以单独配置cloud-init的，如果要覆盖Profiles的cloud-init配置就可以在这里进行设置：

由于这个incus只有我一个人用，为了方便起见，我不想每次创建虚拟机的时候都配置一遍ssh公钥，所以我直接把ssh公钥相关的内容写到了Profiles cloud-init的User data（用户数据）

配置实例的CPU、内存：

实例创建完成后，登录进去测试下：

添加Proxy device

Proxy device是incus一个非常实用的功能，你可以简单理解为这是一个端口转发的功能，可以暴露内网的服务到外网，特别适合那些没有公网IP的NAT网络。

假设我想把刚才创建的Debian13实例的SSH端口（22）暴露到外网，可以在Web UI这样配置：

YAML配置，其中10.38.58.3是实例的内网IP地址：

architecture: x86_64
config:
  image.architecture: amd64
...
devices:
  proxy-1:
    bind: host
    connect: tcp:10.38.58.3:22
    listen: tcp:0.0.0.0:50022
    nat: 'false'
    type: proxy
...

当连接主机的hostip:50022就相当于连接实例的10.38.58.3:22端口了：

实际上这东西还不仅仅只是端口转发，玩法很多，可以自己摸索一下。

创建Windows11虚拟机

说句实话，incus对KVM的支持不如Proxmox VE完善，尤其是当你要安装Windows系统的时候。实际体验肯定是不如Proxmox VE的。

我的建议是最好不要在incus上创建Windows虚拟机。如果你硬要用的话，这里介绍两种安装方式：

1.通过incus官方提供的distrobuilder工具重新打包Windows iso写入virtio驱动。

2.使用io.bus=usb挂载Windows和virtio驱动iso。这是incus 6.11版本加入的新功能。

如果你的incus版本高于6.11我个人推荐第二种安装方式，毕竟第一种方式要安装很多不必要的软件包，而且这种方式有点hack，侵入性太大。第二种更原生，而且性能更好。

方式一：使用distrobuilder

第一种安装方式，在主机安装snap和需要用到的依赖包：

apt install snapd
apt install libwin-hivex-perl wimtools genisoimage

使用snap安装distrobuilder：

snap install distrobuilder --edge --classic

重新打包iso：

distrobuilder repack-windows --windows-arch=amd64 Win11_24H2_Chinese_Simplified_x64.iso Win11_24H2_Chinese_Simplified_x64_virtio.iso

把iso导入到默认的存储卷：

incus storage volume import default /root/Win11_24H2_Chinese_Simplified_x64_virtio.iso windows11-iso --type=iso

转到Web UI创建实例，选择自定义ISO：

选择刚才导入的ISO文件：

添加TPM设备：

启动虚拟机访问控制台应该就能看到Windows安装界面了，安装过程中一直下一步就完事了。

方式二：io.bus=usb挂载ISO

第二种安装方式，创建虚拟机只能使用命令操作，因为有些设置目前Web UI还不支持：

incus init win11 --empty --vm -c limits.cpu=4 -c limits.memory=8GiB -c image.os="Windows 11" -d root,size=80GiB -d root,io.bus=virtio-scsi -d root,io.cache=writeback
incus config device add win11 install disk source=/root/Win11_24H2_Chinese_Simplified_x64.iso boot.priority=10 io.bus=usb
incus config device add win11 virtio disk source=/root/virtio-win.iso io.bus=usb
incus config device add win11 incus_agent disk source=agent:config
incus config device add win11 vtpm tpm path=/dev/tpm0

这里有个坑，如果你待会用控制台安装系统的时候鼠标会产生偏移或者说不同步，使用下面的命令添加一个usb-tablet设备即可解决：

incus config set win11 raw.qemu -- "-device usb-tablet"

启动虚拟机：

incus start win11

访问Web UI打开控制台，如果你手速够快的话，按键盘任意按键应该能直接进到Windows的安装界面，手速不快的话就只能在这个界面等5分钟左右了，这不是错误哈，这是预期行为：

之后会出现下面这个界面，选择第一项回车确认：

在这个界面立即按键盘任意按键即可进入Windows的安装界面：

选择安装Windows11：

在这个界面你会发现找不到可以安装的硬盘，没关系这是正常的，因为我们指定的硬盘设备是virtio-scsi，Windows没有相关驱动，点Load Driver开始安装驱动：

这里需要安装的驱动很多，首先是硬盘驱动：

硬盘驱动安装完成后你就可以看到之前分配的80G硬盘显示出来了，但是不要慌，还是点Load Driver重复之前的步骤来安装其他驱动：

由于Windows这个傻吊系统不能批量安装驱动，你还需要重复这个步骤至少安装下面列出的驱动，这里我就不截图了，按照名字找到对应的路径即可：

1.NetKVM（网卡驱动）路径：NetKVM\w11\amd64
2.Balloom（内存气球）路径：Balloon\w11\amd64

系统安装完成后再把剩下的驱动补全，直接运行virtio-win-gt-x64.msi安装即可：

virtio-win-gt-x64.msi好像还装不全，我遇到还剩一个没装上，这时候需要检查丢失的驱动程序，具体操作如下：

1.转到计算机管理–>设备管理器，查看任何未知设备。
2.右键单击选择“更新驱动程序”。
3.选择“浏览我的计算机以查找驱动程序软件”。
4.选择virtio-win驱动程序CD。确保选中“包括子文件夹”。
5.找到驱动程序后，系统会自动安装”。

incus自身还有一个agent，在系统内通过命令行运行：

这个agent目前的功能非常有限，只支持显示操作系统版本、文件传输和非交互式的命令执行：

全部完成后，你可以删除不再需要用到的设备：

incus config device remove win11 install
incus config device remove win11 virtio

这篇文章还有一个坑没填，也就是我之前说的，dnsmasq对有状态DHCPv6的支持不好，有些系统比如Windows，它会分配多个IPv6地址：

并且我测试系统内IPv6是不通的。作为一个临时解决办法，查看dnsmasq的hosts配置：

cd /var/lib/incus/networks/incusbr0/dnsmasq.hosts/win11.eth0

这里会列出虚拟机绑定的IPv6地址：

10:66:6a:e0:86:b5,10.38.58.2,[2607:5300:60:8401::9],win11

编辑dnsmasq租约配置文件：

nano /var/lib/incus/networks/incusbr0/dnsmasq.leases

删除没有在win11.eth0列出的IPv6地址：

2232654908 34629226 2607:5300:60:8401::8 * 00:01:00:01:30:6e:85:ea:10:66:6a:d1:56:41
2232654908 34629226 2607:5300:60:8401::4 * 00:01:00:01:30:6e:85:ea:10:66:6a:d1:56:41

然后重启虚拟机测试，如果还不行就直接在虚拟机内关闭DHCP，改成静态IP。

我后面还测试了SLAAC，这个Windows系统是真的牛逼，SLAAC也不行。。它还是会分配多个IPv6地址，在用SLAAC的时候Windows会生成一个临时IPv6地址，这个在Windows里面叫做隐私保护地址。。然而在启用ipv6_filtering的情况下，nftables里面的规则是只允许那个根据MAC地址生成的IPv6地址流量的，这系统搞个隐私地址出来，这个隐私地址的流量都会被drop掉。。我后面懒得折腾了，反正我小鸡也不用Windows。。不了了之了。。。总结一下就是这三方在互相打架：incus的ipv6_filtering、dnsmasq的dhcp、windows系统，没有一个很完美的配置能够让它们互相兼容。。。