Hardware Reusability & Repurposing - Part 2
A deeper dive into Cisco's hardware reusability feature with use cases and scenarios to think about when evaluating the overall solution with Nutanix.

I gave some context around how we got to dedicated appliances and some high-level information on how Cisco is breaking the model with Nutanix by leveraging the Cisco UCS stateless architecture in Part 1. In this post, I'll dig deeper into some use cases customers should consider before making investments in a hardware architecture.
A quick reminder that Cisco allows customers to use and reuse their UCS hardware however they need to. This includes taking existing UCS hardware and if needed, retrofitting it with approved parts from the HCL and installing Nutanix. Conversely, customers can purchase new Cisco UCS HCI bundles and reuse that hardware for non-Nutanix related workloads elsewhere in the datacenter ... all while being fully supported by both Cisco and Nutanix.
A Migration to Nutanix
Surprise! Yes, this is still very much a conversation. It either takes the form of wanting to move completely off Broadcom or, especially in large organizations, adopt a dual-vendor strategy at the hypervisor layer. Regardless of the direction, customers often times do not want to buy new hardware to accomplish this goal. Unfortunately for non-Cisco customers, buying new hardware is most likely the direction.
Cisco supports reusing existing hardware with the following servers and generations:
- Cisco UCS M6
- C-Series C220 and C240
- Cisco UCS M7
- C-Series C220 and C240
- X-Series X210c
- Cisco UCS M8
- C-Series C220, C225, and C240
- X-Series X210c and X215c
The next question around this topic is typically "What do I actually have to do with the hardware?" A customer (or partner) needs to follow the HCI with Nutanix specification and data sheets to ensure the hardware in the servers has been qualified. There are a few major components that need to be verified:
- Boot drive media
- Needs to be a pair of RAIDed M.2 drives with a hardware controller
- Front capacity drives for persistent storage
- There's a large list of supported drives a customer can use
- A passthrough controller to match
- For the C240 form factor - the proper riser configuration
We covered this in Part 1 but it is very much worth repeating. Customers who re-use their existing UCS hardware do not lose any functionality. The deployment process for the Nutanix software is still automated through Nutanix Prism Central and the upgrade of firmware and/or software continues to follow the "1-click" procedures through lifecycle manager (LCM).
A Failed Workload Migration
While not nearly as common, this is a scenario customers need to consider. What if a customer has been humming along great and is happy with the Cisco UCS and Nutanix solution with general workloads. A historically bare-metal application comes up for refresh and the customer would like to try to virtualize the application. The customer does their due diligence, does what they believe is appropriate testing but start to run into application issues post migration. Fast forward, all options have been exhausted and it is determined that the application should go back to bare-metal.
With Cisco UCS - this scenario isn't an issue. The customer can easily install a bare-metal operating system on the servers and use them however they please while still keeping full hardware supportability from Cisco. Cisco does not box a customer into purpose-built appliances that can only ever run Nutanix. Furthermore, a core feature of the Nutanix licenses is portability - much like what customers have gotten used to with VMware licenses. In this scenario, this means that the customer can apply the licenses elsewhere in the datacenter for other Nutanix clusters.
The hardware reusability and license portability allows customer the peace of mind that their investment in the solution isn't lost should something happen in the future where the workload isn't a fit.
Scary but Possible
This is a topic that has been brought up in several conversations and is a bit concerning to think about and is somewhat in line with the above scenario. It's a reality we live in and we shouldn't act like an ostrich ... What if something happens to Nutanix tomorrow?

