10.

2024

Design Document
Workload Migration
Workload Migration: Design Document

© Copyright 2024 Nutanix, Inc.

Nutanix, Inc.,
1740 Technology Drive, Suite 150
San Jose, CA 95110
All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws.
Nutanix is a trademark of Nutanix, Inc. in the United States and other jurisdictions. All other marks and names
mentioned herein are trademarks of their respective companies.

Contents
1 Introduction...........................................................................................................................................................................4
1.1 Document Purpose........................................................................................................................................................................................4
1.2 Audience................................................................................................................................................................................................................4
1.3 Software Versions............................................................................................................................................................................................4
2 Requirements, Constraints, Assumptions, and Risks................................................................................6
2.1 Requirements.....................................................................................................................................................................................................6
2.2 Constraints............................................................................................................................................................................................................7
2.3 Assumptions.......................................................................................................................................................................................................8
2.4 Risks...........................................................................................................................................................................................................................8
3 Current State Assessment..........................................................................................................................................10
3.1 Legacy Infrastructure..................................................................................................................................................................................10
3.1.1 Logical Design......................................................................................................................................................................................10
3.1.2 Virtual Infrastructure.........................................................................................................................................................................11
3.1.3 Storage System.....................................................................................................................................................................................11
3.2 Current State VM Inventory.....................................................................................................................................................................11
3.3 Current State Target Infrastructure..................................................................................................................................................12
4 Migration Design........................................................................................................................................................13
4.1 Design Decisions............................................................................................................................................................................................13
4.2 Migration Methodology.............................................................................................................................................................................13
4.3 Nutanix Move Details...................................................................................................................................................................................15
4.4 Citrix Virtual Apps and Desktops Migration Methodology...............................................................................................16
4.5 VMware Horizon Migration Methodology....................................................................................................................................17
4.6 Dizzion Frame Migration Methodology.........................................................................................................................................18
4.7 EUC User Migration Methodology.....................................................................................................................................................19
5 Target Environment State...........................................................................................................................................21
5.1 Logical Cluster Design................................................................................................................................................................................21
5.1.1 Failure Domains...................................................................................................................................................................................21
5.2 Logical Cluster Features...........................................................................................................................................................................22
5.2.1 Workload Resource Balancing and VM Affinity..........................................................................................................22
5.2.2 Workload High Availability and Admission Control..................................................................................................23
5.2.3 Workload Live Migration and Enhanced vMotion Support.................................................................................23
5.3 Platform Selection and Datacenter Infrastructure...............................................................................................................23
5.3.1 Physical Hardware Specifications..........................................................................................................................................23
5.3.2 Rack Layout............................................................................................................................................................................................25
5.4 Resource Sizing..............................................................................................................................................................................................25
5.4.1 Nutanix Cluster Sizing....................................................................................................................................................................25

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
Workload Migration: Design Document

5.4.2 Nutanix CVM Sizing..........................................................................................................................................................................25

5.4.3 Resource Sizing Design Decisions........................................................................................................................................26
5.5 Nutanix Files.....................................................................................................................................................................................................26
5.5.1 Software Version................................................................................................................................................................................27
5.5.2 FSVM Compute Resources.........................................................................................................................................................27
5.5.3 Account and Group Permissions............................................................................................................................................27

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

1 Introduction
Consultant: Fill in the missing information and remove sections that don’t
apply to this deployment before providing to the customer.
<Customer Name> is migrating workloads and users from legacy infrastructure to the Nutanix platform.

<Customer Name> wants to gain the financial, business, and operational benefits of a hyperconverged
infrastructure, and has engaged Nutanix Services to develop, plan, and perform migration to a new
solution. The future state virtual infrastructure should support its existing and future workloads using
<VMware ESXi / Nutanix AHV> as the hypervisor and Nutanix solutions for software-defined storage and
data protection, including disaster recovery on-premises and to a disaster recovery site. The goal is to
establish a highly available and efficient next-generation infrastructure based on <Nutanix and
VMware / Nutanix> recommended practices.

1.1 Document Purpose

The purpose of this document is to provide <Customer Name> staff with a migration design blueprint
for their new hyperconverged infrastructure platform based on Nutanix. The document addresses
conceptual, logical, and physical design elements with design decisions throughout the document to
justify each infrastructure design choice.

