Today's data centers or multitenant cloud environments include multiple systems hosting several virtual machines (VMs) that are connected by a network fabric. Provisioning networking for VMs in a data center or multitenant cloud environment is a challenge for administrators, as it includes virtual networking between VMs, managing the MAC address and IP address, and administering VLANs and VXLANs. The additional challenge apart from ensuring internal and external network connectivity for VMs is to provision and enforce service-level agreements (SLAs) for the VMs and applications within VMs. These SLAs include bandwidth limits and priorities. Administrators also need to provide isolation between multiple tenants sharing a common network infrastructure.
To meet these requirements, Oracle Solaris network virtualization capabilities enable administrators to manage virtual switches across a data center or multitenant cloud environment. The virtual switches are exposed as first-class operating system abstractions. These virtual switches, also known as elastic virtual switches, span multiple systems and enable system administrators to manage them as a single virtual switch.
The virtual switch is an entity that facilitates communication between virtual machines. In Oracle Solaris, a virtual switch is automatically or implicitly created when you create a VNIC over a datalink, such as a link aggregation, a physical NIC, or an etherstub. The virtual switch loops traffic between VMs (inter-VM traffic) within the physical machine and does not send this traffic out on the wire. All VMs need to exist on the same Layer 2 segment to communicate with each other. For more information, see Virtual Switch.
In releases prior to Oracle Solaris 11.2, virtual switches were indirectly managed through the datalinks over which the VNICs were created. Starting with the Oracle Solaris 11.2 release, virtual switches can be managed by EVS. You can create a virtual switch explicitly and specify a name, assign virtual ports (VPort) to the virtual switch, and associate it with a block of IP addresses. You can set properties such as priority, maximum bandwidth, class of service (CoS), MAC address, and IP address for the virtual ports. You can also configure default SLAs on a per-virtual-switch basis.
The following figure shows the elastic virtual switch EVS0 in a single compute node.
Figure 15 Elastic Virtual Switch in a Compute Node
The Oracle Solaris Elastic Virtual Switch (EVS) feature enables you to create and administer a virtual switch that spans one or more compute nodes. These compute nodes are the physical machines that hosts VMs. An elastic virtual switch is an entity that represents explicitly created virtual switches that belong to the same Layer 2 (L2) segment. An elastic virtual switch provides network connectivity between VMs connected to it from anywhere in the network.
An elastic virtual switch can span across multiple hosts. These virtual switches are described as "elastic" because they have the capability to span into the host and span out of the host. The elastic virtual switch spans into the host when you connect the VNICs of the hosts to the elastic virtual switch. When you delete these VNICs, the elastic virtual switch spans out of the hosts.
An elastic virtual switch represents an isolated L2 segment, and the isolation is implemented as a flat (untagged), a VLAN or a VXLAN. For information about how you can implement an elastic virtual switch with a VLAN, see Use Case: Configuring an Elastic Virtual Switch. For information about how you implement an elastic virtual switch with a VXLAN, see Use Case: Configuring an Elastic Virtual Switch for a Tenant. For information about how to implement an elastic virtual switch based on a flat network, see How to Configure a Flat EVS Network.
For information about administering VLANs, see Chapter 3, Configuring Virtual Networks by Using Virtual Local Area Networks in Managing Network Datalinks in Oracle Solaris 11.3. For information about administering VXLANs, see Configuring Virtual Networks by Using Virtual Extensible Local Area Networks.
Every elastic virtual switch is associated with a name, virtual ports, and a block of IP addresses. You can create, monitor, and control the virtual switch resources. For more information, see Administering Elastic Virtual Switches.
The following figure shows two elastic virtual switches (EVS1 and EVS2) between two compute nodes. The VMs that are provisioned on these compute nodes are connected through the elastic virtual switches that span across the two compute nodes. Each compute node connects to the same network fabric through a datalink. The datalink is also known as an uplink port. The datalinks on these compute nodes connect the virtual switch to the external network. The VNIC is connected to the elastic virtual switch through a virtual port (VPort). The VNICs inherit properties that are associated with the virtual ports such as MAC address, IP address, and SLAs.
Figure 16 Elastic Virtual Switches Between Compute Nodes
In this figure, the VMs VM1, VM2, and VM6 can communicate with each other through the elastic virtual switch EVS1. The VMs VM3, VM4, and VM5 can communicate with each other through the elastic virtual switch EVS2. For more information, see How to Configure an Elastic Virtual Switch.
In a data center or multitenant cloud environment that hosts several virtual machines, EVS makes some of the network administration tasks simpler by providing the following benefits:
Creates a virtual network between VMs that are on systems thus providing network connectivity
Supports addition of virtual ports with custom SLAs
Provides network isolation by using VLANs or VXLANs
Supports multitenant virtual networks that share the same underlying infrastructure
Integrated with Oracle Solaris Zones and Oracle Solaris Kernel Zones
Provides centralized management of:
MAC address and IP address for the virtual ports
SLAs on a per-virtual-switch or per-virtual-port basis
Monitoring runtime network traffic statistics of the virtual ports
An elastic virtual switch is associated with the following main resources: an IP network and a virtual port. The resources and the elastic virtual switches are associated with Universal Unique Identifiers (UUIDs). An UUID is automatically generated by the EVS controller when you create an elastic virtual switch or its resources. See Example 59, Displaying the UUID of an Elastic Virtual Switch, Example 62, Displaying the UUID of an IPnet, and Example 67, Displaying the UUID for a VPort.
An IP network, also known as an IPnet, represents a block of IPv4 or IPv6 addresses with a default router for the block. This block of IPv4 or IPv6 addresses is also known as the subnet. You can associate only one IPnet to an elastic virtual switch. All VMs that connect to the elastic virtual switch through a virtual port are assigned an IP address from the IPnet that is associated with the elastic virtual switch.
You can also manually assign an IP address to a VM by setting the IP address property, ipaddr, for the VPort. This IP address must be within the subnet range of the IPnet. For more information about how to add an IPnet to the elastic virtual switch, see How to Configure an Elastic Virtual Switch.
A virtual port, also known as a VPort, represents the point of attachment between the VNIC and an elastic virtual switch. When a VNIC connects to a VPort, the VNIC inherits the network configuration parameters that the VPort encapsulates, such as the following:
SLA parameters such as maximum bandwidth, class of service, and priority
When you create a VPort, a randomly generated MAC address and the next available IP address from the associated IPnet are assigned to the VPort. The randomly generated MAC address has a default prefix consisting of a valid IEEE OUI with the local bit set. You can also specify the IP address and the MAC address when you add a VPort by using the evsadm add-vport command. For more information about how to add a VPort, see How to Configure an Elastic Virtual Switch.
The following table shows the VPort properties.
You cannot modify the properties evs and tenant because they are read-only properties. For more information about the VPort properties, see the evsadm(1M) man page.
The elastic virtual switches and their resources are logically grouped together. Each logical group is called a tenant. The defined resources for the elastic virtual switch within a tenant are not visible outside that tenant's namespace. The tenant acts as a container to hold all the tenant's resources together. For more information about how to create an elastic virtual switch with a tenant, see How to Configure an Elastic Virtual Switch.
You do not need to specify the tenant name for any EVS operation. The default tenant name is sys-global and all the EVS operations occur in this namespace.
In addition to implementing an elastic virtual switch by using a VLAN or VXLAN, Oracle Solaris also provides a flat L2-type network for implementing an elastic virtual switch. You can create a flat L2-type EVS and place all the VM instances on the same segment without a VLAN or VXLAN. This means that the VM instances share the same network, and therefore the same IP address space as a compute server. In a flat EVS network, there is no VLAN tagging or other types of network segregation. By default, the VNICs that you connect to the EVS with the flat L2-type are created with the VLAN ID set to 0. You cannot use flat L2-type to create multi-tenant networks. However, you can use the flat L2-type EVS to map directly to the existing physical networks in the data center. The evsadm command is enhanced that enables you to create a flat L2-type network. For more information, see How to Configure a Flat EVS Network.
You use the flat networks to directly map OpenStack Neutron network to an existing physical network. For example, if the range of available floating IPs are a subset of the existing physical network, then you need to create a flat network with the subnet set to that range of floating IPs. So, the flat network contains a part of the existing physical network's IP. For more information about OpenStack, see Installing and Configuring OpenStack (Havana) in Oracle Solaris.