I was recently asked if there is a way to remove a bundle that has been already downloaded by the SDDC Manager. Most of the time, there is little need to do this. However, there are times when it can be helpful – like if you are using a VCF environment to teach others how to perform tasks like downloading VCF bundles manually. Let’s take a look at how you would do this.Continue reading Deleting Bundles from VCF
After getting your external access up and running, I’m sure your ready to start deploying some additional solutions! Let’s start with the vRealize suite and that all begins with downloading and deploying VRSLCM – (vRealize Suite Lifecycle Manager). Go ahead and get that queued up and downloading, it’s about 3GB in size and it should be available under the Repository -> Bundles page, click the Download Now button next to the vRealize Suite Lifecycle Manager bundle.Continue reading VLC-Build it for me, VRSLCM deployment– VCF 3.9.1
VMware Cloud Foundation (VCF) communicates periodically through the internet with a hosted web service in order to check for and retrieve software updates and bundles. What if you don’t have internet access? Today, I’m going to demonstrate how you can build out your own software repository for VCF.
Before we begin, it’s important to note that this process is not supported for production environments. To understand why, I need to give you a short overview of what I will be showing you today.Continue reading Make a Local VCF Depot
So you got through all the BGP fun and have a fully deployed VCF instance, congrats! Of course now, you want do add some functionality and get your FULL SDDC on. Thankfully, there are only a few more steps to go and you’re already an expert at this.
The long and short of it is that SDDC manager will need access to https://depot.vmware.com. That means you’ll need outbound network connectivity and DNS resolution. Let’s talk about the outbound network connectivity first.Continue reading VLC – Build it for me, External Access
I’ve talked about how to use hosts that have multiple physical NICs to create NSX-V and NSX-T backed workload domains and even how to expand a cluster in one of these workload domains. But what if you want to do an initial installation of VMware Cloud Foundation (VCF) using hosts with multiple physical NICs?
As I’ve mentioned before, the support for multiple physical NICs with VCF is new with VCF 3.9.1. All of the operations we performed previously relied on the VCF API. This worked well for our intended use, but bringup is a different animal.Continue reading VCF Bringup with Multiple Physical NICs
Last week, I shared an example of how to create a new workload domain with VMware Cloud Foundation (VCF) using hosts with more than two physical NICs. In that example, I used NSX-V in the creation of the workload domain. Today, I’d like to provide an example of how you would do this for a NSX-T backed workload domain.
As support for multiple physical NICs (>2) is a newly supported feature with the VCF 3.9.1 release, doing this requires the use of the VCF APIs.Continue reading NSX-T Backed Workload Domains with Multiple Physical NICs
With the VCF 3.9.1 release, support for hosts with multiple physical NICs has been added. This allows you to dedicate specific traffic across specific physical NICs to conform to your best practices. Let’s take a quick look at how this is configured…
By default, VCF will use the first two physical NICs (vmnic0 and vmnic1) on a host for all traffic. When working with a host with multiple physical NICs, you will need to define what the physical NICs are connected to (VDS or N-VDS). The VDS or N-VDS will need to exist, of course.Continue reading Multiple Physical NICs in VCF
Although VMware Cloud Foundation (VCF) will automatically download the software bundles once connected to the Internet, there are times that you may wish to manually inject the software bundles into the SDDC Manager using the API.
After the initial deployment of VCF is completed, additional bundles may be required to enable optional functionality. For example, the bundles for Horizon, PKS, and vRealize Automation are optional and would be downloaded and then installed as needed. Because these bundles can be quite large and VCF downloads them in a serial fashion, it can be faster at times to inject the bundles into VCF manually through the API.Continue reading Manually Uploading VCF Bundles
One of the users of the VLC (VCF Lab Constructor) had an issue with drive space when attempting to upgrade from VCF 3.9 -> 3.9.1. This has been a problem in previous releases at times as well, so I thought it’d be a good opportunity to post about it. That and I don’t post nearly as often as I want to!
SDDC Manager uses LVM for several of it’s critical mount points. Coupled with the EXT4 filesystem this allows those mounts to be very flexible and non-disruptive when increasing their size.Continue reading Resizing the LCM Volume group on SDDC Manager
So, you have adopted VMware Cloud Foundation (VCF), or maybe you have spent some time reviewing the VMware Validated Design (VVD) and found that you would like to deploy a Single SSO domain. In VVD architecture they propose having two regions with a Single SSO Domain, but natively the VCF deployment process expects a greenfield SSO domain.
As of VCF 3.8 release notes:
Provides the ability to link between the SSOs (PSCs) of two or more VMware Cloud Foundation instances so that the management and the VI workload domains are visible in each of the instances.
What does this mean exactly? This translates into the ability for Region B as per the VVD, to join the SSO instance of Region A. This allows VCF to align to the VVD from a design perspective to share SSO domains where it makes sense based upon Enhanced Linked Mode 150ms RTT limitation. In order facilitate this, the Excel Document Deploy Parameters tab, has been updated (shown below) and allows you to enter Region A SSO domain, PSC IP Address, and SSO Credentials. During bringup process on Cloud Builder it will still deploy two PSC’s for that region, but they will be joined to Region A. This will provide Enhanced Linked Mode in vCenter and allow you to manage two VCF environments Role Based Access Controls and VM’s from a single login.
The ability to join SSO domains does come with some limitations though:
- VCF can only join an SSO domain of another VCF instance. The first VCF deployed in your environment still needs to be greenfield.
- ELM limitations of 15 vCenters applies, and that is now shared between two VCF instances. This means instead of a VCF instance being allowed to have 14 Workload Domains plus Management. Only 13 workload domains could be created in a shared deployment as minimum of two would be used for management.
- ELM limitation of 150ms Round Trip Time for latency should be advised, this would mean sharing SSO domain between New York and Sydney will likely not be supported or advised.
- Patches need to stay consistent especially for PSC’s and vCenters between deployments. Patch all PSC in both VCF instances before patching vCenters, and then subsequently patch all vCenters in a timely manner.
- SDDC Manager in ‘Region A’ cannot see the Workload Domains created by the SDDC Manager in ‘Region B’. We are looking to address this in the future.
- NSX-T cannot be shared between ‘Region A’ and ‘Region B’ deployments.
This is great news for customers that are looking to align their VCF environments with the best practices in VVD and also allow for a unified vCenter support experience for their Admins. In addition this will allow for easier migrations on Day X as they will reside in the same vSphere Client, potentially as easy as a drag and drop to Region B depending upon networking and overall customer architecture.