No cores and memory accepted when creating VM on LXD host

Trying to create VM in an LXD host. Even if there are a lot of memory and cores, it will not accept it.

The host NIC is configured in bridge with OVS
MAAS version

maas 3.3.2-13177-g.a73a6e2bd 27109 3.3/stable canonical✓ -

LXD version

lxd 5.12-c63881f 24643 5.12/stable canonical✓ -

OVS version: “2.17.3”

   {
    "pool": {
        "name": "default",
        "description": "Default pool",
        "id": 0,
        "resource_uri": "/MAAS/api/2.0/resourcepool/0/"
    },
    "memory_over_commit_ratio": 1.0,
    "name": "NODO12",
    "storage_pools": [
        {
            "id": "default",
            "name": "default",
            "type": "dir",
            "path": "/var/snap/lxd/common/lxd/storage-pools/default",
            "total": 117473161216,
            "used": 0,
            "available": 117473161216,
            "default": true
        }
    ],
    "id": 68,
    "default_macvlan_mode": "",
    "capabilities": [
        "composable",
        "dynamic_local_storage",
        "over_commit",
        "storage_pools"
    ],
    "cpu_over_commit_ratio": 1.0,
    "available": {
        "cores": 0,
        "memory": 0,
        "local_storage": 117473161216
    },
    "version": "5.12",
    "host": {
        "system_id": "xpd3tt",
        "__incomplete__": true
    },
    "total": {
        "cores": 0,
        "memory": 0,
        "local_storage": 117473161216
    },
    "used": {
        "cores": 0,
        "memory": 0,
        "local_storage": 0
    },
    "tags": [
        "pod-console-logging"
    ],
    "architectures": [
        "amd64/generic"
    ],
    "zone": {
        "name": "default",
        "description": "",
        "id": 1,
        "resource_uri": "/MAAS/api/2.0/zones/default/"
    },
    "type": "lxd",
    "resource_uri": "/MAAS/api/2.0/vm-hosts/68/"
}

Also inside MAAS Postgres DB cores,memory are set to zero. I tried to manually update the row in the DB but it didn’t work.

I follow the doc with recommends doing lxd init from the command line

So to state the blindingly obvious, MAAS sees your LXD host (“NODO12”) but is not detecting any available resources, specifically cores and memory. I run into this from time-to-time, also, and it’s really infuriating. Here’s my superstitious litany of voo-doo incantations:

  1. Verify the LXD host setup: Ensure that your LXD host is correctly set up and that the LXD service is running properly. You can verify this by running lxc info on the LXD host to check the resources available to LXD. If the resources are correctly displayed there, maybe it’s MAAS.
  2. Check the LXD logs: Inspect the LXD log files (I think they’re at /var/log/lxd/lxd.log or /var/snap/lxd/common/lxd/logs/lxd.log if installed as a snap, but don’t quote me). Look for any error messages related to resource allocation or initialization.
  3. See if the LXD Host Configuration is correct in MAAS: In MAAS, navigate to the LXD host configuration page and check whether the resources are visible there. If not, try removing and re-adding the LXD host in MAAS. This does it for me about 70% of the time.
  4. MAAS logs: Check the MAAS logs for any errors related to the LXD host. The MAAS logs are usually located in /var/log/maas/ (or the snap equivalent, /var/snap/maas/common/log. The rackd.log or regiond.log might have information related to the LXD host.
  5. Update LXD and MAAS: Ensure that both LXD and MAAS are up-to-date. You’re running MAAS 3.3.2 and LXD 5.12, and while these are not old versions, ensuring both are at the latest version can help rule out any version-specific bugs. This is a long shot, but worth a try.
  6. Re-run lxd init: If all else fails, you might want to try re-running lxd init on the LXD host, following the official guidelines. This will allow you to reconfigure your LXD host. Please note that this could disrupt any existing containers on the host.
  7. Re-install LXD, followed by MAAS: When I really get superstitious, I’ll just do a reinstall. Works in about 20% of these cases, though it’s really annoying to have to do this again.

Remember, if you have any running VMs, back up your data before making any significant changes.

Thanks @billwear I’m exploring your suggestions.
Just to be clear in this guide:
https://maas.io/docs/how-to-set-up-lxd#heading--lxd-init Should I arrive there that I have already configured the OVs bridge from the MAAS web interface?

OVsBridgeC

I would recommend setting up the bridge beforehand and getting acquainted with its configuration (i.e., make sure it works) before initializing LXD. In my experience, it’s generally easier to do it upfront, although there may be alternative approaches. Keep in mind that network configurations can always be adjusted, but having the bridge ready from the start has personally made the process smoother for me.

Thank you @billwear unfortunately, I have tried all your voo-doo incantations but have not figured it out. I’ve run out of ideas

1 Like

I’m sorry to hear you’re still having issues getting the LXD host detected properly in MAAS. Here are a few more things you could try:

  • Check if the LXD host has any AppArmor or other restrictions that could block access to resources or the API. Try disabling AppArmor temporarily as a test.
  • Look at the logs on the LXD host while trying to add it in MAAS. See if any errors crop up on the host side.
  • Try a simpler storage backend like ZFS instead of OVS/bridge to isolate the networking portion.
  • Verify the MAAS server can access the LXD host API and websocket on the configured port. Check network/firewall rules.
  • Rebuild the LXD host completely from scratch and re-import to MAAS when done.
  • File a bug on Launchpad with logs from both MAAS and the LXD host so the developers can review in detail.

Let me know if any of those provide additional ideas to pursue. Getting LXD hosts working in MAAS can require some perseverance but I’m confident we’ll get to the bottom of it eventually. Feel free to provide any other details that may help.