5 Essential Tips for Maximizing Your Experience at Nutanix .NEXT for Bloggers
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
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.
@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?
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.
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?
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 V
I received some assistance from our Account team and was able to get this to work by using the network name as the “SourceId”.
Thank you for the reply @Mutahir however, I get the same result when I try this. Really, other than the ordering and the addition of the VM id to the VM reference dictionary, this isn’t any different from what we were already trying. Just to clarify, is the “SourceID” supposed to be the vmware moRef ID of the source portgroup?
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
