Solved

Updating a VM via PrismCentral v3 API

  • 27 December 2019
  • 7 replies
  • 4035 views

Badge +1

While attempting to update a VM category via the prism central API, we are getting a 409 response saying:

{
'api_version': '3.1',
'code': 409,
'message_list': [{
'message': 'Edit conflict: please retry change. Entity CAS version mismatch.',
'reason': 'CONCURRENT_REQUESTS_NOT_ALLOWED'
}],
'state': 'ERROR'
}

It seems to be occurring on only one VM as all others seem to update normally. I can clear it by updating the VM through the gui, however once I try and do it via API I get that error.

 

Any thoughts on what could be going on with this VM?

icon

Best answer by etr.eric 15 January 2020, 22:14

Found the solution. You have to make sure that the value is set:

"use_catetories_mapping": True

Oddly enough, this value doesn’t show up when you pull the config of a VM, so you don’t know if it’s ever set or not. It appears to be a hidden value but in order to utilize the categories mapping so that you can have multiple category:values set, you need to make sure that it is set to True.

View original

7 replies

Userlevel 1
Badge +1

@etr.eric Thank you for posting the question. Could you please tell me what are your PE and PC versions? This issue occurs if there is version incompatibility between PE and PC. 

We have had similar issue in the past. We tried upgrading the PC. Please do let me know respective versions.

Badge +1

Both are on 5.11. Since this is just on our test cluster, I was thinking about updating to 5.11.2 anyway but will definitely do it if you think that might help with this.

I’ve honestly had a lot of inconsistency getting the category to stay in place even on the machines that update successfully. It will go through but then when I add another category, it seems like it will drop off. Can you tell me which dictionary is most relevant to the category assignment in the VM metadata? Is it the “categories” field or the “categories_mapping” field? How do they interact?

"metadata":{

"categories_mapping": {
"category_1": [
"category_value"
],
"category_2": [
"cat_value_1",
"cat_value_2"
]
},
"categories": {
"category_1": "category_value",
"category_2": "cat_value_1"
}
}

We’ve also noticed that seemingly only one k,v pair of a given category can live in the categories dictionary, however the mapping dict can hold multiple category values. Is there a limit to how many values can be assigned to a VM?

Badge +1

I don’t know if this is on anyone’s radar still, but I am still having trouble with these fields. In fact, it seems that any update to the categories of a VM via the PrismCentral API isn’t working correctly. It seems to work when adding it initially, however once I try to add an additional category:value, the task goes to a state of PENDING and then doesn’t actually finish despite returning a successful code. Do I need to open a support case? 

Are there any known issues updating category/project fields of a VM via the v3 prism central API?

Badge +1

Found the solution. You have to make sure that the value is set:

"use_catetories_mapping": True

Oddly enough, this value doesn’t show up when you pull the config of a VM, so you don’t know if it’s ever set or not. It appears to be a hidden value but in order to utilize the categories mapping so that you can have multiple category:values set, you need to make sure that it is set to True.

Badge +1

@Sneha Patekar I mistakenly marked this as answered and it is not.

While enabling the “use_category_mapping” flag did fix whether the VM used multiple categories, we are still running into the 409 CONFLICT response when trying to update VMs. It doesn’t appear to be on all VMs. Seems to be when there is a conflict with the spec_version or possibly something with spec_hash. This is still an open issue.

Can you reset this as unanswered?

Badge +1

I believe that the critical point to this is that you have to be aware of the spec_version and if you try and push an update to a VM with it out of sync, you will get a 409 CONFLICT. If you pull the spec_version out entirely, you will get a 422 INVALID. So not only is spec_version required, but it has to match before an update VM API request will go through.

Badge +1

This was marked as answered by mistake. While part of it is understood, there still isn’t any clarity on why a VM will get stuck in the “ERROR” state.

Opened a new topic here: https://next.nutanix.com/api-31/updating-vm-via-prismcentral-v3-api-37435

Reply