To clarify, the way that conjure-up canonical-kubernetes works is: conjure-up drives Juju and asks it to deploy the cluster to whatever the appropriate cloud is (in this case, MAAS), Juju then asks MAAS to give it machines (or, in this case, spin up VMs) for each node needed to run the cluster, Juju then deploys the appropriate charm code for each application to the VMs, and finally the charm code installs and configures the appropriate kubernetes or other components for the role that that VM is playing in the cluster.

The "try was stopped" error from conjure-up is originally coming from Juju, probably due to the VMs being stopped out from under it. Manually running juju list-models might provide some more info there, but I certainly would expect Juju to provide a better error message than that.

As for where the VMs came from in the first place, it's hard to say without more info. The conjure-up logs (in ~/.cache/conjure-up/conjure-up.log) would be very helpful. Is it possible that you ran conjure-up multiple times? Each time you ran that, it would create a new model in Juju with a new deployment of Kubernetes, which would take up ~8 new VMs. If you encountered some error when running conjure-up, it may still have started the cluster but failed watching for it to become ready or in doing one of the post-processing steps. Again, that info would be in the conjure-up.log file.

Once you have started a deployment, you can use juju list-models and juju status -m <model-name> to check the status of the deployment using Juju. This will provide details about exactly which machines the cluster is using for which units, as well as what the status of each of those machines according to the charm (i.e., whether it's successfully participating in the cluster).