1.2 Audience
We created this document for those planning, designing, or implementing the components of a
Nutanix hyperconverged infrastructure, including:

 Project sponsors
 Virtualization architects
 Project managers
 Business decisionmakers
 Technical teams (EUC, server, networking, security, backup and recovery)
The following software versions are used throughout the design and are valid as of the publication date
prior to implementation.

1.3 Software Versions

The following table provides the software versions used throughout the design.

Table 1 Software Versions

Component Version Install Options/Version/License

Prism Central pc.2020.8 NCM Pro

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
Workload Migration: Design Document

Component Version Install Options/Version/License

VMware ESXi ESXi 6.5.0.33000 – Build 13932383 Enterprise Plus

VMware vCenter VMware vCenter 6.5 - 16613358 vCenter Server Standard –

vCenter Appliance

Nutanix Move 4.1 N/A

Always check for the latest software versions before beginning the project.

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

2 Requirements, Constraints, Assumptions, and

Risks
During the design workshops, we gathered both business and technical requirements and referenced
them to create a high-level migration plan to the new solution.

<<Enter Customer Name Here>>’s specific requirements, constraints, assumptions, and risks are
provided in the sections below.

2.1 Requirements
Business requirements have been sorted into conceptual and logical design elements as follows:

 Recoverability: How the platform is recovered during a disaster

 Availability: How the platform handles resilience to meet business service-level agreements (SLAs)
 Manageability: How the platform is managed in day-to-day operations
 Performance: How performant the platform is in meeting workload requirements
 Security: How the platform is secured and meets compliance
 Scalability: How the platform can scale to meet current and future needs
Where design decisions are mentioned in the design, references to the associated requirements are
also included.

**NOTE TO CONSULTANT (TO BE DELETED)**

Below are sample requirements. Do not reuse without validating and
changing to suit the specific customer requirements
While documenting a requirement, make sure to take steps to minimize any
vagueness or ambiguity. Ambiguous requirements might lead to
misinterpretation.
Table 2 Design Requirements

ID Area Requirement Trace

B101 Recoverability Migration methodology and tools must provide an DD01

efficient rollback process.

B102 Availability Migration methodology and tools should minimize DD02

application or virtual machine downtime.

B103 Manageability Migration tool should support automation using DD03

RestAPI.

B104 Performance Migration methodology and tools should provide DD04

maximum performance to meet the migration

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

ID Area Requirement Trace

project timeline.

B105 Security Migration console should support authentication to DD05

limit unauthorized access.

2.2 Constraints
**NOTE TO CONSULTANT (TO BE DELETED)**
Below are sample constraints. Do not reuse without validating and changing
to suit the specific customer requirements
A constraint can be one of two types: Business or technical
Business constraints depend on the state of your organization. They are high-
level constraints and often defined when the project starts, like time, budget,
and resources. Changes to these constraints are rare, and the project
management team has to work within them.
Technical constraints limit your design choices. They are fixed, and any change
to the technical specifications can affect your design.
Every design has constraints. Therefore, you must identify all of them and
develop your plan accordingly. Constraints are outside of your control and
imposed by clients, organizations, or government regulations.
The requirement-gathering workshops identified specific constraints. Constraints limit the logical
design decisions and physical specifications for the design.

Where design decisions are called out in the design, a reference to the associated constraint is made
where applicable.

Table 3 Design Constraints

Traceability of
ID Constraints
Requirement

C101 Hardware choice is predetermined; <<Enter Customer Name Here>> DD01

uses 24 NX-3060-G7 nodes.

C102 VMware ESXi/Nutanix AHV is the chosen hypervisor. DD02

C103 A maximum of 2 Gbps bandwidth exists between DC1 and DC2 DD03
datacenters.

C104 Migration of 50 VMs in a plan is qualified and supported for ESXi DD04
migration. (Move Version 4.6).

C105 The following licenses have been purchased for use in the design: DD05
 VMware vSphere: Enterprise Plus
 Nutanix NCI Node: NCI Pro

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

