Last week VMware announced the availability of VMware Cloud Foundation (VCF) 3.0. In this release a lot has changed in relation to the older 2.3 release. Not only in the available feature set but also in the physical architecture and initial bring up procedure. For a complete overview of the new features, the release notes can be found here.
This blog post will focus on maybe the biggest change, the support for customer’s own network vendor and topology choice.
Prior to VCF 3.0, the physical and logical network components where managed by VCF. VCF was responsible for the entire life-cycle management of the physical and logical network components. All the physical network components where configured and managed by VCF from the initial bring-up. This meant that the choice in network topology and vendor was very restrictive because of the extended validation process.
In VCF 3.0 it is now possible to use your own preferred network topology and vendor. Gone are the strict port wiring and specific switch hardware type requirements. This also means that VCF will no longer manage the physical network components. Configuration of these components needs to be done outside of the life-cycle management of VCF, either manually or automated.
The change to support other network topologies and vendor also lifts certain restrictions of the logical network configuration. Prior to VCF 3.0, the logical network configuration had some requirements around the use of specific VLAN ID’s and size of the subnets. All those restrictions are gone. There are still recommendations but no mandatory items.
Prior to VCF 3.0, VCF would be responsible for the naming of all the components such as the ESXi hosts, vCenter Servers, and NSX Managers. This also meant that the SDDC Manager would be authorative for a specific DNS sub-zone in the customers DNS environment. If multiple VCF environments where deployed, each deployment would use its own DNS sub-zone.
With VCF 3.0, the SDDC Manager is no longer an authoritative DNS server for a specific sub-zone. The existing DNS environment of the customer is used. This makes it also mandatory to manually specify the name of all the components, and to create all the required DNS records. DNS forward and reverse name resolution of all the components must be possible before a deployment can start.
Prior to VCF 3.0, VCF would use an internal IPAM service to assign IP addresses to all of the VMkernel interfaces of the ESXi hosts.
With VCF 3.0 this has changed for the VTEP VMkernel interfaces. IP addresses for the VTEP VMkernel interfaces are now assigned by an external DHCP server. All other VMkernel interfaces such as the management and vMotion interfaces are still configured with the internal IPAM service.
As you can see the ability to use a customer’s own network vendor and topology choice has a significant impact on the design. Therefore, at this moment there is no upgrade path available to VCF 3.0. Customers on a version prior to VCF 3.0 need to wait for an upgrade path to be available or deploy a new VCF environment.
The changes in the network design also has an impact on the initial bring-up of the VCF environment. In VCF 3.0 a new streamlined method for Cloud Foundation deployment and initial bring-up has been introduced using the Cloud Foundation Builder VM. A new blogpost coming soon will explain the differences in the deployment and initial bring-up.