5.2 Network Usage

In Oracle VM a network can perform one or more network functions:

The first step in configuring your Oracle VM environment is to discover your Oracle VM Servers. This step assumes that the Oracle VM Manager host and all of the Oracle VM Servers can communicate over the same network, though the Oracle VM Servers and Oracle VM Manager can reside in different subnets. When you discover the first Oracle VM Server, the management network is created automatically and takes its name from the subnet to which the Oracle VM Server is connected. Each additional Oracle VM Server discovered is either on a previously known subnet, or a new subnet. If the Oracle VM Server is on a new subnet then a new management network is constructed; if the Oracle VM Server is on a known subnet then it is simply added to that subnet. Each server in your Oracle VM environment can only have one interface designated for management, belonging to a single management network object in the Oracle VM Manager's database.


Although the Oracle VM Manager and its discovered and owned Oracle VM Servers may be on different subnets as long as they can reach each other, Network Address Translation (NAT) is not supported in this configuration. NAT would lead to a discrepancy between the actual management IP of the Oracle VM Server and the IP provided during discovery.

A network port on every Oracle VM Server is designated as the management interface during the installation of the Oracle VM Server and is configured as a bonded interface. Ports can be added to this bond or removed from it. Once a management network is created, it can only be deleted if no servers have ports in the management network anymore.

After your management networks are in place, you plan for the creation of other types of network. Note that once a port is selected for a particular network, it cannot be selected again when creating additional networks. You can use a combination of network bonding and VLAN Groups to create all the networks needed for your environment using your existing ports. Network bonding is covered in Section 5.3, “Building a Network Environment”; VLAN Groups are covered in Section 5.7, “VLAN Groups and VLAN Segments”.

Figure 5.1 Oracle VM Networking Example

This figure shows an example of a networking architecture in an Oracle VM environment.

Figure 5.1, “Oracle VM Networking Example” shows an example of an Oracle VM environment with split network functions. Each Oracle VM Server is connected to the management network, regardless of which server pool they belong to.

It is best practice to define separate networks for heartbeating functionality and for live migration. This is because functions like live migration can generate peaks in network traffic. Since heartbeat functionality is sensitive to peak loads, it is better that this function is not affected by a loaded network [1] . Since these types of network traffic occur at the level of an individual server pool, the networks do not need a gateway. It is important to understand that when creating different networks to handle separate functions, it is not possible for a server to belong to more than one network that has been assigned the same function.

Virtual machine (VM) traffic is often routed over a dedicated network, although it can be combined with the other network functions. In this example the dedicated VM network has a route to the internet (or corporate wide area network). You can create as many virtual machine networks as permitted by your network infrastructure.

The first two server pools are connected to a storage network with Ethernet based storage providers. Ethernet based storage is provided as either NFS file servers or iSCSI LUNs. Server Pool 3 has dedicated fibre channel storage, which requires a fibre channel switch and host bus adapters (HBAs) in all connected hardware components. Similar to networks for virtual machines, you create as many storage networks as needed to implement your storage strategy.

[1] Temporarily high network load could cause the heartbeat to fail for a server, resulting in the server being fenced out of a cluster unnecessarily.