Traceability of
ID Constraints
Requirement

 Nutanix NCM Prism Central: NUS Pro

 Nutanix Unified Storage: Pro

C106 Legacy storage system is running out of capacity. DD07

2.3 Assumptions
**NOTE TO CONSULTANT (TO BE DELETED)**
Below are sample Assumptions. Do not reuse without validating and changing
to suit the specific customer requirements.
Any assumption is a potential risk for your project because the project might
fail if any assumption is false. Your risk management plan heavily depends on
assumptions and constraints. Failing to identify any of them can affect your
project.
Assumptions are expectations about the implementation and use of a system that cannot be confirmed
during the design phase. They provide guidance within the design. If assumptions aren’t met, the
respective design areas are at risk. Key stakeholders must accept and sign off on all assumptions before
the design document is accepted.

Table 4 Design Assumptions

Item Description Assumption Accepted

A101 Operations staff have the required technical knowledge to test ☐

and troubleshoot the VDI broker.

A102 Customer support team or application owners develop and ☐

provide a UAT checklist.

A103 Dependent infrastructure is fully functional and includes: ☐

 Active Directory
 DNS
 NTP
 SMTP
 Backup Software
 DHCP
 Firewalls
 Switches and routing

A104 Target infrastructure is ready for new workloads. ☐

A105 Target solution has enough resources (CPU, RAM, storage) to ☐

accommodate migrated workloads.

A106 Customer provides up-to-date VM and application inventory. ☐

A107 Customer provides up-to-date application dependency map. ☐

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

Item Description Assumption Accepted

A108 Customer is responsible for application UAT after migration. ☐

2.4 Risks
**NOTE TO CONSULTANT (TO BE DELETED)**
Below are sample Risks. Do not reuse without changing to suit the specific
customer requirements.
Communicate risk factors in a clear and concise manner so that all
stakeholders can understand them. You can achieve this by writing an
effective risk statement.
A high-quality risk statement can answer the following questions:
What could happen?
Why could it happen?
Why should an enterprise care?
Risks must also have an associated impact and mitigation.
The design workshop identified certain risks. The risks are described in the following table with an
impact, mitigation assessment, and traceability to associated design decisions.

Table 5 Design Risks

Item Risk Description Impact Mitigation

R101 Project timeline Running an unsupported Extend support

configuration

R102 Low bandwidth link between Exceeding project timeline Upgrade link between
source and Nutanix datacenters to meet
project timeline

R103 Some of the VMs running guest Running applications in an Upgrade guest OS
OS versions not supported by the unsupported configuration before migration or
hypervisor migrate VM manually

R104 Some of the applications running Extends project timeline Deploy virtual appliance
on virtual appliances on Nutanix

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

3 Current State Assessment

To ensure all requirements can be met in the design, we documented the current state, including a
high-level design of existing infrastructure, networking infrastructure, and VMs in scope for migration.

3.1 Legacy Infrastructure

3.1.1 Logical Design

The following figure shows the logical design of the existing clusters to be migrated to the Nutanix
hyperconverged platform.

Figure 1 Logical Design of Existing Clusters

The key attributes of the current state are as follows:

 The primary datacenter is in <location>. The secondary and disaster recovery datacenters are in
<location>, with a VDI cluster consolidated to <location>.
 Clusters are running <ESXi on Nutanix> at the last hardware refresh.
 <Three> clusters currently exist. We’re consolidating into <two>.
 <Two> separate <vCenter servers> are deployed with <internal Platform Service Controllers, not in
linked mode>.
 The clusters currently run <vCenter 7.0 and ESXi 7.0>. We plan to upgrade to <8.0> during or after
the hardware refresh.
 Networking bandwidth between datacenters is <value>.

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

3.1.2 Virtual Infrastructure

 The following table shows information about physical components from legacy infrastructure.
Table 6 Legacy Infrastructure Physical Components

ID vCenter Name Cluster Name # VMs Data Volume Networking Speed Storage FC Speed

3.1.3 Storage System

The following table shows information about the legacy storage subsystem.

Table 7 Legacy Storage Subsystem

ID Storage Name Storage Free Space Peak IOPS Peak Latency Storage
Capacity FC/iSCSI/NFS
Speed

