[2.x] MAAS does not detect RAM in newly commissioned VMWARE VM's

[Mischa Schouten]

This bug is very similar to a few that date back to 2012.

Basically the new VM's register and can be commissioned just fine, only when the ready state is reached the total RAM is valued at '0'.
CPU's and storage are detected just fine.

The major downside of this is that this halts my experimentation with openstack since Juju can't find any ready machines with a memory requirement of 3584 Megs (ServerError: 409 CONFLICT (No available machine matches constraints: mem=3584.0 zone=default))

I would be very happy with a workaround that will allow me to go forward with the openstack installation and at the same time help me understand the data structure of MAAS commissioned machines (I'm still looking at how to rename them)

dpkg -l '*maas*'|cat
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===============================-==============================-============-=================================================
ii maas 2.1.3+bzr5573-0ubuntu1~16.04.1 all "Metal as a Service" is a physical cloud and IPAM
ii maas-cli 2.1.3+bzr5573-0ubuntu1~16.04.1 all MAAS client and command-line interface
un maas-cluster-controller <none> <none> (no description available)
ii maas-common 2.1.3+bzr5573-0ubuntu1~16.04.1 all MAAS server common files
ii maas-dhcp 2.1.3+bzr5573-0ubuntu1~16.04.1 all MAAS DHCP server
ii maas-dns 2.1.3+bzr5573-0ubuntu1~16.04.1 all MAAS DNS server
ii maas-proxy 2.1.3+bzr5573-0ubuntu1~16.04.1 all MAAS Caching Proxy
ii maas-rack-controller 2.1.3+bzr5573-0ubuntu1~16.04.1 all Rack Controller for MAAS
ii maas-region-api 2.1.3+bzr5573-0ubuntu1~16.04.1 all Region controller API service for MAAS
ii maas-region-controller 2.1.3+bzr5573-0ubuntu1~16.04.1 all Region Controller for MAAS
un maas-region-controller-min <none> <none> (no description available)
un python-django-maas <none> <none> (no description available)
un python-maas-client <none> <none> (no description available)
un python-maas-provisioningserver <none> <none> (no description available)
ii python3-django-maas 2.1.3+bzr5573-0ubuntu1~16.04.1 all MAAS server Django web framework (Python 3)
ii python3-maas-client 2.1.3+bzr5573-0ubuntu1~16.04.1 all MAAS python API client (Python 3)
ii python3-maas-provisioningserver 2.1.3+bzr5573-0ubuntu1~16.04.1 all MAAS server provisioning libraries (Python 3)

[Mischa Schouten (mlschouten)]

>In addition:
>lshw output excerpt from hardware node RAM that IS correctly detected by MAAS
>
    *-memory
          description: System Memory
          physical id: 1000
          slot: System board or motherboard
          size: 128GiB
        *-bank:0
             description: DIMM Synchronous 2133 MHz (0.5 ns)
             product: M393A2G40DB0-CPB
             vendor: 00CE04B300CE
             physical id: 0
             serial: 40AD3081
             slot: A1
             size: 16GiB
             width: 64 bits
             clock: 2133MHz (0.5ns)
        *-bank:1
             description: DIMM Synchronous 2133 MHz (0.5 ns)
             product: M393A2G40DB0-CPB
             vendor: 00CE04B300CE
             physical id: 1
             serial: 40AD308A
             slot: A2
             size: 16GiB
             width: 64 bits
             clock: 2133MHz (0.5ns)
        *-bank:2
             description: DIMM Synchronous 2133 MHz (0.5 ns)
             product: M393A2G40DB0-CPB
             vendor: 00CE04B300CE
             physical id: 2
             serial: 40AD30A2
             slot: A3
             size: 16GiB
             width: 64 bits
             clock: 2133MHz (0.5ns)
        *-bank:3
             description: DIMM Synchronous 2133 MHz (0.5 ns)
             product: M393A2G40DB0-CPB
             vendor: 00CE04B300CE
             physical id: 3
             serial: 40AD30A1
             slot: A4
             size: 16GiB
             width: 64 bits
             clock: 2133MHz (0.5ns)

>
>and lshw output excerpt from VMWare ESX 6.5 node RAM that is not correctly detected by MAAS.
>
     *-memory:0
          description: System Memory
          physical id: 28
          slot: System board or motherboard
          capacity: 1GiB
     *-memory:1 UNCLAIMED
          physical id: 1
        *-bank UNCLAIMED
             description: DIMM DRAM EDO
             physical id: 0
             slot: RAM slot #0
             size: 8GiB
             width: 32 bits
     *-memory:2 UNCLAIMED
          physical id: 2
        *-bank UNCLAIMED
             description: DIMM DRAM [empty]
             physical id: 0
             slot: RAM slot #1
     *-memory:3 UNCLAIMED
          physical id: 3
        *-bank UNCLAIMED
             description: DIMM DRAM [empty]
             physical id: 0
             slot: RAM slot #2

[Mischa Schouten (mlschouten)]

Happy workaround :
using credentials found in /etc/maas/regiond.conf

#psql -U maas -h localhost maasdb
UPDATE maasserver_node SET memory = '<NUMBEROFBYTES>' WHERE hostname = '<NAMEOFCOMMISIONEDHOST>' \g

This seems to satisfy Juju at least.

[Andres Rodriguez (andreserl)]

Hi Mischa,

CAn you please attach the lshw output that MAAS stores?

Also, can you confirm whether ytou have commissioned the machine with Trusty or have you commissioned it with Xenial?

[ybaumy (christian-setzer)]

same error here with

maas 2.2.0+bzr6054-0ubuntu1~16.04.1
pyvmomi 6.5.0.2017.5-1
vcenter 6.5

[Fairbanks. (fairbanks)]

I have the same issue with the latest MAAS 2.3.3 version and using VMWare 6.7.

[Fairbanks. (fairbanks)]

I want to note that the fix that mlschouten posted ( https://bugs.launchpad.net/maas/+bug/1666521/comments/3 ) does work, but you need to use MiB's instead of bytes!
Bytes result in a to large integer for the database, and all is stored using MiB's.

[Adam Collard (adam-collard)]

This bug has not seen any activity in the last 6 months, so it is being automatically closed.

If you are still experiencing this issue, please feel free to re-open.

MAAS Team

[ignazio (cassano)]

I confirm the bug is present on 2.6.2-7841 and I had to modify the postgres table mentioned above.
Ignazio