I’ve just upgraded to 2.6 and noticed that machines with a power configuration of Virsh which are ESXi based guests are now failing to be controlled.
I have a whole bunch of ESXi guests registered in MAAS and have happily been controlling them using Virsh as their power type
If I run below command manually on the MAAS region or rack controllers it returns with no error.
virsh -c esx://root@10.10.100.200/?no_verify=1 list --all
However on the MAAS GUI, all machines with that power type have a validation error saying
Error: Supplying extra parameters to the Virsh address is not supported.
So I thought I’d bring this up just because it’s what I’m seeing.
I’m not really expecting a fix because bringing in ESXi Guests into MAAS is not really a production type scenario.
So the /?no_verify=1 flag? is due to the fact that the ESX machine is using a self signed certificate.
I tried dropping it but it just returns :
Error: Failed to login to virsh console.
Since then I’ve set those machines to manual power types.
I’ve also started playing with KVM pods and composable machines. MAAS 2.6 has made this really nice and easy to setup and get going
I am able to list all the VMs from VMware after I exchanged SSL certs using:
virsh -c list --all
but whenever I try to add a machine through MAAS it keeps replying "failed to detect a valid IP address from ". It seems like MaaS does not translate the hostname to its IP address which is why it does not recognize it as a valid IP.
The easiest workaround is to enable back option ?no_verify=1, but just for esx: protocol. Change is fairly simple, just look at /provisioningserver/drivers/pod/virsh.py, method login() at line 354.
Btw, as optional parameters to virsh were disabled because of the possibility of exploiting “command” parameter (see bug reference in sparkiegeek’s comment above), this is actually not relevant in a esx: protocol use case, as it doesn’t support it and always works via http (https://libvirt.org/drvesx.html). MAybe we could enable this back? There seems to be a valid use case that doesn’t make security any worse.
A quick look at code revealed that possible second fix/workaround is to fix bmc model code in maasserver/models/bmc.py, as it looks like they don’t do a lookup from fqdn to IP and just call a method that needs an IP as a parameter with a FQDN name instead (that 's the error you’re seeing). But this is a change that is more risky than the first workaround, so I didn’t try it.
I have exactly same problem; not with vmware, but hyperv.
before 2.6, with virsh, I can use hyperv://user@server ip/?transport=http to connect, but now, even with latest 2.9 I cannot.
Also, after I setup proper certificate for my windows server, and replace the server ip with full qualified domain name, I got “failed to detect a valid IP address from” error message.
Same as @darmadoo. virsh -c list --all works fine.
So why MAAS cannot resolve FQDN to IP given that the operation system (Ubuntu 20.0.4) can do it without problem?
Thanks @ltrager, this is very likely the root cause. Do we know what the release date is? It is tagged with milestone 2.9.x, but no any date associate with it.
So I just upgraded from 2.7 to 2.9.2 and it seems like “Add hardware” functionality resolves the FQDN but it still is not able to access the VMs Power configuration. I tried to add the VM name and VM UUID (using dominfo <vm_name> and neither works.
I still get the error message “Error:() - No rack controllers can access the BMC of node”
I can still turn up the VMs if I run virsh -c <ESXI_FQDN> start <VM_UUID> and virsh -c <ESXI_FQDN> start <VM_NAME>
