Question about booting Windows 10 in Incus using a virtual machine

I’m trying to open a win10 VM on debian12, but I’m having some problems troubleshooting it

incus init winvm --empty --vm
incus config device override winvm root size=30GiB
incus config set winvm limits.cpu=3
incus config set winvm limits.memory=4GiB
incus config device add winvm vtpm tpm path=/dev/tpm0
incus config device add winvm install disk \
  source=/root/win.incus.iso \
  boot.priority=10
DEV=$(lshw -C network | awk '/logical name:/{print $3}' | head -1)
CIDR=$(incus network show incusbr0 | awk -F: '/ipv4.address/ {gsub(/ /,"",$2); print $2}')
PREFIX=${CIDR%/*}             
PLEN=${CIDR#*/}              
BASE=${PREFIX%.*}            
START=2                      
END=$(( 2**(32-PLEN) - 2 ))
USED=$(incus network list-leases incusbr0 | awk '{print $2}' | grep -E "^${BASE}\." || true)
for i in $(seq $START $END); do
    IP="${BASE}.${i}"
    if ! grep -qx "$IP" <<< "$USED"; then
        FREE_IP="$IP"
        break
    fi
done
incus config device override winvm "$DEV" ipv4.address="$FREE_IP"

Result:

root@www:~# incus config show winvm
architecture: x86_64
config:
  limits.cpu: "3"
  limits.memory: 4GiB
  volatile.cloud-init.instance-id: f5ec860a-4a56-4fd2-9d25-6a2bbe923207
  volatile.eth0.host_name: tapfe76f65d
  volatile.eth0.hwaddr: 10:66:6a:c0:d0:f4
  volatile.last_state.power: RUNNING
  volatile.last_state.ready: "false"
  volatile.uuid: 568e02c2-e1e0-4ed8-98f6-65d0e5748d1f
  volatile.uuid.generation: 568e02c2-e1e0-4ed8-98f6-65d0e5748d1f
  volatile.vm.definition: pc-q35-9.0
  volatile.vsock_id: "1457712359"
devices:
  eth0:
    ipv4.address: 10.89.194.2
    name: eth0
    network: incusbr0
    type: nic
  install:
    boot.priority: "10"
    source: /root/win.incus.iso
    type: disk
  root:
    path: /
    pool: default
    size: 30GiB
    type: disk
  vtpm:
    path: /dev/tpm0
    type: tpm
ephemeral: false
profiles:
- default
stateful: false
description: ""
+-------+---------+----------------------+-----------------------------------------------+-----------------+-----------+
| NAME  |  STATE  |         IPV4         |                     IPV6                      |      TYPE       | SNAPSHOTS |
+-------+---------+----------------------+-----------------------------------------------+-----------------+-----------+
| test  | RUNNING | 10.89.194.187 (eth0) | fd42:763:4dc3:3e7f:1266:6aff:fe4a:9d79 (eth0) | CONTAINER       | 0         |
|       |         |                      | 2607:5300:xxxxxxxxxxxxxxxxxxx (eth1) |                 |           |
+-------+---------+----------------------+-----------------------------------------------+-----------------+-----------+
| winvm | RUNNING |                      | fd42:763:4dc3:3e7f:1266:6aff:fec0:d0f4 (eth0) | VIRTUAL-MACHINE | 0         |
+-------+---------+----------------------+-----------------------------------------------+-----------------+-----------+

I’ve noticed that the IPV4 address is never appended, even when I manually add the address

The zabbly on the front end of the spice is spinning in circles for over 20 minutes without any prompts for the next step, am I missing something in the setup?

The system image has been patched.

distrobuilder repack-windows \
  --windows-arch=amd64 \
  win.iso \
  win.incus.iso
incus start winvm
sleep 1
SERVER_IP=$(hostname -I | awk '{print $1}')
nohup websockify --web /usr/share/spice-html5 6080 \
         --unix-target=/run/incus/winvm/qemu.spice \
       > /var/log/websockify-winvm.log 2>&1 &
echo "SPICE HTML5 console on http://${SERVER_IP}:6080/spice_auto.html"

Hi!

My understanding is that when you try to incus config device override the ipv4.address field for the eth0 network interface, then the Windows VM does not boot up. Is that a fair description?
But if you do not override the IPv4, does the VM manage to boot up?

I don’t think that’s it, I have tried to remove it but it doesn’t work. I use ProxmoxVE to do the same thing and I found out that it might be an issue with the CPU not supporting some QEMU default parameters, I will try to test it later on DigitalOcean to avoid possible CPU type issues.

No problem now, cpu type make this mistake.

The final guide I summarized is below:

1 Like