Nutanix Ansible Collection v2.5.0: v4 API Coverage, Proxy Support, and Karbon's Slow Fade

What This Collection Actually Automates

The nutanix.ncp collection is the official Ansible interface for Nutanix Cloud Platform (NCP), which includes Prism Central, Prism Element, and related services. It solves the problem of managing Nutanix infrastructure without clicking through Prism's web UI or writing raw API calls. The target user is an operations or platform engineer who already uses Ansible for other infrastructure and wants VMs, storage, networking, security policies, and cluster profiles defined as code. The collection covers a broad surface: VMM (VMs, hosts, inventory), networking (virtual switches, subnets, network functions), Flow management (entity groups, security policy rules), IAM, cluster management, and licensing. The v2.5.0 release notes emphasize that it is built on v4 APIs and SDKs, which is a shift from older v2/v3 endpoints. That matters because Nutanix has been moving its platform to v4, and modules built on older APIs may stop working or lose features. The collection's stated design goals are simplicity and ease of development, but as with most official vendor collections, the real value is that it tracks the vendor's API changes, so you do not have to rewrite your playbooks when Nutanix deprecates an endpoint.

How v4 Modules Talk to Prism Central

The collection wraps Nutanix's v4 Python SDKs. Each module, such as ntnx_vms_v2 or ntnx_virtual_switches_v2, calls the corresponding v4 API endpoint on Prism Central. The release notes mention a dedicated BaseModulev4 class introduced in v2.5.0 to avoid unnecessary flags for v4-only parameters. That is an internal refactor, but it tells you the collection has a clear separation between v4 and older module paths. Authentication uses local, LDAP, or, new in v2.5.0, Service Account API keys sent via the X-Ntnx-Api-Key header. That header is a concrete detail: if you have a service account, you can now authenticate without storing a password in your playbook. Proxy support is also new for all v4 modules, via module parameters or environment variables, with authentication and precedence control. The release notes do not specify the exact parameter names, but the pattern is standard for Ansible modules, likely something like proxy_url and proxy_username. The read_timeout parameter is a notable fix: all v4 modules now accept a configurable read timeout to avoid failures when Prism Central responds slowly. That is a practical addition, because Prism Central can be slow under load, and the default SDK timeout might be too aggressive. The data flow is straightforward: your playbook passes parameters to the module, the module constructs a v4 SDK client, authenticates, and issues the API call. The module returns results as Ansible facts, which you can register and use in later tasks.

Getting It Running: Commands and Requirements

Installation is standard for an Ansible collection. The README says you need ansible-core 2.16.0 or newer. After installing the collection, you must install the Python dependencies from its requirements.txt. The README gives the exact command: pip install -r ~/.ansible/collections/ansible_collections/nutanix/ncp/requirements.txt. That path assumes you installed the collection to the default user location. If you use a different collections path, adjust accordingly. The dependencies include the Nutanix v4 SDKs and other libraries, though the README does not list them individually. Once dependencies are in place, you can call modules by their fully qualified name, such as nutanix.ncp.ntnx_vms_v2. The collection also includes inventory plugins, like ntnx_prism_vm_inventory, which you can use to dynamically populate your Ansible inventory from Prism. The v2.5.0 release fixed a NoneType crash in inventory plugins when VM fields are explicitly None, so that path is more stable. There is no mention of a dedicated CLI or wrapper; you use it as a normal Ansible collection. The README points to a Nutanix developer blog for getting started, but the core steps are: install the collection, install requirements, and write a playbook with the module parameters.

What v2.5.0 Adds: New Modules and Fixes

The v2.5.0 release notes list several new resource types. Networking gains network functions (create, update, delete) and virtual switches with full CRUD, migration from an existing bridge, list, and get. Flow Management adds entity groups for microsegmentation and the ability to list security policy rules by policy ExtID. IAM gets list and get operations for IAM entities. The security rules module (ntnx_security_rules_v2) gains global scope, specific intratier rules, and subnet/VPC references. These are meaningful additions for teams that manage microsegmentation or network segmentation through code. The release also includes bug fixes, such as removing unnecessary required fields for state: present in ntnx_subnets_v2, and adding missing total_available_results in ntnx_password_managers_info_v2. The v2.4.0 release added key management servers, STIG controls, SSL certificates, cluster profiles, storage policies, EULA management, and new inventory modules. That shows a steady expansion of coverage. However, the release notes are promotional in tone, calling the update 'powerful' and telling you to 'upgrade now.' Ignore that. The concrete list of features is what matters, and it is substantial.

