@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?
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.
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.
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:
virtio-serial (to notify Incus that the agent is operational)
virtio-vsock (to handle the agent secure REST API)
9pfs (to fetch the agent binary, configuration and keys)
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.