9.1 Understanding the Network Group and Virtual Bridge Objects

9.1.1 Virtual Bridge Object

In the Cloud Manager Orchestration Server, 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, the server 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.


A Virtual LAN (VLAN) provides a “logical” LAN topology for a group of machines that does not need 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 need 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, the Orchestration Server 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. The server can track a VLAN ID for each Network object to allow correct management of individual VLANs as full-fledged networks.

The server 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 manually.

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 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 a “network” in the Orchestration Console. 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 Orchestration Console

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 Orchestration Console 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 Orchestration Console main menu, select Actions > Create > 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, specify the name you want to use to identify this vBridge. The data you enter here is completely free form. When the Orchestration Server 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, Virtual Bridge Info/Groups Tab.

  8. Click the Save button to save the fact changes you have made.

Deleting a Virtual Bridge

Although it is 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. In the Orchestration Console main menu, select Actions > Delete > 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 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 Orchestration Server 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.

The object’s display name is visible in the Orchestration Console, the Cloud Manager Web Console and Mobile Clients interfaces, and in optional zos and zosadmin commands. As the number 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.

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 Orchestration Console by 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, select the vBridge object .displayname fact and then open the Fact Editor to enter a new value for that fact.

As you use one of these methods, you will notice that the fact value is prepopulated 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 NetIQ Cloud Manager 2.1.5 Orchestration Server Command Line Reference.