MAAS 2.6 breaks Virsh ESXi Powertype

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.

image

1 Like

This was changed in https://bugs.launchpad.net/bugs/1815136

Why do you need the ?no_verify=1 flag?

So I thought I’d bring this up just because it’s what I’m seeing. :joy:
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 :heart_eyes:

2 Likes

MAAS has a VMware power driver. Have you tried using that?

Yeah, it’s for vcenter, i don’t have a vcenter server, only the vsphere hosts themselves

Could you please file a bug report?

1 Like

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.

Do I just comment out this line of code in line 368?

poweraddr = poweraddr + '?command=' + get_path(
        #    '/usr/lib/maas/unverified-ssh')

Once I make changes to the code, was there a command i needed to run to ‘recompile’ the code? Or is it a code fix and MAAS pulls from the latest file