After completing this section, you should be able to configure RHV to use networks provided by an external OpenStack provider.
RHV-M can utilize networks from any external network provider that implements the OpenStack Neutron REST API, including the Red Hat OpenStack Platform (RHOSP) OpenStack Networking service. The OpenStack Networking component provides an API for software-defined networking (SDN) capabilities, including dynamic creation and management of switches, routers, firewalls, and external connections to physical networks.
Neutron includes an expanding list of plugins, drivers, and agents that enable coupling with many commercial and open-source network technologies, including Cisco virtual and physical switches, NEC OpenFlow, Open vSwitch and Open Virtual Networking, Linux bridging, VMware NSX, MidoNet, OpenContrail, Open Daylight, Brocade, Juniper, and IBM. RHV 4.3 supports RHOSP versions 10, 13, and 14 as external network providers, when deployed with the original Open vSwitch driver up to and including version 13, and the Open Virtual Network and Open Daylight drivers starting in version 13.
Reviewing Software Defined Networking
Software-defined networking is more than deploying virtual networking components in a virtualization or cloud environment. An SDN controller is the control plane component that manages network devices in the data (forwarding) plane. These network devices, such as switches, routers, and firewalls, are programmatically configured for network routes, security, subnets and bandwidth in cooperation with the cloud-native application requiring dynamic services and allocation. An SDN controller centralizes the network global view, and presents the perception of a massively scalable, logical network switch to those applications.
Open vSwitch (OVS) can plug and unplugs port, create networks or subnets, and provide IP addressing. An Open vSwitch bridge allocates virtual ports to instances, and can span across to the physical network for incoming and outgoing traffic. Implementation is provided by OpenFlow (OF), which defines the communication protocol that enables the SDN Controller to act as the middle manager with both physical and virtual networking components, passing information to switches and routers below, and the applications and business logic above.
Enhanced features of OVN
Open Virtual Networking (OVN) enhanced OVS significantly to add native support for virtual network abstractions, such as virtual L2 and L3 overlays and security groups. Some high level features of OVN include:
Provides virtual networking abstraction for OVS, implemented using L2 and L3 overlays, but can also manage connectivity to physical networks.
Supports flexible security policies implemented using flows that use OVS connection tracking.
Native support for distributed L3 routing using OVS flows, with support for both IPv4 and IPv6.
Native support for NAT and load balancing using OVS connection tracking.
Native fully distributed support for DHCP.
Works with any OVS datapath (such as the default Linux kernel datapath, DPDK, or Hyper-V) that support Geneve tunnels and OVS connection tracking.
Supports L3 gateways from logical to physical networks.
Supports software-based L2 gateways.
Can provide networking for both VMs and containers running inside of those VMs, without a second layer of overlay networking.
Inclusion of OVN significantly enhances RHV networking, by providing a native overlay networking solution, and shifting networking away from being handled only by Linux host networking. OVN enhances networking and provides management capabilities to address diverse or complex networking requirements for advanced use cases.
Importing External Networks
To use neutron networks, first register the external network provider with RHV-M. After the network provider is validated, networks offered by that provider are automatically discovered and listed for selection as logical networks that are available to import into a data center. Imported networks are treated as RHV logical networks and can be attached to virtual machines in the data center. Certain limitations apply to using logical networks imported from an external provider:
External provider networks are for use as virtual machine networks, and cannot be used as display networks.
The same logical network can be imported more than once, but only to different data centers.
External provider networks may not be edited in RHV, but must be managed in the source external provider who implemented the drivers, agents and interfaces of the network.
External provides cannot be deleted from from RHV-M while any of their logical networks remain in use by a virtual machine.
External provider networks are not required. Although virtual machine scheduling does not check availability for imported networks during host selection, imported networks are acceptable for all normal deployment use cases.
Configuring Hosts to use External Networks
RHV hosts must communicate with the neutron API to use imported networks, requiring the installation and configuration of a neutron agent (the provider's virtual interface driver) using one of two methods. The second method, using Red Hat OpenStack Platform director, is recommended. For the first method, install the neutron agents manually. Register each host to the following repositories:
rhel-7-server-rpms
rhel-7-server-rhv-4-mgmt-agent-rpms
rhel-7-server-ansible-2-rpms
Then install the OpenStack Networking hook, by which VDSM invokes the correct plugin type (such as OVS) to pass the correct information to libvirt to treat vNICs that are handled by the OpenStack Networking provider. Also, remove the firewall rule that rejects ICMP traffic:
[root@host ~]#yum update[root@host ~]#yum install vdsm-hook-openstacknet[root@host ~]#iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
The second method is to use Red Hat OpenStack Platform director to deploy the Networker role to a node, then add the network node to the RHV Manager as a new host. Using the RHOSP director is recommended.
Configuring Subnets on External Networks
External network providers assign IP addresses through subnets configured on the logical networks. On networks with more than one available subnet, virtual machines can be assigned an IP address from any subnet. The external network provider's DHCP service assigns these IP addresses. Although RHV-M can discover predefined subnets on imported logical networks, subnets can be removed in RHV, without changing the external provider's configuration, to avoid using that subnet in RHV. RHV can also add new subnets for RHV use. To add or remove subnets from the networks on the external provider, use that provider's configuration tools.
Neutron network integration between RHV and RHOSP provides the hybrid platform to solve many rightsizing and scaling problems. In early cloud migration plans, many companies attempted to force fit enterprise workloads into the cloud without adequate redesign to handle scale out, stateless, and application-resilient HA (as opposed to platform resilient) requirements. Lessons were learned, in the first decade of the cloud rush, that not all workloads are conducive to redesign as cloud workloads. Hybrid infrastructure is increasingly seen as not just useful, but requisite, because most applications are comprised of a mix of enterprise and microservice workloads.
For example, significant applications remain as virtualized enterprise workloads, including:
Private cloud control plane, monitoring, and configuration management servers.
Authentication and authorization, and identity management servers.
Highly specialized, mission-critical applications. including high performance computing.
Database, data warehouse and big data business intelligence applications.
Highly available support servers, including DNS, DHCP, file servers, and email servers.
Any application requiring service level agreements addressing performance, backups, and stateful workloads.
Benefit of integrating environments
These applications remain on Red Hat Virtualization while middleware and front end interfaces move to the cloud. Organizations now require these hybrid abilities:
To support applications requiring both scale up and scale out technologies simultaneously for different application components.
To support software-defined networking in enterprise virtualization and including network overlay, encapsulation, and network security groups.
To manage a complex network topology from a single management platform for both the virtualization and the private cloud environments.
Neutron integration allows Red Hat Virtualization and Red Hat OpenStack Platform to be deployed in such a manner that applications can be designed to utilize both environments simultaneously. The front end, middleware, and business intelligence are deployed to OpenStack for the ability to scale out and back on demand, while a back end database continues as a highly available workload in Red Hat Virtualization, where it is better suited.
Traditional virtualization has become efficient at deploying and provisioning, minimizing delivery time using templates, snapshots, and images. Until now, enterprise virtualization still required physical switches and cabling for complex network infrastructure between clusters and data centers, thus limiting the increases in deployment speed. With RHOSP deployed alongside RHV in a data center, and utilizing Neutron integration, SDN features and management are shared, allowing automated, on-demand network configuration and scaling. By incorporating SDN into RHV, the legacy virtualization infrastructure now has access to the advanced networking capabilities of VXLAN, OpenFlow, Geneve, and Open vSwitch to supplement traditional VLANs and Linux bridges.
For more information, refer to the External Providers chapter in Adding an OpenStack Networking (Neutron) Instance for Network Provisioning at https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html-single/administration_guide/index#Adding_an_OpenStack_Network_Service_Neutron_for_Network_Provisioning