1030.20.ips: The value of memory licensed on the web is not consistent with what we see in phyp

[ChicagoDuan]

After successfully activating the memory, we will see the value of memory licensed on the web is not consistent with what we see in phyp.

Before activating memory:

After activating memory:

What is the meaning of “memory licensed” on the web and does it indicate the amount of memory that has been activated? If so, the value on the web is incorrect.

[ChicagoDuan]

@mzipse Can you give us some help with this issue? Thanks.

[edwin-wang]

I think this is target for Everest (9043) 4 sockets. Correct? @ChicagoDuan

[ChicagoDuan]

I think this is target for Everest (9043) 4 sockets. Correct? @ChicagoDuan

Yes

[neslop]

Trying to get this re-energized. We see the behavior of returning, for example, "2048" as GB in our JSON structure going back to BMC, and yet BMC seems to turn it into "8192" which is 4x the expected value. We have a defect open and are still trying to find an owner in BMC who can comment on this.

[mzipse]

A phyp fix has been identified for this defect. The plan is to drop this fix into FW1050.10 and FW1030.40 service packs.

One other thing to note. I got this from Phillip Scramlin... Another thing that could cause confusion, is the cfcuod -query permmodinfo macro IPS was using will only show what activations amounts were manually applied to a system, it doesn't account for base enabled memory. We have other macros that would show what memory is actually activated (base + licensed).

[mzipse]

We'll keep this open until at least one of those service packs has been delivered.

[mzipse]

I understand from Xujin that you are still seeing this problem. We would like you to share more information on what you are seeing. Here is some information we'd like you to gather.... 1) Screen shot of the GUI 2) Go to https://bmc-host-name/redfish/v1/LicenseService/Licenses/PermMem and post a screen shot 3) From PHYP, please run cfdumpcodmgr and cfcuod -sp

Thanks in advance.

[ChicagoDuan]

Hi @mzipse I can't open this link: https://bmc-host-name/redfish/v1/LicenseService/Licenses/PermMem We can't run "cfdumpcodmgr" command in PHYP.

Here are these screenshots:

[mzipse]

@ChicagoDuan , sorry for not being clear. That link by itself will not work, you need to substitute the "bmc-host-name" in the url with your systems bmc host name. You should then see something like this....

redfish { "@odata.id": "/redfish/v1/LicenseService/Licenses/PermMem", "@odata.type": "#License.v1_0_0.License", "AuthorizationScope": "Capacity", "ExpirationDate": "1970-01-01T00:00:00+00:00", "Id": "PermMem", "LicenseType": "Production", "MaxAuthorizedDevices": 1024, "Name": "Permanent Memory Licenses (GB)", "SerialNumber": "A212-0040", "Status": { "Health": "OK", "State": "Enabled" } }

[jbremer-ibm]

@ChicagoDuan, I have a an additional data point I would like to collect.

Could you run "cfcuod -query permmodinfo" from the PHYP terminal?

Additionally, you may need to try and run "cfdumpcodmgr" once more from the PHYP terminal. The terminal doesn't like it when you backspace due to a mistype, could be the reason it was not working.

[ChicagoDuan]

@jbremer-ibm
We have confirmed again that we did not use backspace when spelling “cfdumpcodmgr”. We still unable to run the "cfdumpcodmgr". Here is the screenshot：

[jbremer-ibm]

@ChicagoDuan Looks like everything is working as expected here. Based on 'cfcuod -query permmodinfo', the output states you have 4096 GB licensed, which is what is listed on the BMC.

[ChicagoDuan]

@jbremer-ibm @mzipse Thanks！We tested using 1030.40 and found that the number of licensed memory displayed on the ASMI is the actual amount of memory enabled by the machine, not the amount of memory manually activated by PHYP. For example:

1. The machine actually has 2T of memory installed, and we manually activates 4T of memory in PHYP. The ASMI displays 2T.
2. The machine actually has 2T of memory installed, and we manually activates 1T of memory in PHYP. The ASMI displays 1T.

Is this as expected? If so, I think this issue can be closed. Thanks

[jbremer-ibm]

@ChicagoDuan Appreciate the clear description. That is the expected behavior. I agree that this issue can now be closed.

[mzipse]

Excellent! Closing.