9.1 Understanding the Network Group and Virtual Bridge Objects

9.1.1 The Virtual Bridge Object

In PlateSpin Orchestrate, a group of Virtual Bridge (vBridge) objects is called a Network. It represents the networks (actually, LANs and VLANs) that are available to that VM host, and can be shared across multiple VM hosts. Network groups are created automatically during VM and VM host discovery as their virtual networking settings are determined. By default, PlateSpin Orchestrate automatically groups vBridges with the same name into a corresponding Network with the same name, assuming that vBridges with similar names usually refer to the same Network. After discovery, you can freely reassign the vBridges to other Networks or multiple Networks, depending on your organization’s physical network topology.

The VLAN Fact

A Virtual LAN (VLAN) provides a “logical” LAN topology for a group of machines that does not have to depend on the switch hardware to which the machines (virtual or physical) are directly connected. Modern “smart” network switches can keep track of a “VLAN ID” on network traffic passing though them. Using this ID, the switches transparently route such traffic to the hosts configured to use the VLAN specified by the ID.

Using VLANs can reduce the costs of an organization’s physical network infrastructure. For example, if your organization requires multiple subnets or multi-homed hosts, you won’t have to buy new equipment for each new subnet or install multiple physical NICs on the physical machines; this can be done with VLANs using the same common physical network layer. VLANs allow greater flexibility in managing the network topology.

Where possible, PlateSpin Orchestrate discovers that a VLAN ID is in use on a network. The Virtual LAN Identifier fact is found on a Network object :

<fact name="group.vlanid" value="" type="String" />

The fact is populated with a positive integers value upon discovery of an already-existing VM host configuration. PlateSpin Orchestrate can track a VLAN ID for each network object to allow correct management of individual VLANs as full-fledged networks.

PlateSpin Orchestrate applies a graphic overlay to the Network icon to signify that the Network was discovered as a VLAN. In cases where VLAN discovery is not accomplished through automation, you can also set the VLAN fact value by hand.

9.1.2 The Purpose of the Virtual Bridge

The vBridge is discovered, along with its associated VM, when a discovery job runs on a VM host. A virtual bridge (vBridge) acts as a “virtual” Ethernet segment contained entirely within the software of a VM host. The virtual NIC (vNIC) devices on that host’s VMs can each be assigned to one of the VM host’s vBridges as if they were being physically connected to a LAN.

Virtual bridges can also be associated with one or more physical NICs to combine the virtual LANs on these hosts into one common virtual LAN. This combined LAN is referred to as as a “Network” in PlateSpin Orchestrate. Association of virtual bridges is also frequently done to include a “virtual” LAN on a VM host in the organization’s overall physical LAN topology so the VMs can access other systems in the organization as if they were directly connected to the switches.

The following points might help you understand the relationship of these objects:

  • Associating a vNIC to a vBridge is like plugging a physical NIC into an Ethernet switch.

  • Associating a vBridge with a physical NIC is like connecting two physical switches together using their uplink ports.

  • A vBridge can become part of a vLAN by associating it with a physical NIC device that itself is configured as a VLAN.

  • A VM host can have multiple vBridges, each of which can be connected to separate physical networks (for example, through 802.1Q VLAN tagging).

  • When a VM is provisioned, a Virtual NIC must be connected to a Virtual Bridge in order for the Virtual NIC to be usable.

In the Explorer Tree, a vBridge is given the form vmhostname_ethn where n represents the numerical order in which this vBridge was discovered on the VM host, with 0 being appended to the name of the first vBridge discovered or created. For example, host1_eth0 might be the name of the first bridge. Each additional vBridge is incremented by one, so the second vBridge in this example would be named host1_eth1.

9.1.3 Creating or Deleting a vBridge in the Development Client

This section includes the following information:

Creating a Virtual Bridge