3.2 Current State VM Inventory

The following table provides information about VMs for workloads we plan to migrate.

Table 8 Current VM Inventory

ID Guest OS Version # Systems Data Volume Location

1 Windows 2012R2 40 50 TB DC1, AWS region 1

2 Windows 10 400 20 TB DC1

3 Linux 10 5 TB DC1

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

3.3 Current State Target Infrastructure

Figure 2 Usable Capacity, Production Cluster

Figure 3 Usable Capacity, Disaster Recovery Cluster

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

4 Migration Design

4.1Design Decisions
Table 9 Design Decisions

Associated Associated
ID Design Decision Design Justification
Requirements Constraints

Use Nutanix Move for Nutanix Move is free software to

DD01 B101, B102 C101, C102
migration. support migration to AHV

Use multiple Nutanix To speed up the migration

DD02 B101, B102 C101, C102
Move instances. project timeline

Use bandwidth Due to limited bandwidth

DD03 B101, B102 C101, C102
throttling. between datacenter bandwidth

vSphere shared-nothing
Use vSphere shared-
DD04 migration is the easiest and B101, B102 C101, C102
nothing migration.
quickest way to migrate

Leveraging shared-nothing
DD05 Set EVC baseline to migration across two vSphere B101, B102 C101, C102
clusters requires

4.2 Migration Methodology

Consultant: Define and provide high-level information about the full EUC
migration methodology. Expand with low-level information for each migration
service included in the engagement.
The following figures show the high-level architecture for the VM migration project.

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
Workload Migration: Design Document

Figure 4 Migration from VMware to Nutanix AHV

Figure 5 Migration from Hyper-V to Nutanix AHV

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

Figure 6 Migration from Legacy ESXi to Nutanix ESXi

4.3 Nutanix Move Details

The following table provides information about the Nutanix Move configuration.

Table 10 Move Details

Type Name IP Address

vCenter

Hyper-V

Nutanix Move

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
Workload Migration: Design Document

Figure 7 Distributed Architecture of Nutanix Move

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

5 Target Environment State

5.1 Logical Cluster Design

Consultant: Edit the figure to represent the future environment
The following figure shows the logical cluster design of the future environment. Each hyperconverged
cluster is represented as follows:

 Gray: Nutanix clusters

 Purple: Virtualization clusters
 White: Storage containers

Figure 8 Logical Cluster Design

5.1.1 Failure Domains

The enterprise architecture design appropriately subscribes to the concepts of failure domains. If a
technological domain fails, it should ideally minimize the impact to other dependent technological
domains. In this design, the following domains are considered failure domains that can impact the
normal operations to deliver IT services.

Table 8 Failure Domains

Domain Description Failure Mitigation

Workloads are mainly run in ESO with few in

There are two different
Datacenter Reston. ESO workloads are replicated to each
datacenters that are
other in case of a site failure.
geographically separated.

Site Each site has an Arista-based Every component has local redundancy to

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

Domain Description Failure Mitigation

network with no common points mitigate against failure. However, if a logical

of failure. The networking team failure occurred, it might vary from rack-local to
plans to adopt the leaf-spine sitewide.
architecture, where each rack Localized rack failure can then rely on
hosts a pair of top-of-rack leaf alternatives in having availability across racks.
switches. Site-local failure must rely on the alternate site.

Because each rack has redundant PDUs, the loss

of one power source shouldn’t impact devices
Each rack in a datacenter has a
Rack that are properly connected to both sources.
dedicated pair of redundant
In an extreme case where a rack loses both
power distribution units (PDUs).
sources of power, we can consider failing over
services to the other site.

Each cluster has compute and storage capacity

reservations to ensure that self-healing can take
place.
Nutanix clusters are designed to
You can also upgrade a cluster to replication
withstand a single failure and can
factor 3 to tolerate double concurrent failures.
Cluster self-heal before replacement or
However, this configuration consumes more
repair as long as sufficient
capacity because it stores three copies of data
capacity is available in the cluster.
instead of two.
In an extreme case, if a cluster-wide failure
occurs, services can fail over to another site.

Nutanix
Failure of Prism Central doesn’t impact normal
Prism Prism Central isn’t a relevant
cluster operation, as clusters can be individually
Central failure domain.
managed via Prism Element.

