Thanks for the feedback on the latest beta; I saw your comment on bug #1800573. That bug is more general, but we are also looking at fixing a more specific issue which likely has the same root cause - bug #1801420.
If you could post any relevant logging on the more specific bug, that could be helpful. For example, the rsyslog output from
/var/log/maas/rsyslog/<host> on the controller, and
/var/log/cloud-init*.log from the installed system would be helpful. I would also check the event log for the machine; I’ve seen a few cases where MAAS reports in the event log that it cannot log into the KVM host after deployment.
That said, if the new deploy-time configuration feature isn’t working properly and you still want to test KVM pods in general, there should be no problem with simply deploying the machine and using basically the same procedure we use to set up the KVM pod. There is only one caveat: when you use the checkbox to deploy KVM, we use a feature that is only exposed via the API when you deploy the machine:
bridge_all=true. This causes a bridge to be automatically created for every interface we find on the machine. The advantage of doing this is that you can reach VMs from the host itself. In the absence of the ability to attach to a bridge, a
macvtap type connection will be attempted, which should allow the VM to be attached directly to a physical interface.
The new networking features require the MAAS database to be up-to-date, so that when you ask for an interface on a specific network, we know which interface to attach to. So if you want to deploy the machine manually and then configure the pod, you just need to be careful to not change anything about the network configuration, such as interface names, addition of bridges, etc.