Issue with vmm v4.2 API (updateVmById)

Note: I’ve also tried with raw API requests from a REST client, with the same results.

Does the VM have any storage policies or attached volume groups? 
I have seem a similar error when I was trying to update the VM Configuration that had a volume group attached to it.

I would also encourage you to raise a support case, if this in indeed a bug with the API.

Additionally, if you have access to the PCVM or CVM, you use use ecli to see if the task is being registered.

Task troubleshooting:

1. List all task ecli task.list
2. Inspect a specific task (look for the Acropolis component) ecli task.get <uuid»

The output of the ecli task.get should hopefully give you a better justification as to why the task is failing (providing the task is being registered to begin with) 

Thanks for your reply. No, the VM has nothing special about it like that. The updateVmById command is accepted (the PUT call), and a task created, but that task fails with the error.

I've opened a support case, but they only suggested I "wait a bit after the VM is created" before trying to update it. I can run the modification hours/days after it's created and it still fails. 

Okay yeah go back to support and tell them that did not work. You have performed a decent amount of troubleshooting already, so be firm we support and escalate the case if you feel like support is not listening.

By any chance did you have a chance to look at the ecli task.get output?

The only extra bit of detail in the ecli output is this:
 

  "debug_info": "VM Invalid Argument Error: 30102\n  :createTime attribute is missing in the VmUpdate Arg.",

The task does not get past the Prism Central, it seems.

So back to square 1. Since it’s not getting past the PC, you will need support to help trace the request from the IKAT proxy downstream to find where it’s getting rejected. 

When the body is a Vm instance, the SDK seems to be serializing it via vm.toJson(), which strips the read-only fields createTime/updateTime from the request body.
The v4.2 VM-update backend validates createTime as required and rejects the request, which is why the task fails with VMM-30102 createTime EMPTY.

As a quick fix to try - create the update body as a plain object (which preserves createTime and avoids the models toJson() stripping).

const vmResponse = await vmApi.getVmById(vmUuid);
const vmData = vmResponse.data.data;
const eTag = vmData.$reserved?.ETag;
const payload = { ...vmData, numSockets: 2, memorySizeBytes: 2 * 1024 * 1024 * 1024 };
await vmApi.updateVmById(vmUuid, payload, { 'If-Match': eTag });

const vmResponse = await vmApi.getVmById(vmUuid);
const vmData = vmResponse.data.data;
const eTag = vmData.$reserved?.ETag;
const payload = { ...vmData, numSockets: 2, memorySizeBytes: 2 * 1024 * 1024 * 1024 };
await vmApi.updateVmById(vmUuid, payload, { 'If-Match': eTag });

Bingo - that worked! Many thanks!

      // Fetch current VM state and ETag
      const vmResponseForResource = await apis.vmApi.getVmById(vmUuid);
      const vmDataForResource = vmResponseForResource.data.data;
      const vmETagForResource = vmDataForResource.$reserved?.ETag;

      // Create new payload with spread operator and updated values (forum user suggestion)
      const payload = { 
        ...vmDataForResource, 
        numSockets: finalSockets,
        memorySizeBytes: finalRamGib * 1024 * 1024 * 1024
      };
      debug_main("Updated sockets to %d and memory to %d GiB", finalSockets, finalRamGib);

      if (debug_main.enabled) {
        debug_main("Payload for resource adjustment: %s", JSON.stringify(payload, null, 2));
      }

      // Send the update
      const resourceUpdateResponse = await apis.vmApi.updateVmById(vmUuid, payload, { 'If-Match': vmETagForResource });