Converging VMware vSphere to VMware Cloud Foundation 9.0: The Top 10 Questions Answered

Transitioning your VMware vSphere environment to VMware Cloud Foundation (VCF) is a strategic move that shifts your infrastructure from a collection of managed silos to a unified private cloud. 

In my recent webinar with Brent Douglas where we dove deep into the converge process, the turnout was massive. Below are the Top 10 “must-know” questions submitted by the audience, complete with the detailed answers you need to navigate your move from vSphere to VCF with confidence.

Question 1: What are the differences between converting and importing vSphere Environments to VCF?

There were several questions that came in surrounding the differences between when and why you would convert versus import environments. So let’s look at each of these in more depth.

Converting:

• This is used when you do not have an existing VCF fleet deployed or want to deploy an additional VCF Management Domain into a new or existing fleet.
• The VMware vCenter instance, including ALL clusters, is converted to a single management workload domain.
• Existing configurations have precise requirements.

Importing:

• This is used when you have an existing fleet and want to add an existing vCenter instance as a VI workload domain.
• The vCenter instance, including ALL clusters in that instance, are imported as an additional VI workload domain. 
• Existing configurations have less stringent requirements.
  

Here are some additional considerations for performing a conversion versus an import:

• VCF currently has a limit of 24 VI workload domains per VCF instance. If you have a need for more than 24 workload domains, you will need to either deploy a new instance or perform a conversion of another vCenter server so that you can expand the capacity of the environment. 
• Environment or regional boundaries may dictate a division of resources, and a VCF Management Domain may be desirable to manage workload domains along these or other boundaries.

Sometimes business requirements dictate additional factors, such as DMZ requirements which can mandate boundaries for workload domains versus new instances of VCF.

Question 2: I have an environment that is vSphere x.x. What are the version requirements for converging? 

This question and variants of it were by far the most common questions that came in during the webinar. Requirements for both converting and importing your environment are specifically documented for reference. 

There are two basic things which are important in determining your path. The first is whether VMware NSX is involved or not. The second is what version of VCF are you planning on importing/converting to.

Note: NSX (previously VMware NSX-T) is a REQUIRED component of VCF, and therefore if you do not have it deployed it will be deployed as a part of the process. VMware NSX-V is not supported. If it is still used, it must be upgraded to a supported version of NSX-T before it can be upgraded to VCF 9.

For converting:

• If you are aiming to convert to VCF 9.0.0, NSX is not supported when converting so it must be deployed new. The minimum version of vCenter and VMware ESX is 9.0.0, as these components have to be upgraded prior to being able to run a conversion.
• If you are aiming to deploy VCF 9.0.1 or 9.0.2 without NSX, the minimum version of vCenter and ESX is 9.0.1 or 9.0.2 as these components have to be upgraded prior to being able to run a conversion.
• If you are using NSX, you must be deploying VCF 9.0.1 or VCF 9.0.2. The minimum supported version is vCenter 8.0 Update 3, ESX 8.0 Update 1, and NSX 4.2.1.
• If you are on any previous version of vCenter, ESX, or NSX, you should upgrade these using existing processes to the above versions as they are the minimum to be able to convert into VCF 9.

For Importing:

• The minimum version of VCF is 9.0.x to be able to import a vCenter as a workload domain.
• ESX and vCenter should be on version 8.0 Update 1 or later.
• NSX should be on 4.1.0.2 or later.
• If you are on any previous version of vCenter, ESX, or NSX, you should upgrade these using existing processes to the above versions as they are the minimum to be able to import into VCF 9.

Question 3: How did you create your lab environment? I have seen some of William Lam’s Blogs on the topic and wanted to see your process.

I love this question. I have worked with William Lam for many years on various initiatives. His blogs on creating lab environments are amazing. I highly recommend them as a starting point if you need some assistance. 

For my lab I was constrained with the available equipment that I have access to. I do not have physical hardware, so I used a nested configuration in one of our Broadcom private cloud labs.  

I started by configuring the environment using a VyOS VM for the router and configured it with all the required subnets, VLANs, BGP, and NAT configurations to support the VCF deployment. I also configured a Microsoft server to host my AD, DNS, DHCP, Certificate Authority, SFTP and NTP configurations. 

I then deployed 8 ESX host VMs with moderate sized CPU/RAM requirements and drives for vSAN storage. The minimum number of hosts is 4 for a basic management domain conversion. I deployed 4 additional host VMs to be able to do a workload domain import as well.  Finally, I deployed the VCF installer VM to perform deployments or conversions, and went through the wizard correcting any issues during the prerequisites run.  I have done this in every release of VCF since VCF 3.x was released, so I know it works and is reliable.