Karbon Deprecation: A Clear Sign of Lifecycle Management

One of the most important items in v2.5.0 is the deprecation notice for Karbon modules. The release notes state that Karbon is not supported on Prism Central 7.3 and later. That is a direct warning: if you use the collection to manage Kubernetes clusters via Karbon, you need to plan a migration. The deprecation message is a signal that Nutanix is moving away from Karbon as a product, and the collection is following suit. For users, this means two things. First, do not build new automation on Karbon modules. Second, if you have existing playbooks that use them, they will break or become unsupported when you upgrade Prism Central. The collection does not provide a replacement module for Karbon in the release notes, so you will need to find another way to manage Kubernetes, perhaps through direct API calls or a different tool. This is a concrete limitation that is easy to miss if you only read the 'new features' section. It also shows that the collection is actively tracking the platform's lifecycle, which is good, but it means you must read the deprecation notes carefully before upgrading.

Where It Falls Short: Timeouts, Permissions, and Documentation Gaps

The collection has several limitations that are visible from the release notes. First, the read_timeout parameter is a fix, but its existence implies that the default timeout was causing failures. You will need to tune it for your environment, and the documentation does not give a recommended value. Second, the release notes mention documenting required permissions for the Ansible service account across all modules. That is a step forward, but it also means that prior to v2.5.0, you had to guess or reverse-engineer the permissions. If you are upgrading from an older version, your service account may not have the correct permissions for new modules. Third, the collection is Python-heavy; you must install the SDK dependencies into the same Python environment as ansible-core. This can be a source of friction in environments where Ansible runs in a container or a separate virtualenv. Fourth, the README is thin on examples. It points to a blog post for getting started, but the repository itself does not include a comprehensive set of playbook examples. That means you will likely need to read the module documentation, which is not included in the README, to understand parameter structures. Finally, the collection is GPL-3.0 licensed, which is fine for most internal use, but if you build a commercial product that embeds these modules, you need to be aware of the copyleft implications. That is not legal advice, just a caution to review the license if you distribute code that includes this collection.

Alternatives: The Raw v4 API and the Nutanix SDK

The main alternative to this collection is to use the Nutanix v4 Python SDK directly in your own automation scripts. The collection is built on that SDK, so you are not gaining any API access that you could not get yourself. The difference is in abstraction. With the collection, you get Ansible's idempotency, playbook structure, and inventory integration. With the SDK, you write Python code that handles authentication, retries, and error handling yourself. That is more work, but it gives you full control and avoids the collection's release cadence. If you are already using Ansible, the collection is the natural choice. If you are not, or if you need complex logic that does not fit a module's parameters, the SDK is a better fit. Another alternative is to use Terraform's Nutanix provider, though that is not mentioned in the repository. Terraform takes a declarative approach and is better for infrastructure provisioning, while Ansible is better for configuration and ongoing changes. The collection does not compete with Terraform directly; it competes with writing your own API calls. The trade-off is clear: the collection saves you time but locks you into the module's parameter schema and the collection's release schedule.

Maintenance and Upgrade Cost

The collection has a regular release cadence: v2.3.0 in October 2025, v2.4.0 in January 2026, and v2.5.0 in April 2026. That is roughly quarterly, which means you should plan to upgrade at least that often to stay current with v4 API changes. Each upgrade may introduce new modules, but it may also add deprecations, as seen with Karbon. The upgrade cost is moderate: you need to install the new collection version and update the Python dependencies, since requirements.txt may change. The release notes do not mention a migration guide, so you may need to read the changelog for breaking changes. The collection is not archived and is actively maintained, which is a positive sign. The license is GPL-3.0, so if you redistribute the collection or modify it, you must share your changes under the same license. For internal use, that is rarely an issue. The documentation gap is a real cost: the README is minimal, and the release notes are the main source of information. You will likely spend time reading module documentation on the Ansible Galaxy page or in the repository's docs folder, which is not linked in the README.

Editorial conclusion

Adopt nutanix.ncp v2.5.0 if you manage Nutanix Cloud Platform through Ansible and need current v4 API coverage, especially for networking, Flow, IAM, or virtual switches. Skip it if you rely on Karbon modules, since they are deprecated and unsupported on Prism Central 7.3 and later. Before upgrading, verify your ansible-core is at least 2.16.0, install the collection's requirements.txt into your Python environment, and test one v4 module with the new read_timeout and proxy parameters against a slow or proxied Prism Central. Also confirm your service account has the permissions documented for each module, as the release notes now list required permissions per module.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes