What You See Is What You Get Element

Network Naming Best Practices for Oracle VM Server for x86

by Gregory King and Suzanne Zorn

Best-practice guidelines for naming networks in Oracle VM Server for x86, which can reduce errors as well as simplify maintenance and troubleshooting.


Published November 2013


Troubleshooting Oracle VM Server network configurations can be unnecessarily complicated by a poor choice of network names. In practice, cryptic or vague network names—such as "OVM GUEST Network 4" or "VM/VLAN"—make it difficult to understand how a network is configured or intended for use. This problem is exacerbated in large Oracle VM configurations that have many server pools, servers, and VLAN segments.

Want to comment on this article? Post the link on Facebook's OTN Garage page.  Have a similar article to share? Bring it up on Facebook or Twitter and let's discuss.

Choosing a consistent naming scheme with meaningful, descriptive network names can reduce the probability of errors by both new and seasoned administrators engaged in the management and troubleshooting of the Oracle VM environment. A well-designed naming scheme also reduces the time new systems administrators need to become proficient in day-to-day management of the Oracle VM environment.

This paper provides example naming schemes that can be used for configurations typical of large enterprise data centers.

Note: This article assumes you are familiar with basic Oracle VM Server for x86 concepts and terminology. For an overview, refer to the article "Looking 'Under the Hood' at Networking in Oracle VM Server for x86." Also see "Fundamental Concepts for VLAN Networks with Oracle VM Server for x86."

Creating and Managing Oracle VM Networks

Oracle VM Manager is used to create and manage networks in Oracle VM Server for x86. When you create a network, you specify the network function or role (for example, server management, cluster heartbeat, live migrate, storage, or virtual machine) and the building blocks for this network (physical Ethernet ports, network bonds, or VLAN segments). You also specify the network name and an optional network description (see Figure 1).

The Create Network form in Oracle VM Manager

Figure 1. The Create Network form in Oracle VM Manager.

When planning a network configuration, decide what information is most relevant and choose a naming convention that includes that information. For example, including information about the network channel (role), server pool, or VLAN segments that are used can greatly simplify network management.

Note: Oracle VM Manager doesn't require that network names be unique. However, it is highly recommended that you choose unique names for each network to eliminate the possibility for confusion. When you are assigning networks to a virtual machine using the Oracle VM Manager GUI, only the name field is displayed. Having multiple networks named "Guest NFS," even if their description field is unique, could easily result in the wrong configuration.

The following sections illustrate best-practice naming schemes for common enterprise network scenarios:

  • Hosting companies (multiple customers): Single data center, multiple server pools, servers configured with a single bond
  • Separate production, test, and development environments: Single data center, multiple server pools, servers configured with multiple bonds

Example 1: Hosting Companies (Multiple Customers)

Hosting companies commonly implement a networking solution that has multiple server pools, servers with a single network bond, and multiple VLANs to isolate customer traffic. Servers, such as Oracle's Sun Blade X3-2B (blade server) or Sun Server X3-2 (2U rackmount), are often configured with only two of the 10 Gb Ethernet interfaces bonded to reduce network cabling in the rack. Multiple server pools are created and dedicated to individual customers, with a limited number of servers in each server pool. Multiple VLANs are used to isolate the customers' network traffic from each other. For example, a hosting configuration might have 600 VLANs, with 2 or 3 VLANs dedicated to each customer.

Table 1 contains a suggested naming convention for Oracle VM networks in this scenario.