Question 4: Are vSphere LCM images required?  How can I convert from vSphere LCM baselines?  Are there any gotchas to this process?

VCF 9 does not support vSphere LCM baselines, and thus before you can upgrade to VCF 9 you must transition to images. That being said, don’t be scared, in my humble opinion they are WAY better than baselines. If you are already running VCF 5.x you must transition the environment. If you’re running standalone vSphere you can go to the cluster and specify the image using one of the existing hosts as the image.

The biggest advantage here is that you can add custom drivers, firmware, and vendor addons to the images that are being used and manage it at the cluster level. For example, you can specify drivers for Fiber Channel cards in the image configuration. This makes management of clusters of hosts a lot simpler in the long run.

Question 5: What are the storage options for VCF 9?

This is a common question. In previous versions of VCF, VMware vSAN was a requirement for the VCF Management Domain. For additional VI Workload Domains, that requirement is more relaxed.  

In VCF 9, additional storage configurations are supported for principal storage including vSAN, Fiber Channel, and NFS. Many other configurations are supported for supplemental storage.

Question 6: Does the import or convert process require downtime for running VMs?

The import and convert processes require minimal downtime to the running VMs. These processes mainly deploy and configure any missing components to the environment. 

If you are upgrading or remediating a configuration to be able to import or convert, you can use Maintenance Mode, VMware Distributed Resources Scheduler, and VMware vMotion to migrate the end workloads while these events are happening. 

Obviously, the component that is being upgraded will need to have down time and that should be managed appropriately. Every environment is different though, so I highly recommend doing testing in the environment to make sure you have all use cases covered.

Question 7: How does licensing work in VCF 9?

There were many questions on licensing in VCF 9. Unlike previous versions, licensing has been centralized in VMware Cloud Foundation Operations. The old 25 character product keys are replaced by a term-based subscription for a product with a specific number of cores. The cores are then allocated appropriately through the VCF business services console and configured in VCF Operations instances using either online or offline methods of assigning licenses.  

Question 8: For my existing environment, if I use Enhanced Linked Mode is it true that I have to break it before converting/importing?

Yes, this is true. Enhanced Linked Mode (ELM) is no longer supported in VCF 9. If you have already upgraded from VCF 5.x to VCF 9, ELM must be deactivated. If you’re running vSphere, ELM must also be deactivated before you import or convert. VCF Operations takes over the functions which were provided by ELM.

Question 9: What activities take the most time when importing or converting to VCF 9?

This is a complicated question, as every environment is unique. There are some common things which I can point to that delay projects:

• Not understanding the requirements and prerequisites for converting, importing and upgrading to VCF 9.  Most of the problems can be traced back to a prerequisite not being completed or an issue not being remediated. In the same way a slow network connection can cause delays in downloading a binary, a prerequisite that has not been met can delay a converge process until it is addressed. 
• Validation that host hardware is compatible with VCF9 is of absolute importance, as failures may occur as a result of this.
• Upgrades take time. If you are not on the appropriate software versions, you may need to do multi-hop upgrades to get to VCF 9. 
• Lack of experience with VCF 9. Training and lab experience are important for successful outcomes. The deployment process has changed since VCF 5.x due to the new VCF installer workflows. There are many cases where even experienced administrators run into things that are unique to VCF 9 that they have not seen before.

Question 10: After you have imported or converted to VCF 9, will PowerShell scripts against the vCenter and ESX hosts still work or will they need modifications?

In general, most PowerShell scripts will still work unless a function is no longer available in VCF 9. I highly recommend testing any scripts to validate that they still work as expected. 

That being said, depending on what the PowerShell script is used for, it may be a good idea to investigate whether the functions can be done in a better or more efficient way with VCF. For example, VCF has built-in certificate and password management for all components. If you are manually replacing certificates or passwords via a PowerShell script, it may be more efficient to do that through VCF Operations instead. Also, if you use scripted provisioning operations in your environment, the script should be examined. VCF has significant provisioning automation which can optimize your scripts so that you are not just deploying hosts, but entire workload domains.

On-Demand Replay

If you missed the webinar, you can read the highlights or watch the replay below. Discussion and demo timestamps are provided if you would like to jump directly to specific sections.

Need help?

Converging vSphere to VCF 9 requires careful planning and execution for a successful transition. If you need assistance with your transition, VCF Professional Services can help. Contact your account director for more information.