Getting started with VMware Cloud Foundation (VCF) 4.0

On March 10th, VMware announced a range of new updated products and features. One of these was VMware Cloud Foundation (VCF) version 4.0. In the following series of blogs, I am going to show you the steps to deploy VCF 4.0. We will begin with the deployment of a Management Domain. Once this is complete, we will commission some additional hosts and build our first workload domain (WLD). After that, we will deploy the latest version of NSX-T Edge Cluster to our Workload Domain. The great news here is that this part has now been automated in VCF 4.0. Finally, with this in place we will go ahead and deploy vSphere with Kubernetes, formerly known as Project Pacific. So let’s being with a deployment of the Management Domain.

Note that VCF 4.0 is for greenfield deployments only. It is not a version that can be upgraded to from earlier versions of VCF 3.x. Customers who wish to upgrade to VCF 4 will be able to do so when an updated version of VCF 4.x is made available. This is currently being worked on.

Disclaimer: “To be clear, this post is based on a pre-GA version of the VMware Cloud Foundation 4.0. While the assumption is that not much should change between the time of writing and when the product becomes generally available, I want readers to be aware that feature behaviour and the user interface could still change before then.”

Cloud Builder

Those of you already familiar with VCF will be aware that we use Cloud Builder to bring up the Management Domain and the SDDC Manager. I wrote about the VCF 3.9 bringup here. Not much has changed in that overall process in VCF 4.0. You still populate the spreadsheet or a JSON file with the various infrastructure related information, such as hostnames, IP addresses,  VLAN info, licenses, etc. However the management domain has changed. The major change is that we have now moved from NSX-V to NSX-T. Therefore as part of the bring-up process, the Management Domain will now have a 3-node NSX-T cluster deployment included.

Another major change compared to VCF 3.9 is that there is no automated deployment of vRealize Log Insight in the Management Domain in 4.0. Instead, customers will have to deploy the vRealize Suite Lifecycle Manager (vRSLCM) after the bring-up has complete, and rollout the desired vRealize products, e.g. vRealize Operation, vRealize Automation and vRealize Log Insight as mentioned previously.

There is another big difference between VCF 3.9.1 and VCF 4.0 as well. In VCF 3.9.1, we introduced the concept of NSX Application Virtual Networks (AVN), which meant that vRealize components would be deployed on these networks rather than a traditional VLAN. In VCF 4.0, the use of AVNs becomes optional. Therefore you can deploy vRealize components on AVNs or on traditional VLANs – the choice is yours. Other than that, many requirements remain much the same. You still require 4 ESXi nodes for the Management Domain, and a 4 node vSAN cluster is still created, albeit we now use vSAN 7 in VCF 4.0.

Once the spreadsheet or JSON file is populated and the Cloud Builder Appliance is deployed, we can being to roll out the Management Domain. Point a browser to the appliance, login, and you are presented with an option to deploy either VCF natively or VCF on VxRail. I’m going to go with the first option:

Next is your list of prerequisites. Read them carefully and make sure everything is in place.

We now come to the point of uploading the spreadsheet/JSON which we populated with all of our configuration information for the Management Domain. I had comments in the past about why are we still using a spreadsheet/JSON for this. Surprisingly enough, this is what our VCF customers are asking us for. It takes a while to populate this, when you consider you probably need to involve the network team to help, and maybe a speak to a procurement team for the license information. In fact, we went with a UI approach back in VCF 2.x, and our customers asked us to keep the spreadsheet/JSON method. If you have any thoughts on this approach, please leave me a comment. Anyway, on with the deployment:.

After uploading the completed spreadsheet/JSON, the validation commences. If there are any warnings thrown, and this could be for a number of reasons, you will need to acknowledge that warnings were found before continuing with the deployment. In my case, I had some devices formatted with VMFS on the hosts, as well as some NTP configuration issues. I would strongly urge anyone deploying VCF to make sure that all warnings are addressed before continuing with the deployment.

And off we go with the actual deployment. I have captured the tasks which show that NSX-T is now being rolled out in the Management Domain during the initial bring-up.

