{"id":549,"date":"2026-09-09T00:43:39","date_gmt":"2026-09-08T22:43:39","guid":{"rendered":"https:\/\/nutanix.ma\/?p=549"},"modified":"2026-09-09T00:47:02","modified_gmt":"2026-09-08T22:47:02","slug":"increasing-nutanix-controller-vm-memory-size","status":"publish","type":"post","link":"https:\/\/nutanix.ma\/index.php\/2026\/09\/09\/increasing-nutanix-controller-vm-memory-size\/","title":{"rendered":"Increasing the Nutanix Controller VM Memory Size"},"content":{"rendered":"\n

Controller VM memory is one of those settings that gets chosen once, at deployment, and then quietly stops being right. The cluster grows, you enable a few more services, VM count creeps up \u2014 and one morning Prism raises a critical alert telling you RAM usage on a CVM is high. The good news is that increasing CVM memory is a supported, non-disruptive operation you can do yourself from Prism Element in about five minutes.<\/p>\n\n

This walkthrough covers the whole thing: what the alert looks like, the constraints worth knowing before you start, the steps, and the before\/after on a real four-node cluster I recently resized from 24 GB to 36 GB per CVM.<\/p>\n\n

The alert<\/h2>\n

It shows up as a critical alert with a fairly blunt summary \u2014 main memory usage in the CVM is high, with the free memory reported in KB:<\/p>\n\n

\"Nutanix
The alert detail \u2014 RAM usage high on the Controller VM.<\/figcaption><\/figure>\n\n

On the cluster in question this was one of three critical alerts on the home dashboard:<\/p>\n\n

\"Prism
Before \u2014 three critical alerts, including RAM usage high on a CVM.<\/figcaption><\/figure>\n\n

Before changing anything, confirm the picture from the VM table. Go to the VM<\/strong> page, switch to Table<\/strong>, tick Include Controller VMs<\/strong> and filter on cvm<\/code>. That gives you every CVM with its memory capacity and current usage side by side:<\/p>\n\n

\"Prism
Four CVMs at 24 GiB, running between 83% and 92% memory usage.<\/figcaption><\/figure>\n\n

All four CVMs sitting in the mid-to-high 80s, with one at 92.4%, is not a one-off spike \u2014 that’s a cluster that has outgrown its original sizing. This is the case where adding memory is the right answer rather than a workaround.<\/p>\n\n

Before you start<\/h2>\n

Three things worth understanding before you touch the setting.<\/p>\n\n

Resizing requires a CVM restart, but it is not disruptive.<\/strong> AOS restarts one CVM at a time and waits for it to come back before moving to the next, so the cluster keeps serving I\/O throughout and there’s no production impact. You don’t need a maintenance window for this, though I’d still avoid running it during a backup window or alongside other maintenance.<\/p>\n\n

64 GB is the ceiling through Prism Element.<\/strong> You can allocate up to 64 GB per CVM from the web console. If you need to go beyond that, it’s a Nutanix Support conversation rather than a self-service change.<\/p>\n\n

The setting only ever increases memory.<\/strong> AOS applies your target to any CVM currently below it and leaves the rest alone. So if a CVM is at 20 GB and you select 28 GB, it goes up to 28 GB. But if a CVM is already at 48 GB and you select 28 GB, it stays at 48 GB \u2014 the value is a floor, not an absolute. You cannot shrink a CVM this way.<\/p>\n\n

And the usual precondition: run a full NCC health check first<\/strong> and make sure nothing else is wrong with the cluster. Restarting CVMs one after another is safe on a healthy cluster; it is not something to start on a cluster that already has a node down or a rebuild in progress.<\/p>\n\n

Step 1 \u2014 Open Configure CVM<\/h2>\n

Log in to Prism Element, then from the dropdown menu to the left of the main menu select Settings<\/strong>. In the General<\/strong> section of the left navigation pane, click Configure CVM<\/strong>:<\/p>\n\n

\"Prism
Settings > General > Configure CVM.<\/figcaption><\/figure>\n\n

Step 2 \u2014 Select the target memory size<\/h2>\n

The Configure CVM page shows a Target CVM Memory Allocation<\/strong> dropdown and a table listing every node, its IP, its model and its current CVM memory. Pick your target size \u2014 36 GB in this case \u2014 and the table previews what each CVM will end up with:<\/p>\n\n

\"Configure
Target set to 36 GB across all four NX-8035-G7 nodes.<\/figcaption><\/figure>\n\n

Click Apply<\/strong>. Prism asks you to confirm, and it’s worth reading the warning: during the process the Prism service itself may become temporarily unavailable. That’s expected \u2014 Prism runs on the CVMs, so when the CVM hosting it restarts, the console blips. Cluster I\/O is unaffected. Click Yes<\/strong>:<\/p>\n\n

\"Confirmation
The confirmation \u2014 note the warning about Prism being briefly unavailable.<\/figcaption><\/figure>\n\n

Step 3 \u2014 Wait for it to work through the nodes<\/h2>\n

From here it’s hands-off. AOS works through the CVMs one at a time. If the console drops out momentarily, give it a minute and reconnect \u2014 that’s the Prism leader moving, not a failure. When it finishes you get a straightforward confirmation:<\/p>\n\n

\"Configure
Memory update successful on all nodes.<\/figcaption><\/figure>\n\n

Step 4 \u2014 Verify<\/h2>\n

Go back to the VM table and check the CVMs again. Memory capacity should show the new size, and usage should have dropped proportionally:<\/p>\n\n

\"Prism
After \u2014 36 GiB per CVM, usage down to between 32% and 60%.<\/figcaption><\/figure>\n\n

The change on this cluster:<\/p>\n\n

    \n
  • CVM memory went from 24 GiB to 36 GiB<\/strong> on all four nodes.<\/li>\n
  • Memory usage dropped from 83\u201392% to 32\u201360%<\/strong>.<\/li>\n
  • The highest CVM went from 92.4% to 60.14%<\/strong>.<\/li>\n<\/ul>\n\n

    And the home dashboard tells the same story \u2014 the RAM usage alert is gone and cluster health is back to a normal state:<\/p>\n\n

    \"Prism
    After \u2014 no critical alerts, data resiliency OK.<\/figcaption><\/figure>\n","protected":false},"excerpt":{"rendered":"

    Controller VM memory is one of those settings that gets chosen once, at deployment, and then quietly stops being right. The cluster grows, you enable a few more services, VM count creeps up \u2014 and one morning Prism raises a critical alert telling you RAM usage on a CVM is high. The good news is […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-549","post","type-post","status-publish","format-standard","hentry","category-nutanix"],"_links":{"self":[{"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/posts\/549","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/comments?post=549"}],"version-history":[{"count":2,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/posts\/549\/revisions"}],"predecessor-version":[{"id":551,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/posts\/549\/revisions\/551"}],"wp:attachment":[{"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/media?parent=549"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/categories?post=549"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/tags?post=549"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}