The following blog provides an overview of the VMware Cloud Foundation (VCF) Import Tool that was introduced with VCF 5.2. The VCF Import Tool enables vSphere Administrators to easily convert existing vSphere and vSAN infrastructure to a Cloud Foundation Private Cloud. More information about the VCF Import Tool can be found in the Cloud Foundation Administrators Guide.
Introduction to the VCF Import Tool
VMware Cloud Foundation 5.2 introduces a new CLI tool, referred to as the “VCF Import Tool”, to convert or import existing vSphere environments that are not currently managed by the SDDC Manager into a VMware Cloud Foundation private cloud. Feel free to check out this 6-minute video to see a demo of the VCF Import Tool in action.
The VCF Import tool enables customers to expedite their move to a modern private cloud by enabling them to quickly implement Cloud Foundation directly on top of their existing vSphere infrastructure. There is no requirement to purchase new hardware, go through a complex deployment, or have to migrate workloads. You simply deploy the SDDC Manager to an existing vSphere cluster and use the import tool to convert it to a Cloud Foundation private cloud.
Importing your existing vSphere infrastructure into a VCF private cloud is non-disruptive as it is transparent to the running workloads. At a high level the process entails scanning the vCenter inventory to ensure compatibility with VCF and then registering the vCenter Server, and its associated inventory, with the SDDC manager. The registered vCenter Server instances become VCF workload domains that can be centrally managed and lifecycled from the SDDC Manager as part of a VMware private cloud. Once added to the Cloud Foundation inventory, all the available SDDC Manager operations are available to manage the converted/imported domain. This includes expanding the domains by adding new hosts and clusters as well applying software updates and upgrades.
Overview of the VCF Import Tool
There are two ways to get started with using the VCF Import Tool.
- If you do not already have an SDDC Manager appliance deployed in your data center, the first step is to manually deploy an instance of the appliance on an existing vSphere environment. You then use the VCF Import Tool to convert that environment to the VMware Cloud Foundation management domain.
- If you already have an instance of the SDDC Manager running in your data center, you simply upgrade it to VCF 5.2 and use it to begin importing existing vSphere environments as VI workload domains.
Note that in addition to importing and converting vSphere environments into VCF as workload domains, the VCF import tool can also be used to deploy NSX into a converted or imported domain. This can be done at the time you do the convert/import, or as a ‘day-2’ operation run any time after the environment has been added as a workload domain. Also, the import tool includes a ‘sync’ feature that allows you to manage configuration drift between the vCenter Server and SDDC manager. More information about these features is discussed below.
Requirements for using the VCF Import Tool
To get started with using the VCF Import Tool there are several requirements that must be met. The requirements vary depending if you are converting an existing vSphere environment into a VCF management domain or importing an existing vSphere environment as a Virtual Infrastructure (VI) domain. I’ll begin by going over the requirements that are unique to converting a VCF Management Domain. I’ll then go over the requirements that are common for both the convert and import use-case.
Note: the requirements and limitations noted in this blog are based on the initial release of the VCF Import Tool available with VCF 5.2. Be sure to check the release notes to see if these limitations are still applicable for the version of VCF you are using.
Requirements for converting a vSphere cluster to a VCF Management Domain
To convert an existing vSphere environment into a VCF management domain there are two requirements that you need to be aware of.
- First, the vSphere environment that you will convert needs to be running vSphere 8.0 update 3 or higher. This includes both the vCenter Server instance and the ESX hosts. This is the version of vSphere that is associated with the VCF 5.2 Bill of Materials (BOM). This requirement is due, in part, to the fact that you must first deploy the SDDC manager appliance into the cluster, and the 5.2 version of the SDDC Manager appliance requires vCenter and ESXi version 8.0 update 3 (or above).
- Second, when converting a vSphere environment, the vCenter server must be running on the cluster that is being converted. The documentation refers to this as the vCenter server needing to be “co-located” with the cluster.
Requirements for importing a vSphere cluster to a VCF VI Domain
Like converting a new management domain. There are two key requirements that you need to be aware of when importing a vSphere environment into a VCF VI domain,
- First, the supported vSphere versions that can be imported as a VI domain are vSphere 7.0 update 3 and above. Again, this includes both the vCenter Server instance and the ESXi hosts. Note that the minimum version of 7.0 update 3 is the vCenter and ESXi version that corresponds with the VCF 4.5 Bill of Materials (BOM).
- Second, when importing a vSphere environment, the vCenter server must either be running on the cluster that is being converted (co-located) or running on the cluster in the management domain.
Common requirements when converting and importing vSphere clusters
Along with the requirements noted above, the following requirements are applicable to both converting and importing vSphere infrastructure.
- All hosts within a vSphere cluster must be homogeneous. Essentially, all the hosts in a cluster need to be the same in terms of capacity, storage type, and configuration (pNICs, VDS, etc.). Server configurations can be different across clusters, but within a cluster the hosts must be the same.
- Clusters to be converted and imported must be running one of the three supported storage types: vSAN, NFS, or VMFS on Fiber Channel (FC). This is often an area of confusion because when doing a greenfield deployment of VCF using the Cloud Builder appliance the storage for the management domain must always be vSAN. Be aware that the vSAN requirement does not apply to converted management domains where the storage can be either vSAN, NFS or VMFS on FC.
- When using vSAN, the minimum number of hosts required for the management domain is always four. However, when using NFS or VMFS on FC the minimum number of hosts required is three. Here again, this is different than when doing a greenfield deployment with the Cloud Builder.
- Enhanced Linked Mode (ELM) is not supported with the VCF Import Tool. Each vCenter Server instance to be converted or imported as a VCF workload domain must be in its own SSO domain. As such, each converted or imported vCenter instance will instantiate an isolated workload domain in VCF. This can be a concern for customers who are accustomed to having a single pane of glass with their VCF environment. Be sure to check out the new dashboards provided by VCF Operations (formerly Aria Operations) as they can help mitigate this change.
- All clusters in the vCenter inventory must be configured with one or more dedicated vSphere Distributed Switches (VDS). Note that vSphere Standard Switches (VSS) are not supported. What’s more, if you have a VSS configured in your cluster it will need to be removed before you can import the cluster. Also, it’s important to note that a VDSs cannot be shared across vSphere clusters.
- There can be no standalone ESXi hosts in the vCenter inventory. Standalone hosts will need to either be moved to a vSphere cluster or removed from the vCenter inventory.
- All clusters must have DRS enabled in fully automated mode and all hosts must have a dedicated vMotion network configured.
- All vmkernel adapters must have statically assigned IP addresses. As part of the convert/import process, a network pool will be created inside the SDDC Manager using the assigned IPs. Once the import is complete, these IPs must not change. As such, the IPs need to be statically assigned.
- vSphere environments cannot have multiple vmkernel adapters configured for a single traffic type.
Notable Limitations with the Import Tool in VCF 5.2
Having noted the requirements for using the VCF Import tool, there are a few notable limitations associated with VCF 5.2 that you need to be aware of. Be aware that the VCF Import workflows includes a ‘check’ function that scans the vCenter inventory prior to attempting the convert or import operation that looks for these conditions, and if detected the workflow will stop.
The following topologies cannot be converted or imported using the VCF Import tool in VCF 5.2:
- vSphere environment configured with NSX.
- vSphere environments configured with the AVI Load Balancer.
- vSphere environments configured with vSAN Stretched Clusters.
- vSphere environments with vSAN configured in ‘compression only’ mode.
- vSphere clusters with shared vSphere Distributed Switches (VDS).
- vSphere environments with the IaaS Control Plane (formerly vSphere with Tanzu) enabled.
- vSphere environments configured with Link Aggregation Control Protocol (LACP).
- VxRail environments.
Installing NSX on Converted and Imported Workload Domains
When discussing the limitations associated with the VCF Import Tool I noted that you cannot convert or import clusters that are configured for NSX. However, after the domain has been converted/imported you can use the VCF Import tool to install NSX. You can choose to install NSX at the same time you do the convert/import, or any time after as a day-2 operation.
One important thing to keep in mind when using the VCF Import Tool to install NSX on a converted or imported workload domain is the fact that virtual networking and logical routing is not configured as part of the NSX install. The import tool installs NSX and configures the distributed port groups in the NSX Manager. This allows you to begin using the NSX distributed firewall to protect deployed workloads. However, to take advantage of the virtual networking and logical switching capabilities provided by NSX, additional configuration is required as you will need to manually configure the host Tunnel Endpoints (TEPs).
Using the VCF Import tool to Sync Changes with vCenter Server
Along with the ability to import existing vSphere infrastructure into Cloud Foundation, the import tool also provides a ‘sync’ feature that allows you to update the SDDC Manager with changes made to the vCenter Server inventory helping to maintain consistency and accuracy across the environment.
In the course of managing vSphere infrastructure that is part of a Cloud Foundation private cloud, there are situations where you may need to make changes directly to the vSphere environment. In some cases, changes made directly to the vCenter inventory may not be captured by the SDDC manager. If the SDDC Manager inventory becomes out of sync with the vCenter inventory, it can cause some of the automation workflows to become temporarily blocked. To avoid this, you run the import CLI tool with the ‘sync’ parameter to update the SDDC manager inventory with any changes made to the vCenter configuration.
Conclusion
This concludes my introduction to the VCF Import feature introduced with VCF 5.2. This tool makes it easy to get started with a VCF by converting your existing vSphere infrastructure to a VCF private cloud. If you found this blog helpful, again I recommend you check out this 6-minute video to see a demo of the VCF Import Tool in action.
