After upgrading vCenter to version 8 I wanted to use vLCM (“Single Image”) instead of baselines (VUM) to upgrade my ESXi hosts.
However, NSX integrates directly with vLCM to push the NSX VIBs. Since my cluster previously used baselines for its updates, and not vLCM, I wasn’t sure what would happen with the already-installed NSX components.
Luckily, it went (relatively) smooth.
NSX Configuration
VMware has some information on the subject already, but as we all know, the docs don’t always reflect reality and (at least in my opinion) sometimes leave something to be desired, especially when things don’t go as smoothly (“it works in the PowerPoint!”) as the docs expect.
The NSX Installation guide has the following prerequisites:
- Ensure all hosts in a cluster are running ESXi 7.0 U1 version.
- Register Compute Manager with the following settings:
- Enable Trust and set access level to vSphere Lifecycle Manager. Trust is mandatory to establish communication between NSX and vSphere Lifecycle Manager.
- Enable Create Service Account.
- Prepare the cluster by applying a Transport Node Profile (using VDS as the host switch type) to the cluster.
So, make sure that’s the case:

Additionally, make sure that you’ve configured to use a VDS, and not an N-VDS, but I’m hoping that’s not the case anymore since it’s a dated configuration anyway.
Then, make sure that you’ve applied a Transport Node Profile to the entire cluster, as this is how configure a vLCM cluster with NSX if you’re doing it vLCM first, NSX second.

If that’s all configured properly, we can go to vCenter to configure our image.
vCenter Configuration
This is where the KB article takes a bit of a shortcut, and just says ‘go do this’. But not really how, or what to expect.
In vCenter, select your cluster and go to the ‘Updates’ tab, and then select ‘Image’. Here you’ll be presented with the option to manage your cluster with a single image, and how you want to obtain/configure that image.
For some reason, vCenter wouldn’t ingest the existing image, giving me an error that seemed to be unrelated to NSX. Additionally, I’d prefer to setup an image manually from scratch, so that it’s “clean” (probably doesn’t make much difference, it just feels right).
Looking at the ESXi hosts, I saw that vLCM has discovered the NSX component, labelled “NSX LCP Bundle”- specifically version NSX LCP Bundle(4.2.1.0.0-7.0.24302014). However it would not let me select this in the ‘custom components’ part of the image builder:

I even tried uploading the NSX VMkernel modules into the Lifecycle Manager depot, but to no avail. It wouldn’t show up at all, even though it had the exact same name and version and everything. I wasn’t able to find any specifics either, whether or not I have to provide this, or ingest it from an existing image. Very frustrating.
KB Article to the rescue
Giving this a rest, I opted to do some other clusters first.
Then, when configuring a different cluster, with different components and no NSX, I saw a reference to a KB article which provided some necessary information:

This KB article shows us that the message regarding the following components, if found by vLCM and marked as to be removed when remediating, can be ignored:

So, crossing my fingers, I pressed ‘Finish Image Setup’.
Panic!
And then I saw some tasks pop up in vCenter:

‘Apply NSX Solution’! And it failed! Oh no!
This caused some mild terror!
Luckily I had seen something like this before: it’s just vCenter’s way of communicating with NSX and the ESXi hosts to verify that the solution is enabled, and if it is already applied to the cluster, this task doesn’t necessarily do anything. Something along these lines has existed since NSX-V. Double checking to be sure: the datapath was not affected. Phew.
The error message makes sense as well; the image applied is a newer version than we’re currently using, as I’m upgrading my ESXi version.
So far so good, right?
It gets better! Looking at the image configuration on the cluster now, we can see that NSX has successfully conveyed to vLCM that the solution is applied, and should be included as a component:

And in NSX we can now also see the ‘vLCM’ flag applied to the cluster:

Onward!
Good to see that enabling vLCM, even with NSX enabled, is possible without doing some heavy manipulation! I have enabled it in the past, just never with NSX in the cluster. Any action that has cluster-wide consequences is always something that requires the utmost care. So I had to make sure I had all the information, which proved a bit difficult.
Hope this provides some real-world experience to anyone who is facing the same task.
Thanks for reading!
The original article was posted on: significant-bit.com