In the event of a vCenter failure, VMs continue to

VMware operate. Individual VMs can be operated by
vCenter isn’t a relevant failure
vCenter connecting directly to the ESXi host. Simple
domain.
power on and off operations can also be
accomplished via Prism.

5.2 Logical Cluster Features

5.2.1 Workload Resource Balancing and VM Affinity

Each <ESXi> hypervisor uses a built-in mechanism to control workload balancing and ensure that VMs
move to other hosts in the case of cluster contention. Depending on the hypervisor choice, both
memory and CPU and storage metrics can be used to determine initial and ongoing VM placement in
the cluster. To ensure resources are sufficient to allow cluster maintenance and host failure, the new
cluster is sized for n + 1. If VMs require affinity or anti-affinity rules to a specific host, or group of hosts,
each hypervisor provides functionality for this purpose.

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

5.2.2 Workload High Availability and Admission Control

Each hypervisor provides a mechanism to ensure that workloads restart in the event of a host failure.
The hosts are monitored for both hardware and network failures; in the event of failure, VMs restart on
surviving hosts.

5.2.3 Workload Live Migration and CPU Compatilbity

Each hypervisor also provides a mechanism to manually move workloads between hosts online, in the
case of maintenance or other operational tasks. Depending on hypervisor choice, a dedicated network
can be configured for live migration. To ensure that VMs can be migrated to hosts with different CPU
versions, enhanced vMotion support (EVC) at the latest current CPU generation can be enabled on each
cluster using the method described in the cluster physical design.

5.3 Target Datacenter Infrastructure

5.3.1 Physical Hardware Specifications

<Customer Name> has selected the Nutanix <NX-8050-G9> as the basis of its virtualization platform. The
following naming is used for the <NX-8050> platform according to the number of nodes per block:

 NX-8050 (single node)

The NX-8050 consists of a 2RU form factor as shown in the following diagram.

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
Workload Migration: Design Document

Figure 9 Front Panel

Figure 10 Back Panel

Table 12 Hardware Specifications

Specification 1 SSD (Ohio and

Attribute Specification 2 NVMe (Boston)
Boston)

Nutanix Chassis Model NX-8050-G9 NX-8050-G9

Model Type All SSD NVMe

2 x Intel Xeon-Gold 6342

2 x Intel Xeon-Gold 6442Y processor (2.6
CPU Type processor (2.8 GHz/ 24-core/
GHz/ 24-core/ 225W) (48 Cores)
230W) (48 Cores)

16 x 64GB Memory Module 16 x 64GB Memory Module (4800MHz

RAM
(3200MHz DDR4 RDIMM) DDR5 RDM)

NVMe N/A 10 x 3.84 TB NVMe SSD

SSD 10 x 3.84 TB SSD N/A

HDD N/A N/A

NIC LOM (Onboard) 2 x 10GBaseT (IPMI Failover) 2 x 10GBaseT (IPMI Failover)

NIC LOM (Onboard) 1 x 1GbE Dedicated IPMI 1 x 1GbE Dedicated IPMI

NIC (Add-on) 2 x Mellanox 25/10GbE, 2-port, 2 x Mellanox 25/10GbE, 2-port, NIC (CX6

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

Specification 1 SSD (Ohio and

Attribute Specification 2 NVMe (Boston)
Boston)

NIC (CX6 25GbE) 25GbE)

1 x LOM Module: Broadcom 10GbE, 2-port,

NIC LOM/AIOM (Add-on) N/A
Base-T NIC (BMC 57416)

GPU None None

5.3.2 Rack Layout

All the nodes are installed in <two racks at the Ohio datacenter and one rack at the Boston datacenter>.
To support the power requirements and ensure power redundancy for Nutanix blocks, we installed
<two PDUs per rack> and distributed Nutanix blocks <across all PDUs>. For redundancy, power supply A
goes to <the left PDUs> and power supply B to <the right PDUs>.

5.4 Resource Sizing