Which will eventuality complete and present you with the following window to launch SDDC Manager. At this point, we have a 4 x node vSAN 7 cluster, managed by vCenter Server 7.0, with NSX-T.next managers and SDDC Manager for VCF 4.0 deployed. All hosts will be automatically configured as Transport Nodes in NSX-T, with both an Overlay Transport Zone and VLAN Transport Zone.

And if I launch the SDDC Manager, I can login and start thinking about commissioning hosts, building new workload domains and indeed how easy it is to deploy a solution such as Kubernetes on vSphere (formerly known as Project Pacific) which is fully integrated with VCF 4.0. I’ll be showing you how to do that in some upcoming blog posts.

One final word on the inclusion of NSX-T in both the management domain and workload domain. NSX-T will now become the default pod networking solution in the Kubernetes on vSphere Supervisor cluster, as well as playing a significant role for north-south traffic in VMware Tanzu Kubernetes Grid, the guest Kubernetes clusters that can be provisioned on Kubernetes on vSphere. It will offer network switching, routing, firewalls, NAT, load balancers, and more. As we get more into this series of posts, the benefits of this integration will become more and more apparent.

To learn more about VMware Cloud Foundation 4, check out the complete VCF 4 Announcement here. To learn more about vSAN 7 features, check out the complete vSAN 7 Announcement here.