Strategic shifts, such as changes in technology, licensing, leadership, or even corporate acquisitions (sound familiar?), can disrupt a data center strategy. While the flexibility and peace of mind that customers gain from a Cisco UCS deployment can be difficult to quantify, the Cisco UCS solution protects customer investment, ensuring the hardware retains its value even if yet another change is required.
A Budget & Time Conundrum
I've run into this scenario countless times. The compute budget is on a different schedule than the storage budget, which makes HCI hard to adopt. This problem is now amplified for some customers with VMware licensing changes where they want to move to a different hypervisor which often times has a time target of the next renewal.
While there's no silver bullet for this - Cisco operates on a different level offering customers different avenues. We've already discussed the go-to-market options for customers in a previous post, but how can the hardware re-use function be leveraged to help? Let's break this down with an example for a three-tier environment. This example isn't meant to be all inclusive but instead help get the creative juices flowing with the art-of-the-possible.
- The compute refresh is coming up in year 1
- The storage refresh is in year 2
- The VMware licensing refresh is in year 3

In the example above the customer needs to refresh aging B200 Cisco UCS blades but keep their existing storage array. The scenario shows Cisco B200 series servers but it could be any other vendor out there and the storage array is purposefully kept generic - it could be any vendor. That said, stay tuned for more on FlashStack with Nutanix, which was announced at the Nutanix .NEXT conference back in May 2025!
Year 1
Customer has purchased new Cisco C220 M8 servers to refresh their environment and run their workloads on top of. Whether the customer can actually reduce the number of nodes in a cluster is a design decision that needs to be figured out but the concept still applies. To make the future plan much easier to implement - the new servers were purchased with M.2 RAIDed boot drives and the appropriate storage controller - we'll get to why in Year 2.
From eight nodes down to 6 nodes connected to the same storage array. Depending on how the customer has set this up, they'll either have the ability to perform a live vMotion migration (Enhanced vMotion Capability - EVC is key for this) or they create a new cluster and perform a cold VM migration to take advantage of the new CPU chipsets.
Year 2
In year 2 is when things get interesting. The storage array is up for refresh. So what does a customer need to do here? Purchase drives to put in the C220 servers for persistent storage to gain the ability to install Nutanix. There's a direct tie back to the initial purchase of the servers in Year 1 here (mentioned above). Because the customer planned ahead, there's no need to physically open each server to insert the M.2 drives and storage controllers. The only thing a customer needs to do is physically insert the drives in the front of the servers.
There's an expansion that happened at the same time in this scenario where the customer expanded the cluster with 2 additional nodes. This allows the flexibility to install a Nutanix 3 node cluster in parallel and play the shell game for workload migration. There's also an assumption that was made with this scenario that the customer would change over to the Nutanix AHV hypervisor as part of the migration. If this is not the case, it is still very much possible but would require yet another migration to be performed.
- A customer removes a node from the existing cluster - they should, at a minimum, be set up with N+1 allowing this functionality
- With the additinal 2 servers, create a new 3-node Nutanix AHV cluster.
This should look something along the lines of this:
(old vSphere cluster -> new Nutanix cluster)
- 6 nodes -> no cluster
- 5 nodes -> 3 nodes
- The migration begins using Nutanix Move and the customer expands the cluster using Foundation Central as the nodes free up in resources
- 4 nodes -> 4 nodes
- 3 nodes -> 5 nodes
- Final migrations
- no more ESXi cluster -> 8 node Nutanix AHV cluster
Year 3
By year 3, a customer should be fully migrated to Nutanix AHV and have fully refreshed their environment. Now trust me when I say "I know" - if I were talking to you live there would be no less than <insert an amount here> objections around this migration plan. There are not enough characters allowed on the internet to dig into each of the different scenarios or constraints that customers have, but this was meant to make you think about the possibilities and flexibility that is offered by using Cisco UCS as the x86 server platform.
The flexibility that the Cisco UCS platform brings to the Nutanix solution is unmatched when Cisco brings its stateless computing core feature to the table. Remember that utilizing this features is not only supported by both organizations, Cisco and Nutanix, but the customer doesn't have to make any concessions with potential functionality loss. Nothing changes to the Nutanix installation or upgrade processes - everything works as if it was purchased as a purpose-built appliance.
If you've followed Nutanix long enough - you may recognize the No SAN image. Maybe I'll start a new trend.