To accommodate all the sizing of the applications identified in the current state assessment, we used
the following sizing calculations for the Nutanix clusters. Since the clusters are configured with
<replication factor 2>, we sized for <n + 1>, with a <30 percent> estimation for data reduction. We sized to
accommodate a site failover. We didn’t consider hyperthreads for the vCPU-to-pCPU ratio.

Each CVM used for the Nutanix platform is sized for <12 vCPU> and <40 GB> of memory, which is the
recommended configuration for the applications we’re migrating. Although more memory can help
with read I/O from the unified cache, due to the memory constraints of each node (<1024 GB>), <40 GB>
of memory provides a good balance. The vCPU and memory overhead for the CVM is sized the same as
any other VM.

5.4.1 Nutanix Cluster Sizing

To accommodate failure, we reserved the capacity of a single node in the cluster. The following table
illustrates the cluster sizing we used, taking n + 1 into consideration.

Table 13 Cluster Sizing for Replication Factor 2

Sum of Total Total

Sum of
Node Physical Physical Logical
Nutanix Cluster Physical
Count Memory Capacity Capacity
Cores
(GB) (TB) (RF2) (TB)

Production Cluster Ohio 12 576 12288 460.8 230.4

Production Cluster Boston 10 480 10240 384 192

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

5.4.2 Nutanix CVM Sizing

To accommodate CVM overhead, we used the following CVM sizing calculations in the cluster.

Table 14 CVM Sizing

CVM CVM CVM RAM Total Cluster Total Cluster

Nutanix Cluster
Count vCPU (GB) CVM vCPU CVM RAM (GB)

Production Cluster Ohio 12 14 48 168 576

Production Cluster Boston 10 14 48 140 480

5.4.3 Resource Sizing Design Decisions

We made the following design decisions for resource sizing.

Table 15 Sizing Design Decisions

Associated Associated
ID Design Decision Design Justification
Requirements Constraints

DD06 Space savings Nutanix has typically seen B101, B102 C101, C102
assumption of 30% made space savings of at least
for all clusters 50% with compression
enabled, so 30% is a
conservative estimate.

DD07 CVMs sized with 32 GB of Sizing CVMs up to the B101, B102 C101, C102
memory and 12 vCPU maximum vCPU size
supported by the
underlying NUMA node
ensures that maximum
performance is available for
running VMs that require
high I/O. 12 vCPU also helps
decrease rebuild time
during a node failure. We
recommend 32 GB RAM for
applications that run on the
Nutanix platform.

5.5 Nutanix Files

Each site has a Nutanix Files deployment and serves respective region and site users file shares. The
existing file share data is migrated to Nutanix Files.

Nutanix clusters run AHV in each site for the Nutanix Files deployment. The naming convention for each
Nutanix Files deployment is shown in the following table. These are temporary names; after the
migration, the Nutanix Files shares are renamed with the existing file share service names.

Table 16 Nutanix Files

Site Name Nutanix Cluster Nutanix Files Nutanix Files FQDN

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.
 Workload Migration: Design Document

Site1 NTNX_CLS1 NTNX_FILES1 NTNX_FILES1.[Link]

Site2 NTNX_CLS2 NTNX_FILES2 NTNX_FILES2.[Link]

5.5.1 Software Version

Use the latest available version of Nutanix Files during the deployment stage. As of this writing, the
latest available version of Nutanix Files is <Nutanix Files [Link]>.

5.5.2 FSVM Compute Resources

Each FSVM must have specific compute resources based on the user’s connection to Nutanix Files. You
can change the compute configurations at any time.

Note: Resources can only be increased, not decreased.

Table 17 FSVM Compute Resources

Supported Connections
Files Cluster # FSVMs vCPU per FSVM Memory per FSVM
per FSVM

NTNX_FILES1 3 4 12 500

NTNX_FILES2 4 6 32 2000

5.5.3 Account and Group Permissions

The following default permissions apply for distributed and standard shares.

Table 18 Distributed and Standard Share Permissions

Role Distributed Shares and Exports Standard Shares and Exports

Domain administrator Full access Full access

Creator owner Full access (inherited only) Full access (inherited only)

Domain user Read only Full access

Tel 1 (855) 688-2649 • Fax 1 (408) 916-4039 • Email info@[Link] • ©2024 Nutanix, Inc. All Rights Reserved.