Win vm hangs on reboot only

I have a win11 vm which fails to reboot and hangs in the zabby “Start boot option” screen. Normal shutdown / startup works as expected.

Do others have the same problem? In

EDIT: Initially I suspected a failed install of uefi keys was the cause but even when I managed to run successfully the updates to install the keys via powershell the windows vm still hangs on reboot.

My config looks currently like this:

architecture: x86_64
config:
  limits.cpu: "4"
  limits.memory: 6GiB
  security.secureboot: "true"
  volatile.base_image: 749772151b3dd4244dd47865c38b2308abd09e4ef59eb703aa105e704ef13063
  volatile.cloud-init.instance-id: b1fa9b1c-5fe7-4f9e-bacc-82956897cb91
  volatile.eth0.host_name: tapfec0dcc1
  volatile.eth0.hwaddr: 00:16:3e:72:64:cc
  volatile.last_state.power: RUNNING
  volatile.last_state.ready: "false"
  volatile.uuid: 9c122b8f-15f1-43b1-809d-9a154a01bf50
  volatile.uuid.generation: 9c122b8f-15f1-43b1-809d-9a154a01bf50
  volatile.vm.definition: pc-q35-10.2
  volatile.vm.rtc_adjustment: "7201"
  volatile.vm.rtc_offset: "-1"
  volatile.vsock_id: "1640953701"
devices:
  eth0:
    name: eth0
    nictype: bridged
    parent: br5
    type: nic
  root:
    path: /
    pool: ssd1
    type: disk
  vtpm:
    type: tpm

With incus info --show-log qemu.log is empty:

Log (qemu.log):

incus console --show-log just shows

BdsDxe: loading Boot0007 "Windows Boot Manager" from HD(1,GPT,149B5F59-0BF9-4A25-9F64-E41F5FDBA68B,0x800,0x32000)/\EFI\Microsoft\Boot\bootmgfw.efi
BdsDxe: starting Boot0007 "Windows Boot Manager" from HD(1,GPT,149B5F59-0BF9-4A25-9F64-E41F5FDBA68B,0x800,0x32000)/\EFI\Microsoft\Boot\bootmgfw.efi

but I don’t see the usual curling circle from windows when starting.
Only way around is to kill the vm and do a simple start.

Any Idea how to analyse/fix this?

So if you shutdown the VM from Windows and then start it back from Incus it boots fine?

The log message you’re showing would indicate that the Windows bootloader was run. Windows won’t be logging anything on the text console after that, so you really need to look at the VGA console instead (incus console --type=vga)

yes, once shutdown (–force), the vm starts fine.
The vga console does not show anything more (mentioned in my fist post as link)

Any idea if the issue is on windows or on vm side and how to dig into that?

Make sure that image.os is set to something that starts with Windows. And make sure all the VirtIO drivers are installed in the VM.

If that’s the case, then you could try:

incus config device add VM agent disk source=agent:config

Which will add a cdrom drive to the VM for use with our Windows agent. Doing that, even if you don’t use it, will prevent the fast reboot logic that Incus has and will force every reboot to go through stop+start.

Thanks @stgraber ,

this procedure fixed it:

  • (re)install latest version of VirtIO win drivers (maybe the installed were no longer compatible?)
  • incus config set VM image.os=Windows
  • incus config device add VM agent disk source=agent:config

additionally I used the powershell script in the agent disk to install the Incus-Agent in windows but starting this service fails with:

Failed to start HTTP server: Failed to get listener: WINDOWS: Failed to listen on vsock: listen vsock vm(4294967295):8443: An address incompatible with the requested protocol was used.

so I guess this is not intended to be used this way? My hope was to get the vm’s ip in the incus list

EDIT: see next post for fixing agent issue:

right click on "D:\viosock\w11\amd64\viosock.inf" → Install
and the agent starts and reports the correct ip in incus list:

1 Like

You need to install the vsock driver. It’s on the virtio driver ISO but is not installed automatically by the driver installer.

1 Like

wow - right click on "D:\viosock\w11\amd64\viosock.inf" → Install
and the agent starts and reports the correct ip in incus list:

+-----------------+---------+--------------------------+------+-----------------+-----------+
|      NAME       |  STATE  |           IPV4           | IPV6 |      TYPE       | SNAPSHOTS |
+-----------------+---------+--------------------------+------+-----------------+-----------+
| win11-ecm4utest | RUNNING | 192.168.12.20 (Ethernet) |      | VIRTUAL-MACHINE | 34        |
+-----------------+---------+--------------------------+------+-----------------+-----------+

I will collect these “hidden secrets” together into a howto …
Thanks so much!

1 Like

last note: since the latest version seems to be crucial and not maintained by windows updates, it should be best practice to define a background job doing the update via winget like

winget upgrade --disable-interactivity -e --id RedHat.VirtIO

same of cource for new install:

winget install -e --id RedHat.VirtIO
1 Like