You might want to manually create a vBridge if, for some reason, the discovery process did not find one of the vBridges in a network. Creating a new vBridge in the Development Client does not “add” a physical bridge to the network, it only helps to model a physical bridge that was not previously discovered.

To create a vBridge, you can select the Network object in the Explorer tree, then right-click and select New Virtual Bridge. You can also use the following alternate method:

  1. From the PlateSpin Development Client, select Actions > Create Virtual Bridge to display the Create a New Virtual Bridge dialog box.

  2. In the Source Groups list, select the Network object where you want to add a vBridge, then click Add to move it to the Target Groups list.

  3. In the New Virtual Bridge Name field, enter the name you want to use to identify this vBridge. The data you enter here is completely free form. When PlateSpin Orchestrate discovers and names vBridges, it associates them by name as the default practice. This is done for convenience in locating the objects. A vBridge can be named anything, provided that it is a legal name for a vBridge on the VM host’s operating system.

    It is not necessary to add the <vmhostname>_ prefix on the name. This prefix is automatically prepended when the new object is created. For example, if you select bridge name sales on VM host vmh1, the actual object is created as vmh1_sales.

  4. Click Create, then click Close.

  5. In the Explorer tree, expand the Network group where you created the new vBridge object.

  6. Select the new vBridge object to open its Info/Groups admin view.

  7. Configure the settings described in Section 9.2.1, The Virtual Bridge Info/Groups Tab.

  8. Click the save icon to save the fact changes you have made.

Deleting a Virtual Bridge

Although uncommon, you might want to manually delete a vBridge when you no longer want the VM to have access to a specified network on the VM host. For example, if the initial need for connecting the VM to a network no longer exists or the network is going to become private and the VM should not have access you would delete the vBridge that allows connectivity.

To delete a Virtual Bridge, you can select the vBridge object in the Explorer tree, then right-click and select Delete, or you can use the following procedure:

  1. From the PlateSpin Development Client, select Actions> Delete Virtual Bridge to display the Create a New Virtual Bridge dialog box.

  2. In the Source Objects list, select the name of the vBridge (hold down the Ctrl key to select multiple), then click Add to move these objects to the Delete Targets list.

  3. When you have selected all of the vBridges you want to delete, click Delete to display the Delete query dialog box.

  4. In the dialog box, select Apply to all to delete all of the vBridge objects in the Delete Targets list, click OK, then click Close.

9.1.4 Virtual Bridge Object Naming and Renaming

Some resource names are generated by the Orchestrate system and can therefore receive generic, arbitrary names such as host1-eth1, host2-eth1, and so on. A Virtual Bridge (vBridge) you name at creation time might also change later in its purpose or facilities.

As the quantity of these vBridge objects grows in your grid, you might find it helpful or necessary to rename them, assigning more meaningful, intuitive names to suit the purpose of the object. The object’s “display name” is visible in the Development Client interface, the VM Client interface, the Server Portal, and in optional zos and zosadmin commands.

NOTE:A Network object (that is, the group that contains these vBridge objects) can also be renamed. Objects such as jobs, events, and users cannot be renamed.

A vBridge object’s name is stored in the ${objectType}.displayname fact, which exists on every Grid object type, even those objects that cannot be renamed.

You can rename a vBridge object in the Orchestrate Development Client using one of three methods:

  • Right-click the vBridge object in the Explorer tree, then select Rename to allow editing of the display name.

  • Triple-click the vBridge object in the Explorer tree to allow editing of the display name.

  • In the Constraints/Facts page, where you can select the vBridge object .displayname fact and then open the Fact Editor to enter a new value for that fact.

As you begin to rename using one of these methods, you will notice that the fact value is pre-populated with the ${objectType}.id fact. This functions as the name value for the object name until you decide to change it.

NOTE:Even after being renamed, the vBridge object retains its associated resource ID in the .id fact. This is not editable.

For more information about making the Resource object display names visible from the zos or zosadmin command line, see the PlateSpin Orchestrate 2.5 Command Line Reference.