The VCF Import Tool helps customers transform existing vSphere or vSphere + vSAN environments into VMware Cloud Foundation environments in two ways.Convertcap (a poem)Import.. Previously in this (Use the VCF Import Tool to convert an existing vSphere environment to a management domain.) article demonstrated the process of converting an existing vSphere environment into a workload domain for management in a VCF solution, so this article picks up on that theme and looks at how you can use this tool to import an existing vSphere environment into a VI workload domain in a VCF solution.
I. Requirements and restrictions on use
Note that using the VCF Import Tool to perform the Import process has the same characteristics as the previous Convert process.Requirements and restrictions, so please refer to the previous article (Use the VCF Import Tool to convert an existing vSphere environment to a management domain.) in the description, which will not be repeated here.
One of the usage requirements and limitations is that vCenter Server VMs in existing vSphere environments are either located within their own cluster or running on a VCF management domain cluster, two different scenarios occur when an NSX scenario is deployed at the same time as an Import task:
- If the vCenter Server virtual machine is running within its own vSphere cluster, when an import task is performed and an NSX scenario is deployed at the same time, the NSX Manager virtual machine is deployed to the vSphere cluster.
- If the vCenter Server virtual machine is running on a VCF management domain cluster, when an import task is performed and an NSX solution is deployed at the same time, the NSX Manager virtual machine is deployed to the VCF management domain cluster.
Existing vSphere environments
In order to fulfill the requirements and limitations of the VCF Import Tool, it is also necessary to check the information of the existing vSphere environment. The existing vSphere environment to be used for the Import is shown in the following figure, a vSAN ESA standard cluster consisting of 3 hosts, the details of the checking process are skipped here, please refer to the previous article for details.
The vCenter Server virtual machine for the current vSphere environment runs on a VCF management domain cluster (note that adjustments are made later).
III. Performing pre-introduction pre-checks
Before performing an Import operation on an existing vSphere environment, you need to perform a pre-check on SDDC Manager to determine if the current vSphere environment meets the requirements to be imported as a VI domain. There is no need to upload the VCF Import Toolkit to SDDC Manager since it was already uploaded to SDDC Manager during the previous Convert. Connect to the command line of SDDC Manager via SSH as the vcf user and use the following command to enter the vcf-brownfield-toolset directory.
cd /home/vcf/vcfimport/vcf-brownfield-import-5.2.0.0-24108578/vcf-brownfield-toolset/
After entering the catalog, use the following commands to perform an environment check on SDDC Manager. There are a total of 83 entries, 82 successful checks, 0 failures, and 1 internal error.
python3 vcf_brownfield.py check --vcenter --sso-user administrator@ --sso-password Vcf520@password
Based on the output of the check, see the contents of the specific error. The Compatibility validation item checks for errors as follows.
An error occurred when validating VMware Cloud Foundation compatibility: File with Compatibility Matrix Content for Compatibility controller VMWARE_COMPAT is not found.
This error had to be resolved or it would not continue later. At first, I thought it was caused by a problem with the vSAN HCL file, and after all kinds of attempts and verification, and even cleared the management domain that was converted before, and redeployed the VCF management domain environment, but the result was that this error could not be fixed. Then I realized that this error refers to the "Compatibility Matrix" compatibility data file can not be verified, which is a special compatibility matrix data for VCF, and vSAN HCL database file is somewhat similar but not the same, that is, this data is missing and can not be verified, so this data is not available. That is, this data is now missing and cannot be verified, so there is this internal error. In fact, you can also see this error in the SDDC Manager UI in the figure below. Whether the domain is converted or deployed using Cloud Builder, this VCF compatibility data is not available by default, and we need to download and update it manually.
How to manually download and update the VCF compatibility data file, also known as the "Compatibility Matrix" file, can be found in this article《Offline Download of VMware Cloud Foundation 5.2 Upgrade Bundles》Product Documentation. The process is that you need to use the Bundle Transfer Utility to download the "Compatibility Matrix" compatibility data file, and then use this utility to update the compatibility data file into VCF.
For this tool, you can download it from the Broadcom Support Portal (BSP), and I've uploaded the tool and the "Compatibility Matrix" compatibility data file to this Baidu.com link./s/1lUbrN0zjLUUC1oB8L7ZRAg?pwd=lvx9), you can download it if you need it. Below I will demonstrate how to download this compatibility data file and update it to SDDC Manager.
If the VCF environment can connect to the Internet, you can use this tool to perform the download and update process on SDDC Manager directly. However, if you cannot connect to the Internet, you can find a Linux host that can connect to the Internet, and then use the tool to download the compatibility data file () on the host, save it locally after downloading, and then upload the file to SDDC Manager on the intranet environment to complete the update using this tool. Save the file locally, upload it to the SDDC Manager on the intranet environment, and then use the tool to complete the update. Note that downloading the compatibility data file requires that you have theBroadcom Support Portal(BSP) account, you can download without VCF privileges and only with normal user privileges.
Upload the Bundle Transfer Utility tool to a Linux host with an Internet connection, unzip it and give the lcm-bundle-transfer-util utility execute permissions, then download the "Compatibility Matrix" compatibility data file using the following command Compatibility Matrix" compatibility data file using the following command.
./lcm-bundle-transfer-util --download --compatibilityMatrix --depotUser xxxxxxxx@
After obtaining the VCF compatibility data file, upload the file, along with the Bundle Transfer Utility tool, to the SDDC Manager in the VCF management domain, unzip the tool and adjust the permissions using the following command.
mkdir /opt/vmware/vcf/lcm/lcm-tools
cd /opt/vmware/vcf/lcm/
tar -xvf
chown vcf_lcm:vcf -R lcm-tools
chmod 750 -R lcm-tools
Go to the directory where the tool is located and use the following command to update the VCF compatibility data, please note the directory location used for the "inputDirectory" option in the command.
./lcm-bundle-transfer-util --update --compatibilityMatrix --inputDirectory /home/vcf/ --sddcMgrFqdn --sddcMgrUser administrator@
After updating the "Compatibility Matrix" compatibility data, run the environment check again with the following command and all checks are now successful.
python3 vcf_brownfield.py check --vcenter --sso-user administrator@ --sso-password Vcf520@password
Preparing NSX Manager
When we do a Convert, we also perform a deployment of NSX, and when we do an Import, we can also perform a deployment of NSX at the same time. This step is optional, you can perform the NSX deployment at the same time as the import process, or you can perform the NSX deployment at some other time after the import is finished, just skip it with the --skip-nsx-deployment option. The following are required to perform an NSX deploymentJSON Configuration File。
{
"license_key": "AAAAA-BBBBB-CCCCC-DDDDD-EEEEE",
"form_factor": "medium",
"admin_password": "Vcf520@password",
"install_bundle_path": "/nfs/vmware/vcf/nfs-mount/bundle/",
"cluster_ip": "192.168.32.76",
"cluster_fqdn": "",
"manager_specs": [{
"fqdn": "",
"name": "vcf-vi01-nsx01a",
"ip_address": "192.168.32.77",
"gateway": "192.168.32.254",
"subnet_mask": "255.255.255.0"
},
{
"fqdn": "",
"name": "vcf-vi01-nsx01b",
"ip_address": "192.168.32.78",
"gateway": "192.168.32.254",
"subnet_mask": "255.255.255.0"
},
{
"fqdn": "",
"name": "vcf-vi01-nsx01c",
"ip_address": "192.168.32.79",
"gateway": "192.168.32.254",
"subnet_mask": "255.255.255.0"
}]
}Upload the JSON configuration file for the NSX deployment and the NSX installation package to SDDC Manager. You need to remember the path where you uploaded this configuration file, as you will need it later.
ls /home/vcf/vcfimport/
ls /nfs/vmware/vcf/nfs-mount/bundle/
In fact, when performing NSX deployment, if the physical resources are not very sufficient, we can also deploy only 1 NSX Manager appliance, which was not mentioned when performing the Convert, the following method should also be applicable, if necessary, you can refer to the following steps. Of course, the above JSON configuration file still needs to be fully configured with 3 NSX Manager devices, if it is not fully configured, then none of the later checks will pass.
Connect to SDDC Manager via SSH and switch to the root user, and use the following command to edit the system configuration file:
vim /etc/vmware/vcf/domainmanager/Add the following and save:
=1
=mediumRestart the service.
systemctl restart domainmanager
V. Formal implementation of the introduction process
Log in to SDDC Manager via vcf user SSH, go to the vcf-brownfield-toolset directory, and use the following command to perform the vSphere environment import process. After running the command, enter the admin user password for SDDC Manager and the root and SSO user passwords for vCenter Server for authentication.
python3 vcf_brownfield.py import --vcenter --sso-user administrator@ --domain-name vcf-vi01 --nsx-deployment-spec-path /home/vcf/vcfimport/
Enter YES to start the Import process.
Log in to the SDDC Manager UI to track task status.
After the task has been running for a while, it fails again when deploying NSX ....... The reason is that the physical host's CPU load is too high causing one of the virtual ESXi hosts in the management domain to get stuck, and it just so happens that the SDDC Manager VM is on it, see this (Use esxtop to kill stuck and unresponsive VMs in ESXi hosts.) Article!
After the management domain ESXi hosts got stuck, the SDDC Manager VM performed an HA switchover, and once all services were running normally, restarting the failed task through the SDDC Manager UI was sufficient, as the import task for the existing vSphere environment had already been completed, as shown in the following figure.
In the end, the mission was carried out successfully in its entirety.
After the task is completed, switch to the root user, restart all services of SDDC Manager, and reinitialize the UI.
Validating imported VI domains
Navigating to the SDDC Manager UI->Inventory->Workload Domains, you can see that the existing vSphere environment has been imported as a VI domain, and the name of the VI domain is the name we set when we imported, vcf-vi01.
Click into the VI domain to view summary information for that workload domain.
In the Hosts and Clusters tab, you can see configuration information for ESXi hosts and clusters that are part of a vSphere environment.
Perform a little environment pre-check to see if all components and configurations are in order.
In the distribution view, there are now two workload domains in VCF version 5.2.
Under the Image Management view, there are now two available images.
In network settings view, view the network pool configuration information for the VI domain.
During an import check of an existing vSphere environment, the VCF management domain was redeployed due to an unknown error, so at that time, the vCenter Server VMs from the existing vSphere environment were migrated to its own cluster via cross vCenter vMotion. The ESXi 4 hosts are now disconnected due to high physical resource load causing them to seize.
Existing vSphere environment information, now a VI domain vCenter Server, VM inventory contains vCenter Server VMs and 1 NSX Manager VM.
The vCenter Server VM is in an existing vSphere cluster, so the NSX Manager VM is deployed to the same location.
Log in to the NSX Manager UI (VIP) of the VI domain to view the NSX system configuration overview.
NSX cluster configuration, an NSX management cluster with only one NSX Manager node.
The VI domain vCenter Server has been added to NSX as a Compute Manager.
Hosts in a VI domain cluster have NSX configured with Distributed Virtual Port Groups (DVPG).
The VI Domain Management component is on the DFW exclusion list.