26 Replies to “Getting started with VMware Cloud Foundation (VCF) 4.0”

  1. Hi Cormac,

    I have a question, As you mentioned – Another major change compared to VCF 3.9 is that there is no automated deployment of vRealize suite, So customer has to deploy vRealize suite using vRSLCM manually. All products of vRealize suite need to deploy using vRSCLM and VCF SDDC manager cannot deploy automatically in VCF 4.0 ?

    As in 3.9 we used to deploy from SSDC Manager – vRealise suite and deploy the product.

    1. That is correct – manual deployment in vRSLCM in VCF 4.0. Automation of vRealize components should appear again in a future release. The focus of VCF 4.0 was vSphere with Kubernetes.

  2. Hi Cormac
    Quick question if I may, just preempting release Notes, does VCF 4 also follow the Standard or Consolidated Architecture Models similar to previous versions?

    1. Hi Simon,

      At launch time, my understanding is that it will only follow the standard architecture model. The discussion around the consolidated architecture is still on-going.

      If you have a particular need/use-case for the consolidated approach, I’d love to hear about it.

      1. Hi Cormac
        We did have particular needs/use-cases for the consolidated model as per VCF 3.9.1, is it possible I could contact you directly to discuss it please?

      2. Hi Cormac,

        Our use case in particular is for our partner demo lab, where we need to demonstrate projects, but do not require the capacity for a production environment

        1. Thank you Matthew – good to know. We’re still evaluating consolidated VCF 4.0. Once we have a decision (either way), I’ll post an update.

  3. Hi Comac,

    Thanks for sharing the details.

    Would like to clarify few details, regarding license – Is it possible to continue with evaluation license ? Hope the workload domain construct would be possible only with valid license ?
    In pre-requisite i have seen that the BGP peering section is optional however during deployment it failed due to the BGP peering. Do we have any option to skip and do the peering manually ?

    1. On the license question, can you elaborate? Do you mean do testing with an eval license, and then apply a full license later, and everything should still work? Do you plan to apply the full license before or after the eval license has expired?

      On the BGP question, you’ll see from my write-ups that I simply went ahead and selected static routes, and it deployed without issue. I see no issue with enabling BGP afterwards, as these are fully fledged NSX-T Edge Clusters. It just means a bit more work for you later on I guess.

  4. Hi Cormac,
    Where does the VTEP gateways reside ?? whether on existing DLF or separate hardware, as in previous versions the GW was residing on a separate hardware ….appreciate your assistance

    1. I assume this is in the context of vSphere with Kubernetes?

      Anyway, the NSX-T Edges get deployed onto the Workload Domain.

      The NSX-T Managers get deployed onto the Management Domain.

  5. Hi Cormac,

    We would like to upgrade our LAB VCF to 4.0 (fresh install).
    Since we have only 4 nodes for the mgmt domain: to demonstrate Kubernetes integration can we enable workload management manually in vCenter (using the eval licenses) or is this somehow blocked?

    BR Johannes

    1. Hi Johannes,

      We are currently waiting on official approval for deploying ‘vSphere with Kubernetes’ on the VCF 4.0 Management Domain. We are also waiting on some guidance/documentation as there may be some additional undocumented steps needed in NSX-T to allow the NSX-T Edge to be identified on the Management domain by the Workload Management task. I’m hoping to have clarification this week.

      Cormac

      1. Hi Cormac,

        Any news on the official approval?

        I did the VCF 4.0 install this week, everything works fine.
        When trying to enable Kubernetes on the MGMT domain manually (via vCenter), the cluster is incompatible. When digging further into why it is not compatible, I get the following via dcli on VCSA:

        Command> dcli com vmware vcenter namespacemanagement clustercompatibility list
        |———|———-|—————————————————————————————-|
        |cluster |compatible|incompatibility_reasons |
        |———|———-|—————————————————————————————-|
        |domain-c8|False |Failed to list all distributed switches in vCenter a19ea0a8-35b5-4365-8ab9-7ab0bc18ca4b.|
        | | |Cluster domain-c8 is missing compatible NSX-T VDS. |
        |———|———-|—————————————————————————————-|

        The funny thing is: all Kubernetes and NSX-T requirements are fulfilled and DVS 7.0 is used.
        So it must be something “internal”.

        BR Johannes

        1. You need to ‘Enable Trust’ between the NSX-T and vCenter Server. This can be found if you edit the Compute Manager in NSX-T, and turn on ‘Enable Trust’ for your vCenter Server. I’ll document the complete steps once support is announced.

  6. Hello Cormac,

    Been a huge fan of yours for a long time. Amazing posts and very helpful. I’ve got a couple of queries, please see if you can help me with some direction for these. I have a customer waiting on this.

    When can we expect multi-site guidance on VCF 4 to be released? I heard it is sometime end of May 2020 but want to see if you have a date/timeline.
    Will NSX-T 3.0 Federation be added to VCF support? (This I think relates to the question above)

    If things delay I’ll have to force myself to design on 3.9.1 for the customer I have right now. That brings some challenges as NSX-T migration coordinator doesn’t support cross-vc NSX-v migrations + vRealize Automation is still 7.6 in 3.9.1. Of course customer has to wait till next release of VCF 4.x to be able to upgrade.

    Pardha.

    1. Thanks for the kind words Pardha. I’ll share what I can.

      By multi-site, I guess you mean the Multi-Instance Management feature of VCF? i.e. the ability to manage multiple VCF deployments via a single SDDC Manager? We have some Federation today, but it is read-only (view health, etc) and is limited to 5 instances. We do have plans to enhance this feature in VCF to include actual configuration changes, and so on, but I don’t have any dates to share on when it will be available.

      NSX-T 3.0 Federation is something that we are also keen to include in VCF, and have it work side-by-side with MIM, but again there are no dates that I can share.

      My gut feel is that maybe 3.9.1 is the way to go for your customer, and then perhaps upgrade later on. However at this point I cannot say for sure when these features will be in the product.

    2. Pardha, would it be ok to reach out to you over email to talk through your customer’s requirement a bit more?

    1. Do you mean installing both management and workload domain on same hosts? This is something I will publish once we support it.

  7. hi, is there any specific license for SDDC manager?if we have seperate license for VSPHERE7,VSAN7,NSXT and vrealize suite8.1 then is this possible to run VCF4.0 without any further license or no?

    1. Hi Ali,

      Yes – an SDDC Manager License is also required. I think it might be worth having a conversation with your local VMware Business Development Manager, who can give additional advice on how to trial VCF 4.0 with your current suite of products.

      Can you let me know which region you are in, and I can have someone reach out to you (if you are ok with that)?

      1. Thank you for replying,we are in USA, because i couldnt find any specific license for only SDDC Manager 4.0

Comments are closed.