Table 1. Network Naming for Multiple Server Pools, Single Network Bond
Customer Network Name Network Description
ACME CUST1 pool MGMT bond0 v200 ACME Dom0: bond0 server mgmt, cluster heartbeat and live migrate for all Oracle VM servers belonging to customer1
CUST1-P1 Customer access eth0 v300 ACME DomU: Customer access to manage guest OS
CUST1-P1 NFS eth1 v301 ACME DomU: NFS and backup traffic
CUST1-P1 Private eth2 v302 ACME DomU: Private network for Oracle Real Application Clusters (Oracle RAC) and other app traffic
CUST1-P1 DMZ1 eth3 v303 ACME DomU: External public access to apps
CUST1-P2 Customer access eth0 v300 ACME DomU: Customer access to manage guest OS
CUST1-P2 NFS eth1 v304 ACME DomU: NFS and backup traffic
CUST1-P2 Private eth2 v305 ACME DomU: Private network for Oracle RAC and other app traffic
CUST1-P2 DMZ2 eth3 v306 ACME DomU: External public access to apps
RoadRunner, Inc CUST2 pool MGMT bond0 v400 RoadRunner Inc Dom0: bond0 server mgmt, cluster heartbeat and live migrate for all OVM servers belonging to customer2
CUST2-P1 Customer access eth0 v520 RoadRunner Inc DomU: Customer access to guest OS
CUST2-P1 NFS eth1 v521 RoadRunner Inc DomU: NFS and backup traffic
CUST2-P1 Private eth2 v522 RoadRunner Inc DomU: Private network for Oracle RAC and other app traffic
CUST2-P1 DMZ3 eth3 v523 RoadRunner Inc DomU: External public access to apps

This example assumes two customers: ACME and RoadRunner, Inc. VLANs 200 and 300–306 are allocated to the first customer (ACME). VLAN 200 is mapped to Dom0/bond0 and is used for server management, cluster heartbeat, and live migrate for all Oracle VM servers belonging to this customer (see shaded entry in Table 1). The remaining VLANs are mapped to various Ethernet ports (for example, eth1) on each individual Oracle VM Guest operating system and used for virtual machine communication. Similarly, VLANs 400 and 520–523 are allocated to the second customer (RoadRunner, Inc) and configured in the same way.

The network name identifies the customer and server pool, intended network usage, Ethernet port or bond, and VLAN. Having the Ethernet port as part of the name is important since this is displayed when selecting networks for the virtual machine when creating a new Oracle VM Guest; the description is not displayed when editing a newly created virtual machine. The description provides additional information, such as the full customer name and an expanded description of the intended usage. For example, the network name CUST1-P1 NFS eth1 v301 is easily recognized as a network allocated to customer 1's server pool 1, which is used for NFS, uses Ethernet port eth1, and is mapped to VLAN 301. The description field additionally provides the customer name (ACME) and notes that this network is also used for backup traffic.

Example 2: Separate Production, Test, and Development Environments

Large organizations often want to manage separate production, test, and development server pools using a single management environment. Multiple server pools are created and dedicated to production, test, and development. Multiple VLANs are used to isolate traffic from each area. This configuration provides the ability to promote virtual machines from a development server pool to a test pool, and then to a production pool.

Table 2 contains a suggested naming convention for an Oracle VM networks scenario that has a production server pool and a development server pool:

