Figuring out why MAAS cannot connect to virsh


Answer: 1

18 hours ago

I'm trying to get MAAS to talk to virsh on localhost to not have to configure a whole extra physical machine to run deployment service juju on. MAAS seems to be able to deploy a virtual machine to this extent and the host it's running on is more than capable of meeting the requirements (seems to be 4GB of RAM, which it has 20 of).

In MAAS, I go to the tab KVM, set the Name as local_kvm, leave Zone, Resource Pool, and Password (optional) as default, and set the Address to either of


In both cases: It's failing with the very unhelpful error message:

Failed talking to pod: Failed to login to virsh console.

Directly running:

virsh -c <address> 

succesfully connects to the local virsh console after accepting/trusting as a host. Of course, thinking that perhaps the MAAS gui doesn't 'force' the SSH connection through if it does not recognize/trust the host, I try again with the MAAS GUI, yet after doing so trying to do so in the GUI again fails with the same error message.

Which just states 'it failed', but doesn't really tell me why. Here's what I'd like to know:

  • What user is this being executed as?
  • What command is MAAS trying to execute?
  • Where can I find a log file containing detailed reasons as to why the qemu/ssh connection failed?
  • Is it possible that this error message is printed regardless of what went wrong, because I haven't configured storage, networks, etc. yet for KVM/libvirt-qemu, apart from removing DHCP from it.

Note that I already installed qemu on the host, running plain virsh on the terminal as root works.

A lot of the instructions online refer to a maas user, yet I do not have this user on the machine. The thing was installed via apt as the root account, and the services appear to run as such, on root. Perhaps it shouldn't, to make things work, but then the question becomes: how do I change it not to do this, while not completely breaking it, as I'd imagine lots of necessary (virtual) files are owned by root that would need to be changed?

Added by: Cassandra Reichel

Answer: 2

24 hours ago

I was running into the same issue. Initially, I had installed the snap, but then after running into permissions issues, I decided to switch to the PPA apt installation, which wasn't straight forward given that the project is working towards doing away with it. The following is what got me to success.

  1. Uninstall the snap if it's installed.
  2. Install the PPA, but don't install latest, instead use a version (just as the guide describes). This will also add the maas user. Version 2.9 worked for me.
  3. Follow these two nearly identical guides, bridging gaps when one or the other falls short: guide and an unofficial guide.
  4. You should now have a working MAAS install with all of the extra configuration that will be required to get this working. Of the two guides, you'll eventually get to this command in one of them where you add the maas user to the libvirt group: sudo usermod -a -G libvirt maas. If you execute that command, then the maas user will have access to libvirt, and will be able to execute virsh commands locally with the connection string set to qemu:///system. This is my setup, (the MAAS server is also the KVM server).
  5. If you prefer to use a different user to manage the VMs in MAAS, then add the user to the libvirt group instead of maas, then follow the other guide on creating an SSH key and copying it over. If you want something more succinct, you can look at this example which is also how you might setup a VM that's been manually created on a non-configured or manual KVM host. This is also how you would configure an alternate host to manage the VMs.

While it seems they are moving away from supporting the PPA, another option all together may be to run MAAS in an lxd container. I'll be heading this route if I ever need to upgrade, and you can find documentation on that here.

Popular Search

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 1 2 3 4 5 6 7 8 9