Hi,
I was trying out maas 2.5.0 in a bionic vm, and the pod feature. I gave it access to my host’s libvirt via the url “qemu+ssh://andreas@10.0.5.1/system”, where I have other vms already, and was very surprised to see maas immediately commissioning my existing vms, including windows ones.
I was expecting ti be able to use pods to just easily create new vms for maas, like a mini cloud. The fact that it grabbed existing VMs and started owning them was surprising for me. Is this expected?
This has been previously reported as a bug and was given the “Won’t Fix” status:
https://bugs.launchpad.net/maas/+bug/1696512
I would suggest from my view there is merit to re-opening this bug with the goal of at least clarifying this in the UI.
I was actually caught off guard about this during development, too. That’s why my MAAS test environment post suggests creating a container to host the hypervisor.
Another idea I remember we discussed was using a “prefix filter”, such as how Add Hardware > Chassis works, so that MAAS only manages and creates VMs with a specified string prefixed to the VM name.
If we should clarify this in the UI, we should open a new bug for that, since the old bug was already decided on as a Won't Fix.
On the other hand, if there is another a way to solve this in a way that’s simple for users and doesn’t cause excessive complexity/maintenance in the MAAS code, let’s discuss. How would you like to see this fixed, ideally?
MAAS supports KVM in two different ways. The old way was via “Chassis” and the new way is “Fully managed KVM host (a.k.a pods)”.
In the chassis support, MAAS didn’t manage the host itself. It only discovered available machines, commissioned them, and made them available for deployment. However, on a “virsh” chassis, we allowed filtering via a prefix.
In the pod, the story is different. A pod is where MAAS fully manages the pod source. MAAS takes ownership of it as a whole, and all of the resources. If the user where to have pre-created VMs (or machines in the case of RSD), MAAS will take ownership of them given that it manages the infrastructure as a whole. In order to effectively have information about the machine to make it deployable, then MAAS will commission them. That said, IIRC, the API allows you to prevent commissioning all those pre-created VMs, but it is not surfaced on the UI because that’s not the desired behavior.
Furthermore, the support of KVM host as now supported relies on MAAS being able to create storage devices and network attachments, and for that MAAS needs to completely own the it. Hence the supported path to achieve that is by ensuring the MAAS has deployed the KVM host (which 2.5+ now supports).
Hope this helps.
I think a warning in the UI is needed. It was very much unexpected to me that MAAS would take over existing VMs in that libvirt endpoint, or even power all of them up at once. Many things can go wrong here. For example, the host might not have capacity to have all VMs running at the same time. My expectation was that in MAAS I would see the already existing VMs, but in a state similar to “new”. Somewhat known, but untouched.
I remember seeing this when playing with the vmware chassis, and was glad there was a prefix option. Given that here it’s not only VMs that are taken over, but also storage and networking, I don’t think that approach won’t work, and we should go the warning route at the least, and maybe the “known, but untouched” suggestion, if that’s feasible.