Table 2. Network Naming for Multiple Server Pools, Multiple Network Bonds
Function Network Name Network Description
Production PRD Pool 1 Dom0 SM bond0 v200 Pool1 production servers Dom0: server mgmt
PRD Pool 1 Dom0 HB bond1 v201 Pool1 production servers Dom0: cluster heartbeat
PRD Pool 1 Dom0 LM bond2 v202 Pool1 production servers Dom0: live migration
PRD Pool 1 DomU Pub eth0 v203 Pool1 production VMs DomU: eth0 Sys admin access to manage guest OS
PRD Pool 1 DomU NFS eth1 v204 Pool1 production VMs DomU: eth1 NFS and backup traffic
PRD Pool 1 DomU PRV eth2 v205 Pool1 production VMs DomU: eth2 Private network for Oracle RAC and other app traffic
PRD Pool 1 DomU DMZ eth3 v206 Pool1 production VMs DomU: eth3 External public access to apps
PRD Pool 2 Dom0 SM bond0 v210 Pool2 production servers Dom0: server mgmt
PRD Pool 2 Dom0 HB bond1 v211 Pool2 production servers Dom0: cluster heartbeat
PRD Pool 2 Dom0 LM bond2 v212 Pool2 production servers Dom0: live migration
PRD Pool 2 DomU Pub eth0 v213 Pool2 production VMs DomU: eth0 Sys admin access to manage guest OS
PRD Pool 2 DomU NFS eth1 v214 Pool2 production VMs DomU: eth1 NFS and backup traffic
PRD Pool 2 DomU PRV eth2 v215 Pool2 production VMs DomU: eth2 Private network for Oracle RAC and other app traffic
PRD Pool 2 DomU DMZ eth3 v216 Pool2 production VMs DomU: eth3 External public access to apps
Development DEV Pool 1 Dom0 SM bond0 v100 Pool1 dev servers Dom0: server mgmt
DEV Pool 1 Dom0 HB bond1 v101 Pool1 dev servers Dom0: cluster heartbeat
DEV Pool 1 Dom0 LM bond2 v102 Pool1 dev servers Dom0: live migration
PR DEV D Pool 1 DomU Pub eth0 v103 Pool1 dev VMs DomU: eth0 Sys admin access to manage guest OS
DEV Pool 1 DomU NFS eth1 v104 Pool1 dev VMs DomU: eth1 NFS and backup traffic
DEV Pool 1 DomU PRV eth2 v105 Pool1 dev VMs DomU: eth2 Private network for Oracle RAC and other app traffic
DEV Pool 1 DomU DMZ eth3 v106 Pool1 dev VMs DomU: eth3 External public access to apps

This example assumes that VLANs 200–216 are assigned to production, and VLANs 100–106 are assigned to development.

In both production and development, each server pool has three separate networks for server management, cluster heartbeat, and live migration (see shaded entries in Table 2). Each of these networks is mapped to a bonded network interface. Production Server Pool 1 uses bond0/VLAN 200 for server management, bond1/VLAN 201 for cluster heartbeat, and bond2/VLAN 202 for live migration. Production Server Pool 2 uses similar bond assignments with VLANs 210, 211, and 212, respectively. And Development uses similar bond assignments with VLANS 100, 101, and 102.

In this example, the network name identifies the function (development or production), server pool, intended network usage (for example, heartbeat), network bond or Ethernet port, and VLAN mapping. For example, the network name PRD Pool 2 Dom0 HB bond1 v211 identifies this network as allocated to production's server pool 2, which has an intended usage as heartbeat (HB) and is mapped to network bond1/VLAN 211.

Network names containing DomU clearly identify the virtual machine networks, while network names containing Dom0 clearly identify all non-virtual machine networks.

Final Thoughts

Choosing meaningful values for both the network name and description is a simple, no-cost way to improve management of Oracle VM networks. Taking a few minutes to plan a consistent naming scheme can save hours of time maintaining and troubleshooting the networks.

Network names and descriptions can be changed at any time without adverse effects. So it's never too late to fine-tune your Oracle VM network names and descriptions to make them more meaningful—and make your network configuration easier to understand and manage.

See Also

The following resources are available for Oracle VM Server for x86:

About the Authors

Gregory King joined the Oracle VM product management team as a senior best-practices technical consultant specializing in Oracle VM Server. Greg has a significant amount of hands-on experience with high availability, networking, storage, and storage networking, including SAN boot technology and server automation in production data centers, since 1993. His primary responsibility with the team is to develop and document solutions, including best practices, as well as foster a deeper understanding of the inner workings of Oracle VM with the goal of helping people become more successful with the product.

Suzanne Zorn has over 20 years of experience as a writer and editor of technical documentation for the computer industry. Previously, Suzanne worked as a consultant for Sun Microsystems' Professional Services division specializing in system configuration and planning. Suzanne has a BS in computer science and engineering from Bucknell University and an MS in computer science from Renssalaer Polytechnic Institute.

Revision 1.0, 11/12/2013

Follow us:
Blog | Facebook | Twitter | YouTube