【VMware VCF】使用 VCF Import Tool 将现有 vSphere 环境导入为 VI 域。 ...

VCF Import Tool 工具使用两种方式来资助客户将现有的 vSphere 或 vSphere + vSAN 环境转变为 VMware Cloud Foundation 环境，分别是转换（Convert）和导入（Import）。之前在这篇（使用 VCF Import Tool 将现有 vSphere 环境转换为管理域。）文章中演示了将现有 vSphere 环境转换为 VCF 解决方案中管理工作负载域的过程，因此这篇文章接着这个主题，看看如何使用这个工具将现有 vSphere 环境导入为 VCF 解决方案中的 VI 工作负载域。

 
一、使用要求和限定

请注意，使用 VCF Import Tool 工具实行导入（Import）过程与之前的转换（Convert）过程具有相同的要求和限定，因此请参考之前文章（使用 VCF Import Tool 将现有 vSphere 环境转换为管理域。）中的说明，这里不再赘述。
使用要求和限定中有一条是，现有 vSphere 环境的 vCenter Server 假造机要么位于自身的集群内要么运行在 VCF 管理域集群上，当在实行导入（Import）任务的同时进行 NSX 方案的部署，则会出现两种不同的情况：

• 假如 vCenter Server 假造机运行在自身 vSphere 集群内，当实行导入任务并同时部署 NSX 方案，则 NSX Manager 假造机将部署到 vSphere 集群内。
  
• 假如 vCenter Server 假造机运行在 VCF 管理域集群上，当实行导入任务并同时部署 NSX 方案，则 NSX Manager 假造机将部署到 VCF 管理域集群上。
  

 
二、现有 vSphere 环境

针对 VCF Import Tool 工具使用的各种要求和限定，同样必要对现有 vSphere 环境的信息进行查抄确认。本次用于导入（Import）的现有 vSphere 环境如下图所示，一个由 3 主机所组成的 vSAN ESA 标准集群，关于具体查抄过程这里就略过了，详细请参看之前文章。

当前 vSphere 环境的 vCenter Server 假造机运行在 VCF 管理域集群上（注意，后面有调解）。

 
三、实行导入前预查抄

在对现有 vSphere 环境实行导入（Import）操作之前，必要在 SDDC Manager 上实行一次预查抄，确定当前 vSphere 环境是否满足导入为 VI 域的要求。由于之前在进行转换（Convert）时，已经将 VCF Import Tool 工具包上传至 SDDC Manager 了，所以这里无需进行上传。通过 SSH 以 vcf 用户连接到 SDDC Manager 的下令行，使用以下下令进入到 vcf-brownfield-toolset 目录。

1. cd /home/vcf/vcfimport/vcf-brownfield-import-5.2.0.0-24108578/vcf-brownfield-toolset/

复制代码

进入目录后，使用以下下令在 SDDC Manager 上实行环境查抄。总共有 83 个内容，成功查抄 82 个，失败 0 个，内部错误 1 个。

1. python3 vcf_brownfield.py check --vcenter vcf-vi01-vcsa01.mulab.local --sso-user administrator@vsphere.local --sso-password Vcf520@password

复制代码

根据查抄输出的结果，查看具体错误的内容，Compatibility validation 项查抄错误，如下所示。

1. An error occurred when validating VMware Cloud Foundation compatibility: File with Compatibility Matrix Content for Compatibility controller VMWARE_COMPAT is not found.

复制代码

这个错误必须要解决，否则后面无法继承。一开始的时候，我不停以为是 vSAN HCL 文件有题目导致的，经过各种尝试和验证，还把之前转换的管理域给清除了，重新部署了 VCF 管理域环境，结果这个错误始终无法得到修复。然后后面才反应过来，它这个错误指的是“Compatibility Matrix”兼容性数据文件无法验证，这是一个专门针对的 VCF 的兼容性矩阵数据，跟 vSAN 那个 HCL 数据库文件有点雷同但不一样，也就是这个数据现在缺失了无法进行验证，所以有这个内部错误。实在，你也可以在 SDDC Manager UI 下图中的地方看到这个错误提示，不管是通过转换（Convert）过来的管理域还是使用 Cloud Builder 部署的管理域，这个 VCF 兼容性数据默认都没有，我们必要手动下载并进行更新。

