Preparing to upgrade BNA blueprints, containers, and rogue switches

This section describes the prerequisites that you must perform before you upgrade BMC Network Automation blueprints, containers, and rogue switches to version 3.1. In this section, the following topics are provided:

Upgrading pod and container blueprints

The XML schema for pod and container blueprints in BMC Cloud Lifecycle Managment version 3.1 contains significant differences from the previous version. Any blueprints that are in the BMC Network Automation database during the upgrade are automatically updated with the latest XML schema. Any pod and container blueprint files outside of the BMC Network Automation database will not be updated, and you will no longer be able to import those blueprint files.

If you are upgrading from BMC CLoud Lifecycle Management version 2.1 to version 3.1, BMC recommends that you perform the following procedure to upgrade your pod and container blueprints.

To upgrade pod and container blueprints:

Locate all pod and container blueprints that you want to be able to use in your upgraded environment.
Import all of those pod and container blueprints into BMC Cloud Lifecycle Management version 2.1.
Upgrade BMC Cloud Lifecycle Management to version 3.1. The XML schema for all blueprint files are updated.
Export the pod and container blueprints, if desired.

Upgrading network containers (remove multiple merge actions in a node)

Since multiple merge actions executed on the same container node to configure or unconfigure it now involve concatenation of the underlying templates involved, you should make sure that their templates do not contain unnecessary exit statements at the bottom which could interfere with this logic.

Upgrading rogue switches

The API methods in BMC Cloud Lifecycle Management version 3.1 for provisioning to a physical switch or rogue hypervisor switch are not usable for containers created in BMC Cloud Lifecycle Management version 2.x, which have been upgraded version 3.1.

Click for upgrading rogue switches detail

In BMC Cloud Lifecycle Management version 2.x, there was a vanilla node to represent physical switch and there was no node at all for the rogue hypervisor switch. In order for the new API methods to work for upgraded containers, you must morph the vanilla nodes to physical access switches and create hypervisor access switch nodes (encapsulating a null device).

The rogue hypervisor server switch nodes need to be populated with attach points that reference an appropriate nic segment. The nic segment needs to have an appropriate networkName, and reference the appropriate VLAN and address pool for the servers being provisioned. The pod level and container level switch nodes need to be populated in all necessary pod/container instances.

Upgrade Mechanism

You can re-use the existing pod/container import mechanism to populate the switch node information in all the necessary pod/container instances.

The populateRogueServers attribute

A new attribute has been introduced in pod/container import xml to support populating switch nodes. If set to true, the pod/container import mechanism morphs the vanilla nodes to physical access switches (as specified in the xml) and create the hypervisor switches (as specified in the xml) in necessary pod/container instances.

Populating switch nodes in pod

The switch nodes in the pod can be populated by importing a subset of pod xml which includes NIC segment (network segment the port types are part of in the hypervisor switch), physical switch, and hypervisor switch (with port types) information. An example of the xml is shown below.

Example pod xml

<?xml version="1.0" encoding="UTF-8" ?>
<bbnaData>
    <version>
		<build>0</build>
		<lastUpgrader>94</lastUpgrader>
		<maint>2</maint>
		<major>8</major>
		<minor>2</minor>
		<patch>0</patch>
    </version>
	<pod populateRogueServers="true" reacquireAddresses="false">
		<!-- Put the name of your pod -->
		<name>samplepod</name>
		<!-- nic segment the port types are part of in hypervisor switch -->
		<nicSegments>
			<nicSegment>
				<name>Management Network 1</name>
				<networkName>Management Network 1</networkName>
				<addressPoolName>Management Addresses</addressPoolName>
				<vlanName>Management VLAN</vlanName>
			</nicSegment>
		</nicSegments>
		<nodes>
		    <!-- This node represents the existing node whose physical access flag is true -->
			<node xsi:type="podPhysicalSwitch" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
				<balancedParams />
				<containerCount>1</containerCount>
				<!-- Put proper value of the BNA device representing the switch-->
				<device>PhysicalSwitch</device>
				<!-- This name should match the name of the existing pod node whose physicalAccessFlag is true-->
				<name>PhysicalSwitch</name>
				<params />
				<role>PhysicalSwitch</role>
				<!-- Put the proper port names -->
				<portNames>
					<portName>fa0/1</portName>
					<portName>fa0/2</portName>
				</portNames>
			</node>
			<!-- This node represents the new rogue hypervisor node -->
			<node xsi:type="podHypervisorSwitch" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
				<balancedParams/>
				<containerCount>1</containerCount>
				<name>AccessSwitch2</name>
				<params/>
				<role>AccessSwitch2</role>
				<hypervisorContext>hyp-l</hypervisorContext>
				<portTypes>
					<portType>
						<enabledFlag>true</enabledFlag>
						<name>Management Port Type</name>
						<nicSegmentName>Management Network 1</nicSegmentName>
						<nameWithinSwitch>ManagementPortType</nameWithinSwitch>
					</portType>
				</portTypes>
			</node>
		</nodes>
    </pod>
</bbnaData>

Populating switch nodes in container

The switch nodes in the container can be populated by importing a subset of container xml which includes NIC segment (network segment the port types are part of in the hypervisor switch), physical switch, and hypervisor switch (with port types) information. An example of the xml is shown below.

Example container xml

<?xml version="1.0" encoding="UTF-8" ?>
<bbnaData>
	<version>
		<build>0</build>
		<lastUpgrader>6</lastUpgrader>
		<maint>2</maint>
		<major>8</major>
		<minor>2</minor>
		<patch>0</patch>
    </version>
    <container reacquireAddresses="false" populateRogueServers="true">
		<!-- Put the name of your container -->
		<name>samplecontainer</name>
		<!-- nic segment the port types are part of in hypervisor switch -->
		<nicSegments>
			<nicSegment>
				<name>Customer Network 1</name>
				<networkName>Customer Network 1</networkName>
				<addressPoolName>Customer Addresses</addressPoolName>
				<vlanName>Customer VLAN</vlanName>
				<enabledFlag>true</enabledFlag>
				<lockedFlag>true</lockedFlag>
			</nicSegment>
		</nicSegments>
		<nodes>
			<!-- This node represents the existing node whose pod node physical access flag is true -->
			<node xsi:type="containerPhysicalSwitch" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
				<name>PhysicalSwitch</name>
				<ports />
			</node>
			<!-- This node represents the new rogue hypervisor node -->
			<node xsi:type="containerHypervisorSwitch" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
				<acquiredAddresses/>
				<configureActionInfos/>
				<hostedFlag>true</hostedFlag>
				<name>AccessSwitch2</name>
				<numVrfs>0</numVrfs>
				<podNodeName>AccessSwitch2</podNodeName>
				<role>AccessSwitch2</role>
				<state>3</state>
				<portTypes>
					<portType>
						<enabledFlag>true</enabledFlag>
						<name>Custom Port Type</name>
						<nicSegmentName>Customer Network 1</nicSegmentName>
						<nameWithinSwitch>samplecontainer.CustomerPortType1</nameWithinSwitch>
					</portType>
				</portTypes>
				<ports/>
				<unconfigureActionInfos/>
			</node>
		</nodes>
	</container>
  </bbnaData>

Where to go next

Performing the upgrade