If you google way back, you’ll find some dated writeups. Unfortunately, there’s been enough change that I found them mostly unhelpful. Working from first principles, you’ll need
- A controller (region+rack).
- One or more virtual client systems to manage
- 2 network interfaces
- One to communicate to the outside world. Consider NAT with port forwarding, but bridged could work well too.
- One for the controller to speak to the systems to be controlled (internal network)
Now things get “interesting”. Multiple approaches are then possible. Modeling the real world most closely, create your region+rack controller VM, and install MAAS (apt or snap, dealers choice). Then you can create one or more client systems, attach them only to the internal network, and away you go. Unfortunately, there’s no power control type, so you’ll need to toggle power manually. I’ve had this work in VBox 5.22 and 6 and with various versions of MAAS (mostly older ones).
A different approach is to leverage the POD facility, Vbox 6 still has a bug with nested VT-x, so you’ll need to poke around in the virtualbox fora or documentation, and use the command line to enable it, if you want all of the systems to be virtual machines in their own right.
Logically, the LXD pod facility should be able to used, if you poke around you can see I’ve had that stall (I can configure the pod, but created nodes fail to commision).
Macs have the bhyve hypervisor (e.g. brew install xhyve) and logically one would think it should be “easy” to have MAAS configured to talk to the xhyve (akin to the virsh, qemu+ssh) host and create VMs that way. Aside from the control bits, you have to tweak the networking.
You can find an old Canonical writeup (circa 2015) with a great writeup on how to do MAAS demos on a mac laptop. Unfortunately the code is stale, and the instructions are no longer particularly useful.
It would be a great kindness for someone at Canonical to resurrect that aged 2015 entry and keep it updated with the best approach(es) for 2020, MAAS 2.7/2.8. Indeed, as such demos are often a necessary first step (either as an educational tool or a management dog and pony) having this as part of the release Documentation would be ideal. I’d argue, Mac, Windows and Ubuntu examples would be ideal (especially if the best approach turns out to be slightly different for the different platforms!).