@stgraber Stéphane, I have an interesting problem. After lxd-to-incus migration of my production server, I have a Windows 11 Incus VM that I created way back in the early days as a LXD VM. In Incus my win11 Incus VM that was migrated is working perfectly. However, an “incus list” never shows an IP address. How can I fix this?
I should clarify that the instance has an IP address. It is just not being listed with an “incus list”.
For VMs where there’s no agent, Incus has to rely on the DHCP lease information for the VM and line that up with its own records.
stgraber@dakara:~$ sudo cat /var/lib/incus/networks/incusbr0/dnsmasq.hosts/win11.eth0
00:16:3e:16:48:d6,win11
stgraber@dakara:~$ sudo cat /var/lib/incus/networks/incusbr0/dnsmasq.leases | grep win11
1708724337 00:16:3e:16:48:d6 172.17.250.35 win11 01:00:16:3e:16:48:d6
That assumes a network that Incus itself controls, if this is just bridged to an external network, then the only thing we can try to do is look for anything in the ip neighbor table for the MAC address but that rarely provides useful data.
Is there any such thing as a “Windows” agent? I suspect not. Yes, this Incus VM is bridged to the main LAN.
Not yet. It’s something we’d love to have though, I dream of the day where I can do incus exec win11 powershell and then use that for demos 
The main blocker so far has been the vsock support on Windows which Red Hat has been working on a bit over the years but which last I checked wasn’t yet supported.
Yes, I was aware. By the way, I noticed that in migrating the win11 LXD VM to Incus that I had to change:
lxc config set win11 raw.qemu -- "-device intel-hda -device hda-duplex"
to:
incus config set win11 raw.qemu -- "-device intel-hda -device hda-duplex -audio spice"
After the migration, the win11 LXD VM would not boot. I made the change to the sound and all is well now.
Yeah, I think @jdstrand mentioned that too. I don’t think it’s an Incus thing so much as the QEMU version in use or maybe how QEMU is built in my package.
Any thoughts on reporting the address of a Windows or other non-Linux container address back to the CLI in the case of a bridged network? It’s been awhile and was wondering if that was on the table for a future addition.
Things haven’t really moved there. We still need a working vsock driver for Windows so we can get the agent running on there.
We did do the work to allow for multiple builds of the agent to be exposed by Incus, so we can now cover multiple operating systems and architectures, but we still need those operating systems to have working drivers for:
I am guessing that is a Redhat virtio effort then?
Yeah. I haven’t checked in a few months, but there’s code for the vsock driver, it’s likely just not functional enough or tested enough to have it be included in the resulting driver .iso.
Once the driver is included the next question is going to be on how to use it.
We won’t be able to use the same Go packages on Windows as we do Linux, so some work will be needed at that level to get something working.