如何手动下载并进行更新 VCF 兼容性数据文件，也就是这个“Compatibility Matrix”文件，可以参考这篇《Offline Download of VMware Cloud Foundation 5.2 Upgrade Bundles》产物文档。整个流程大概是，你必要使用 Bundle Transfer Utility 工具下载这个“Compatibility Matrix”兼容性数据文件，然后再使用这个工具将兼容性数据文件更新到 VCF 中。
对于这个工具，可以到 Broadcom 支持流派（BSP）去下载，我已经将这个工具和“Compatibility Matrix”兼容性数据文件上传到了这个百度网盘链接（https://pan.baidu.com/s/1lUbrN0zjLUUC1oB8L7ZRAg?pwd=lvx9）中，有必要可以去下载。下面我将演示如何去下载这个兼容性数据文件并将其更新到 SDDC Manager 中。
假如 VCF 环境可以连接互联网，那可以直接使用这个工具在 SDDC Manager 上实行下载和更新过程，但要是不能联网的话，你可以找一台能够连接互联网的 Linux 主机，然后在这个主机上再使用工具去下载兼容性数据文件（VmwareCompatibilityData.json），下载之后生存到当地，将文件上传到内网环境的 SDDC Manager 上，再使用这个工具完成更新。注意，下载这个兼容性数据文件必要具有 Broadcom 支持流派（BSP）的账号，没有 VCF 权限仅普通用户权限也可以进行下载。
将 Bundle Transfer Utility 工具上传到具有互联网连接的 Linux 主机上，解压后并赋予 lcm-bundle-transfer-util 工具实行权限，然后使用以下下令下载“Compatibility Matrix”兼容性数据文件。

1. ./lcm-bundle-transfer-util --download --compatibilityMatrix --depotUser xxxxxxxx@163.com

复制代码

获取到 VCF 兼容性数据文件后，将该文件以及 Bundle Transfer Utility 工具一并上传到 VCF 管理域的 SDDC Manager 上，使用以下下令解压该工具并调解权限。

1. mkdir /opt/vmware/vcf/lcm/lcm-tools
2. cd /opt/vmware/vcf/lcm/
3. tar -xvf lcm-tools-prod.tar.gz
4. chown vcf_lcm:vcf -R lcm-tools
5. chmod 750 -R lcm-tools

复制代码

进入到工具所在的目录，使用以下下令完成 VCF 兼容性数据的更新，请注意下令中“inputDirectory”选项所使用的目录位置。

1. ./lcm-bundle-transfer-util --update --compatibilityMatrix --inputDirectory /home/vcf/ --sddcMgrFqdn vcf-mgmt01-sddc01.mulab.local --sddcMgrUser administrator@vsphere.local

复制代码

完成对“Compatibility Matrix”兼容性数据的更新之后，再次使用以下下令实行环境查抄，现在所有查抄都已成功。

1. python3 vcf_brownfield.py check --vcenter vcf-vi01-vcsa01.mulab.local --sso-user administrator@vsphere.local --sso-password Vcf520@password

复制代码

 
四、准备 NSX Manager

在进行转换（Convert）时，我们同时实行了 NSX 的部署，在进行导入（Import）时，同样可以一起实行 NSX 的部署。这一步骤是可选操作，你可以在实行导入过程的同时实行 NSX 的部署，也可以在实行导入结束之后，在其他时间再实行 NSX 的部署，只必要使用 --skip-nsx-deployment 选项跳过就行。以下是实行 NSX 部署所需的 JSON 配置文件。

1. {
2.   "license_key": "AAAAA-BBBBB-CCCCC-DDDDD-EEEEE",
3.   "form_factor": "medium",
4.   "admin_password": "Vcf520@password",
5.   "install_bundle_path": "/nfs/vmware/vcf/nfs-mount/bundle/bundle-124941.zip",
6.   "cluster_ip": "192.168.32.76",
7.   "cluster_fqdn": "vcf-vi01-nsx01.mulab.local",
8.   "manager_specs": [{
9.     "fqdn": "vcf-vi01-nsx01a.mulab.local",
10.     "name": "vcf-vi01-nsx01a",
11.     "ip_address": "192.168.32.77",
12.     "gateway": "192.168.32.254",
13.     "subnet_mask": "255.255.255.0"
14.   },
15.   {
16.     "fqdn": "vcf-vi01-nsx01b.mulab.local",
17.     "name": "vcf-vi01-nsx01b",
18.     "ip_address": "192.168.32.78",
19.     "gateway": "192.168.32.254",
20.     "subnet_mask": "255.255.255.0"
21.   },
22.   {
23.     "fqdn": "vcf-vi01-nsx01c.mulab.local",
24.     "name": "vcf-vi01-nsx01c",
25.     "ip_address": "192.168.32.79",
26.     "gateway": "192.168.32.254",
27.     "subnet_mask": "255.255.255.0"
28.   }]
29. }

