Loading

×Sorry to interrupt
This page has an error. You might just need to refresh it.
[NoErrorObjectAvailable] Uncaught ReferenceError: addCTracking is not defined
Failing descriptor: {markup://c:KM_ArticleThemeLayout}

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Unable to update Transport Node Profile on ESXi Transport Node if VMs are running on that host (77123)

Last Updated: 2/18/2020Categories: TroubleshootingTotal Views: 10842Language:
English

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

Symptoms

Updates to ESXi Host Transport Node and Transport Node Profile attached to a host with powered on VMs fail with the error: "The host has powered on VMs which must be moved or powered off before transport node create/update/delete can continue"

Updates to an ESXi host Transport Node (TN) will fail if it has VMK migration specified and there are any powered-on VMs on that ESXi host.

Updates to a Transport Node Profile (TNP) attached to such TNs will fail regardless of the VMK migration setting on the TNP.

Cause

This issue is caused because powered-on VMs cause the migration validation to fail, preventing updates to the TN or TNP.

Resolution

Currently, there is no resolution.

Workaround

There are multiple scenarios to workaround this issue:

Scenario 1:

You have a TNP attached to the compute cluster and you are able to put either all the hosts in that compute cluster or one host at a time into maintenance mode.

Follow these steps:

In vCenter server: Put all the hosts or one host in the cluster into maintenance mode.

In NSX Manager: Edit the TNP configuration and apply to the compute cluster as follows:

From System > Fabric > Profiles > Transport Node Profiles, select the TNP and click Edit. Make your changes and click Save.
Note: If you are updating one host at a time, updated TNP configurations will succeed on the host which is in maintenance mode but will fail on other hosts that are not in maintenance mode. This is an expected behaviour.

From System > Fabric > Host Transport Node, select the cluster attached to this TNP and click Configure NSX. The TNP should be selected in the dialog box that appears. Click Save to apply the TNP edits to the cluster.

In vCenter server: Take the hosts, or the one host you edited, in the cluster out of maintenance mode.

Only required if you are updating one host at a time: Repeat steps 1 through 3 for each additional host in the cluster that has not been put into maintenance mode. When you reapply the TNP configuration on the cluster, you will still see errors regarding powered on VMs even for hosts already edited that you brought out of maintenance mode. You can ignore these errors.  If you do not want to see these errors, detach the TNP from the cluster. 

Scenario 2:

You have not attached a TNP to the compute cluster and you are able to put the ESXi host TN in maintenance mode.

Follow the steps:

In vCenter Server: Go to the ESXi host with powered-on VMs and put it in maintenance mode.

In NSX Manager: Update that ESXi host transport node and apply the changes as follows:

From System > Fabric > Host Transport Node, select the transport node and click Configure NSX.

On the Install NSX wizard, click Next to the Configure NSX screen. Make the required edits and click Finish.

In vCenter Server: Take the ESXi host out of maintenance mode.

Scenario 3:

You are not able to put any hosts in maintenance mode.

Follow these steps:

If you are using Transport Node Profile, detach the Transport Node Profile from compute cluster that contains Transport Node that you want to update. Detaching the Transport Node Profile from compute cluster will not change configurations already applied to any host in the cluster.

For each TN that you want to update, remove the VMK install mapping. This allows bypassing the migration validation that requires the host to have no powered-on VMs.  VMKs that   have already migrated to N-VDS are not affected by this change. After the update, do not add back the VMK install-mapping to the TN, to prevent this issue from recurring.

Navigate to System > Fabric > Nodes >  Host Transport Nodes.

Select the TN you want to update and click "Configure NSX".

In the NSX Installation wizard, click "Next" to go to the Configure NSX step.

Scroll down to the section that shows "Network Mappings for Install" and remove the existing mappings.

Click "Finish".

Edit the TN configuration as required.

Note: If the NSX-T hostswitch (N-VDS) was configured with "Network Mappings for Install" (that are removed now as part of this workaround), do not enable the "PNIC only Migration" flag. To migrate PNICS that are not currently in use, add these PNICs as uplinks to the PNICs list in the Configure NSX screen of the NSX Installation wizard. If the PNICs are currently in use by VSS/DVS, first free them up with

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

KB
•
コンテンツ ライブラリから複数の仮想マシンをデプロイすると、ユーザー インターフェイスに別の vCenter Server のカスタム仕様が表示される (77172)

KB
•
提供 Horizon Cloud Service on Microsoft Azure 的 Microsoft Azure 区域 (77121)

KB
•
vCloud Director 10.0 に仮想マシンの監視チャートが表示されない (77055)

Results 1-3 of 3

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware NSX Transformers

Related Versions:

VMware NSX Transformers 2.x

Take Our Survey

Support Assistant