This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
Cloud Lifecycle Management
Cloud Lifecycle Management
Cloud Lifecycle Management 4.x
Here are the multiple scenarios in which the switchport error can come:
Scenario 1: Provisioning fails with error Verify that the specified switchport exists between the network and virtual cluster
If the Service offering is configured with two networks and the networks are not shared across cluster. In such scenario, the selection of Compute pools would be random and there is a possibility of network is picked from a different node and compute pool picks a different cluster:
Provisioning would fail with error:
"cloudClass" : "com.bmc.cloud.model.beans.CloudError",
"errorAction" : "Verify that the specified switchport exists between the network and virtual cluster.",
"errorCause" : "Error occurred while selecting switch port for network interface number  between network and virtual cluster. Either the switch or the Network Policy did not match. Please Check if Network Policy is applied correctly.",
Other error message can be: [Error selecting switch port for Network Interface : 0. Either the switch or the Network Policy did not match. Please Check if Network Policy is applied correctly.]
Scenario 2: While on-boarding a VM using Quickstart, it is failing with error - VM onboarding is failing due to error "SwitchPort is NOT associated to either Container or POD"
Snippet from CSM log:
13 Jan 2017 10:39:45,132 [ERROR] TASK - [Thread=90c6ee36-1d3b-4407-af5e-75dabd5b0e93::c34e35d0-638d-4f32-a3c0-e432e607c840::c4eafd18-9b77-42fb-91e7-0a7a4aa54aea(266)] [Class=ErrorAction:execute] - Adding TaskError with errorid  message [SwitchPort: <SwitchPort Name> is NOT associated to either Container: <Container Name> or POD : <POD Name> in Cloud DB.] errSev [CRITICAL]
Scenario 3: Existing VM onboarding fails with following error: Error creating Network Connector from BBNA: Could not get SwitchPort for NIC [null]
Snippet from the CSM log:
14 Mar 2016 11:38:43,250 [ERROR] TASK - [Thread=97efce67-1732-441b-bbda-3336ce29cdf1::97a47906-469e-4c20-a00a-8263c6905d78::c168602b-4806-4fe3-ba57-b36eb1ab45bb(177)] [Class=Jexl2Evaluator:eval] - Exception while evaluating expression [switchPortObj.getSwitchObject()]
org.apache.commons.jexl2.JexlException: com.bmc.cloud.task.scxml.jexl2.Jexl2Evaluator.getExpression@179![14,31]: 'switchPortObj.getSwitchObject();' attempting to call method on null
Scenario 4: VM onbaording fails with a error - Could not obtain network information from Cloud DB for switchport : ae0c4151-7450-4791-9bce-8c8564594c85
Trying to onboard new VMs through quickstart in CLM fails with an error:
[Error while onboarding service offering instance.] [Error creating Service Offering Instance with name dummy from SO <service offering name>.] [Error occurred while creating resource set <resource set name>.] [Error creating virtual compute container dummy.] [SwitchPort: <port name> is NOT associated to Switch : Access Switch name in Cloud DB.]
Missing switchport relationship with Network Container or duplicate records of switchport with missing relationships.
Solution for scenario#1:
Cause: Network is not shared across clusters and selection of compute is not filtered based on network selection
In CLM 4.x, check for the following property in providers.json file
If "checkNetworkClusterConnectivity" is set to false, then stop the Platform Manager service and set this value to "true" and start the Platform Manager service.
This would allow the compute pool selection tightly linked to the network selected and would not pick the compute pools where this network is not shared.
Note: Before performing the above steps, you can also perform the following steps:
- Open BMC_Cluster form and search for the cluster which is being selected before submitting the request or the one mentioned in the error message and click on the view relationships button at the bottom.
- Check the access switch (CLUSTERUSESSWITCH) from the relationship window, in case there are many, identify the one associated with the selected Cluster and Network Container.
- After selecting the Access Switch/dvSwitch, click on view related CI button and then click on view relationship on the newly opened form (BMC_ComputerSystem).
- Access Switch/dvSwitch will be having relationships with switchports (HOSTEDACCESSPOOINT).
- Identify the one associated to the selected Network Container.
- Open that record by clicking "VIew Related CI".
- BMC_ProtocolEnpoint form will be opened. Copy the name of the switchport and perform a search by filter "MarkAsDeleted" as "no" and name of the switchport (which you copied).
- We are expecting a single record but in case there are duplicate active records then check the valid one and delete the other.
Solution for scenario#2:
Cause: Missing relationship between SwitchPort and Network Container
1: Login to BNA UI and verify relationships between switchport and POD/ Network Container under
- Virtual Data Center -> Pods ->Pod Nodes
- Virtual Data Center -> Containers -> Nodes
2: In case, relationship between SwitchPort and Network Container is not found, follow below steps -
Open BMC_ConcreteCollection form and search the Network Container (with CloudClass = networkcontainer) whose relationship is missing with switchport
Copy the InstanceId and CMDBRowLevelSecurity attribute value as well
Open the BMC_LANEndpoint form and search for the switchport whose relationship is missing with network container
Click on "View Relationship" and select "BMC.CORE" from Namespace, "BMC_Dependecncy" from Relationship Class and click on "Create"
Replace "Name" attribute value with "CONTAINERUSESSWITCHPORT", provide DatasetId as BMC.ASSET and paste the "InstanceId" copied in point#3 in "Destination.InstanceId"
Switch to 'General" tab and paste CMDBRowLevelSecurity value which was copied from point#3
Switch to "Custom" tab and paste following attribute values:
- Switch to "Custom 2" tab and paste following attribute values:
- Source.CloudClass: switchport
- Save the record and try on-boarding the VM again
3: In case both Management and Customer network were configured at Container level. The nicSegmentName for both Tenant and Management Port Type were given the same name.
<description>Production Port Type 1</description>
<name>Production Port Type 1</name>
<nicSegmentName>Tenant Network 1</nicSegmentName>
<description>Management Port Type 1</description>
<name>Management Port Type 1</name>
<nicSegmentName>Tenant Network 1</nicSegmentName>
- Modify the Container blueprint and provide different value in nicSegmentName for Management and Customer.
- Save the Container blueprint with the different "Revision Number" and re-import it into BNA.
- Re-provision the Network Container as per the steps mentioned in CLM Documentation - Reprovisioning network containers
- Review the updated Network Container in BNA GUI->Network->Virtual Data Center->Containers for the changes.
Solution for scenario#3
Switchport objects gets created/populated if there is a match between the Mac Address available in BMC Server Automation for that server and the Mac Address configured in vCenter for the virtual machine settings.
Solution for scenario#4
Cause: Missing Network and Switchport relationship or having duplicate switchport records.
Open BMC_BaseElement form, in search mode, at Cloud DB.
Switch to "Custom 2" tab and type "switchport" for CloudClass and select "MarkAsDeleted" as "No" on General tab.
Select DatasetId as "BMC.ASSET" and type in the name of the switchport in "Name" field.
Click on "Search" button to perform a search
Multiple records may populate in search result in case there are duplicates in the system.
There could be multiple records in case same switchport name is being used across all the Network Container.
Check the external id of a record to identify the actual records:
External ID will help identifying the actual records as that record will have POD, Node and NIC segment details in following format:
62c78fe0-fd0f-44fd-b164-6fe8d7d582bf:AR-POD:Access Switch 1:WebNetwork
Verify the relationships of all the records from the search results.
Each "Switchport" record from the search result should have following relationships:
Relationship with "Network Container". Relationship name is "CONTAINERUSESSWITCHPORT".
Relationship with respective "Access Switch". Relationship name is "HOSTEDACCESSPOINT".
Relationship with "Network". Relationship name is "SWITCHPORTONNETWORK".
All above are mandatory but in case VM has been provisioned on these switchport then this configuration item (CI) will have a relationship with NIC and relationship name will be "INTERFACEUSESSWITCHPORT".
In case there are duplicate switchport records pointing to the same Network Container then keep the one which has got all above relationships.
If any one of them is missing then that records needs to be created manually by reviewing the similar relationships and collecting their attributes and its values.
Creating missing relationship will have almost similar steps mentioned in "scenario#2" but make sure to collect the actual values of missing relationships by referring to the same relationship available for the other configuration item (CI) but for the same Cloud Class.
Solution for scenario#5
- Verify the Switch port of VM from vCenter side and validate if this switch port exists in the POD/Container.
- It is a pre-requisite that the VM to be onboarded on a network (port group) is part of a network container that is already onboarded in CLM.
- Move the VM to the cluster that has the switch port already onboarded in CLM and redo the onboard VM activity to get past this error.
- Alternatively, if this is a new port group then reconfigure the POD and container to include the new port group so that a matching switch is found during onboard.
Contact BMC Support to verify the information in case it requires.
Refer How to Videos - Cloud Lifecycle Management playlist for how-to videos created by BMC Support.