复制代码

将 NSX 部署的 JSON 配置文件以及 NSX 的安装包上传到 SDDC Manager 中，必要记着这个配置文件上传的路径，后面必要用到。

1. ls /home/vcf/vcfimport/
2. ls /nfs/vmware/vcf/nfs-mount/bundle/

复制代码

实在，在实行 NSX 部署时，假如物理资源不是很富足的话，我们也可以只部署 1 个 NSX Manager 装备，之前在实行转换（Convert）的时候没有说，以下方法应该也同样适用，有必要的可以参考以下步骤。当然，上面的 JSON 配置文件还是必要配置完备的 3 个 NSX Manager 装备，假如不完备，那后面的查抄都过不了。
通过 SSH 连接到 SDDC Manager 并切换到 root 用户，使用以下下令编辑系统配置文件：

1. vim /etc/vmware/vcf/domainmanager/application-prod.properties

复制代码

添加以下内容并生存：

1. nsxt.manager.cluster.size=1
2. nsxt.manager.formfactor=medium

复制代码

重新启动服务。

1. systemctl restart domainmanager

复制代码

 
五、正式实行导入过程

通过 vcf 用户 SSH 登录到 SDDC Manager，进入到 vcf-brownfield-toolset 目录，使用以下下令实行 vSphere 环境导入过程。运行下令后，输入 SDDC Manager 的 admin 用户密码以及 vCenter Server 的 root 和 SSO 用户密码进行验证。

1. python3 vcf_brownfield.py import --vcenter vcf-vi01-vcsa01.mulab.local --sso-user administrator@vsphere.local --domain-name vcf-vi01 --nsx-deployment-spec-path /home/vcf/vcfimport/vcf520-import-nsx.json

复制代码

输入 YES 开始导入（Import）过程。

登录 SDDC Manager UI 跟踪任务状态。

任务实行一段时间后，在部署 NSX 的时候又失败了......。原因是物理主机的 CPU 负载过高导致管理域的一台假造 ESXi 主机卡死了，刚好 SDDC Manager 假造机也在这上面，看这篇（使用 esxtop 杀死 ESXi 主机中卡死和不响应的假造机。）文章！

管理域 ESXi 主机卡死后，SDDC Manager 假造机进行了 HA 切换，等所有服务都运行正常后，通过 SDDC Manager UI 重新启动失败的任务就可以了，因为现有 vSphere 环境的导入任务已经完成了，如下图所示。

最终，任务全部实行成功。

任务完成后，切换到 root 用户，重新启动一下 SDDC Manager 的所有服务，并使 UI 重新进行初始化。

 
六、验证已导入的 VI 域

导航到 SDDC Manager UI->清单->工作负载域，可以看到现有 vSphere 环境已经被导入为 VI 域，VI 域的名称为我们导入时设置的名称 vcf-vi01。

点击进入 VI 域，查看该工作负载域的择要信息。

在主机和集群选项卡中，可以看到属于 vSphere 环境中的 ESXi 主机和集群配置信息。

实行一下环境预查抄，查看各个组件和配置是否都正常。

在发行版本视图下，VCF 5.2 版本中现在具有两个工作负载域。 

在映像管理视图下，现在具有两个可用的映像。

在网络设置视图下，查看 VI 域的网络池配置信息。

在对现有 vSphere 环境进行导入查抄时，由于不知道错误的原因，VCF 管理域被重新部署了，所以其时将现有 vSphere 环境的 vCenter Server 假造机通过跨 vCenter vMotion 迁移到了自身的集群上。由于物理资源负载过高导致 ESXi 4 主机卡死，所以现在是断开状态。

现有 vSphere 环境信息，现在是 VI 域 vCenter Server，假造机清单包含 vCenter Server 假造机和 1 个 NSX Manager 假造机。

vCenter Server 假造机在现有 vSphere 集群中，所以 NSX Manager 假造机被部署到了相同的位置。

登录 VI 域的 NSX Manager UI（VIP），查看 NSX 系统配置概览。

NSX 集群配置，只有一个 NSX Manager 节点的 NSX 管理集群。

VI 域 vCenter Server 已作为盘算管理器被添加到 NSX 当中。

VI 域集群中的主机已配置了分布式假造端口组（DVPG）的 NSX。

VI 域管理组件在 DFW 排除列表中。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。