9.4. Hosts and Networking 9.4.1. Refreshing Host Capabilities When a network interface card is added to a host, the capabilities of the host must be refreshed to display that network interface card in the Manager. Refreshing Host Capabilities Click Compute Hosts and select a host. Click Management Refresh Capabilities . The list of network interface cards in the Network Interfaces tab for the selected host is updated. Any new network interface cards can now be used in the Manager. 9.4.2. Editing Host Network Interfaces and Assigning Logical Networks to Hosts You can change the settings of physical host network interfaces, move the management network from one physical host network interface to another, and assign logical networks to physical host network interfaces. Bridge and ethtool custom properties are also supported. Warning The only way to change the IP address of a host in Red Hat Virtualization is to remove the host and then to add it again. To change the VLAN settings of a host, see Section 9.4.4, "Editing a Host's VLAN Settings" . Important You cannot assign logical networks offered by external providers to physical host network interfaces; such networks are dynamically assigned to hosts as they are required by virtual machines. Note If the switch has been configured to provide Link Layer Discovery Protocol (LLDP) information, you can hover your cursor over a physical network interface to view the switch port's current configuration. This can help to prevent incorrect configuration. Red Hat recommends checking the following information prior to assigning logical networks: Port Description (TLV type 4) and System Name (TLV type 5) help to detect to which ports and on which switch the host's interfaces are patched. Port VLAN ID shows the native VLAN ID configured on the switch port for untagged ethernet frames. All VLANs configured on the switch port are shown as VLAN Name and VLAN ID combinations. Editing Host Network Interfaces and Assigning Logical Networks to Hosts Click Compute Hosts . Click the host's name to open the details view. Click the Network Interfaces tab. Click Setup Host Networks . Optionally, hover your cursor over host network interface to view configuration information provided by the switch. Attach a logical network to a physical host network interface by selecting and dragging the logical network into the Assigned Logical Networks area to the physical host network interface. Note If a NIC is connected to more than one logical network, only one of the networks can be non-VLAN. All the other logical networks must be unique VLANs. Configure the logical network: Hover your cursor over an assigned logical network and click the pencil icon to open the Edit Management Network window. From the IPv4 tab, select a Boot Protocol from None , DHCP , or Static . If you selected Static , enter the IP , Netmask / Routing Prefix , and the Gateway . Note For IPv6, only static IPv6 addressing is supported. To configure the logical network, select the IPv6 tab and make the following entries: Set Boot Protocol to Static . For Routing Prefix , enter the length of the prefix using a forward slash and decimals. For example: /48 IP : The complete IPv6 address of the host network interface. For example: 2001:db8::1:0:0:6 Gateway : The source router's IPv6 address. For example: 2001:db8::1:0:0:1 Note If you change the host's management network IP address, you must reinstall the host for the new IP address to be configured. Each logical network can have a separate gateway defined from the management network gateway. This ensures traffic that arrives on the logical network will be forwarded using the logical network's gateway instead of the default gateway used by the management network. Important Set all hosts in a cluster to use the same IP stack for their management network; either IPv4 or IPv6 only. Dual stack is not supported. Use the QoS tab to override the default host network quality of service. Select Override QoS and enter the desired values in the following fields: Weighted Share : Signifies how much of the logical link's capacity a specific network should be allocated, relative to the other networks attached to the same logical link. The exact share depends on the sum of shares of all networks on that link. By default this is a number in the range 1-100. Rate Limit [Mbps] : The maximum bandwidth to be used by a network. Committed Rate [Mbps] : The minimum bandwidth required by a network. The Committed Rate requested is not guaranteed and will vary depending on the network infrastructure and the Committed Rate requested by other networks on the same logical link. To configure a network bridge, click the Custom Properties tab and select bridge_opts from the drop-down list. Enter a valid key and value with the following syntax: key = value . Separate multiple entries with a whitespace character. The following keys are valid, with the values provided as examples. For more information on these parameters, see Section B.1, "Explanation of bridge_opts Parameters" . To configure ethernet properties, click the Custom Properties tab and select ethtool_opts from the drop-down list. Enter a valid value using the format of the command-line arguments of ethtool. For example: This field can accept wildcards. For example, to apply the same option to all of this network's interfaces, use: The ethtool_opts option is not available by default; you need to add it using the engine configuration tool. See Section B.2, "How to Set Up Red Hat Virtualization Manager to Use Ethtool" for more information. For more information on ethtool properties, see the manual page by typing man ethtool in the command line. To configure Fibre Channel over Ethernet (FCoE), click the Custom Properties tab and select fcoe from the drop-down list. Enter a valid key and value with the following syntax: key = value . At least enable=yes is required. You can also add dcb= and auto_vlan= [yes|no] . Separate multiple entries with a whitespace character. The fcoe option is not available by default; you need to add it using the engine configuration tool. See Section B.3, "How to Set Up Red Hat Virtualization Manager to Use FCoE" for more information. Note A separate, dedicated logical network is recommended for use with FCoE. To change the default network used by the host from the management network (ovirtmgmt) to a non-management network, configure the non-management network's default route. See Section 9.1.5, "Configuring a Non-Management Logical Network as the Default Route" for more information. If your logical network definition is not synchronized with the network configuration on the host, select the Sync network check box. For more information about unsynchronized hosts and how to synchronize them, see Section 9.4.3, "Synchronizing Host Networks" . Select the Verify connectivity between Host and Engine check box to check network connectivity. This action only works if the host is in maintenance mode. Click OK . Note If not all network interface cards for the host are displayed, click Management Refresh Capabilities to update the list of network interface cards available for that host. 9.4.3. Synchronizing Host Networks The Manager defines a network interface as out-of-sync when the definition of the interface on the host differs from the definitions stored by the Manager. Out-of-sync networks appear with an Out-of-sync icon in the host's Network Interfaces tab and with this icon in the Setup Host Networks window. When a host's network is out of sync, the only activities that you can perform on the unsynchronized network in the Setup Host Networks window are detaching the logical network from the network interface or synchronizing the network. Understanding How a Host Becomes out-of-sync A host will become out of sync if: You make configuration changes on the host rather than using the the Edit Logical Networks window, for example: Changing the VLAN identifier on the physical host. Changing the Custom MTU on the physical host. You move a host to a different data center with the same network name, but with different values/parameters. You change a network's VM Network property by manually removing the bridge from the host. Preventing Hosts from Becoming Unsynchronized Following these best practices will prevent your host from becoming unsynchronized: Use the Administration Portal to make changes rather than making changes locally on the host. Edit VLAN settings according to the instructions in Section 9.4.4, "Editing a Host's VLAN Settings" . Synchronizing Hosts Synchronizing a host's network interface definitions involves using the definitions from the Manager and applying them to the host. If these are not the definitions that you require, after synchronizing your hosts update their definitions from the Administration Portal. You can synchronize a host's networks on three levels: Per logical network Per host Per cluster Synchronizing Host Networks on the Logical Network Level Click Compute Hosts . Click the host's name to open the details view. Click the Network Interfaces tab. Click Setup Host Networks . Hover your cursor over the unsynchronized network and click the pencil icon to open the Edit Network window. Select the Sync network check box. Click OK to save the network change. Click OK to close the Setup Host Networks window. Synchronizing a Host's Networks on the Host level Click the Sync All Networks button in the host's Network Interfaces tab to synchronize all of the host's unsynchronized network interfaces. Synchronizing a Host's Networks on the Cluster level Click the Sync All Networks button in the cluster's Logical Networks tab to synchronize all unsynchronized logical network definitions for the entire cluster. Note You can also synchronize a host's networks via the REST API. See syncallnetworks in the REST API Guide . 9.4.4. Editing a Host's VLAN Settings To change the VLAN settings of a host, the host must be removed from the Manager, reconfigured, and re-added to the Manager. To keep networking synchronized, do the following: Put the host in maintenance mode. Manually remove the management network from the host. This will make the host reachable over the new VLAN. Add the host to the cluster. Virtual machines that are not connected directly to the management network can be migrated between hosts safely. The following warning message appears when the VLAN ID of the management network is changed: Proceeding causes all of the hosts in the data center to lose connectivity to the Manager and causes the migration of hosts to the new management network to fail. The management network will be reported as "out-of-sync". Important If you change the management network's VLAN ID, you must reinstall the host to apply the new VLAN ID. 9.4.5. Adding Multiple VLANs to a Single Network Interface Using Logical Networks Multiple VLANs can be added to a single network interface to separate traffic on the one host. Important You must have created more than one logical network, all with the Enable VLAN tagging check box selected in the New Logical Network or Edit Logical Network windows. Adding Multiple VLANs to a Network Interface using Logical Networks Click Compute Hosts . Click the host's name to open the details view. Click the Network Interfaces tab. Click Setup Host Networks . Drag your VLAN-tagged logical networks into the Assigned Logical Networks area to the physical network interface. The physical network interface can have multiple logical networks assigned due to the VLAN tagging. Edit the logical networks: Hover your cursor over an assigned logical network and click the pencil icon. If your logical network definition is not synchronized with the network configuration on the host, select the Sync network check box. Select a Boot Protocol : None DHCP Static Provide the IP and Subnet Mask . Click OK . Select the Verify connectivity between Host and Engine check box to run a network check; this will only work if the host is in maintenance mode. Click OK . Add the logical network to each host in the cluster by editing a NIC on each host in the cluster. After this is done, the network will become operational. This process can be repeated multiple times, selecting and editing the same network interface each time on each host to add logical networks with different VLAN tags to a single network interface. 9.4.6. Assigning Additional IPv4 Addresses to a Host Network A host network, such as the ovirtmgmt management network, is created with only one IP address when initially set up. This means that if a NIC's configuration file (for example, /etc/sysconfig/network-scripts/ifcfg-eth01 ) is configured with multiple IP addresses, only the first listed IP address will be assigned to the host network. Additional IP addresses may be required if connecting to storage, or to a server on a separate private subnet using the same NIC. The vdsm-hook-extra-ipv4-addrs hook allows you to configure additional IPv4 addresses for host networks. For more information about hooks, see Appendix A, VDSM and Hooks . In the following procedure, the host-specific tasks must be performed on each host for which you want to configure additional IP addresses. Assigning Additional IPv4 Addresses to a Host Network On the host that you want to configure additional IPv4 addresses for, install the VDSM hook package. The package is available by default on Red Hat Virtualization Hosts but needs to be installed on Red Hat Enterprise Linux hosts. On the Manager, run the following command to add the key: Restart the ovirt-engine service: In the Administration Portal, click Compute Hosts . Click the host's name to open the details view. Click the Network Interfaces tab and click Setup Host Networks . Edit the host network interface by hovering the cursor over the assigned logical network and clicking the pencil icon. Select ipv4_addr from the Custom Properties drop-down list and add the additional IP address and prefix (for example 5.5.5.5/24). Multiple IP addresses must be comma-separated. Click OK to close the Edit Network window. Click OK to close the Setup Host Networks window. The additional IP addresses will not be displayed in the Manager, but you can run the command ip addr show on the host to confirm that they have been added. 9.4.7. Adding Network Labels to Host Network Interfaces Using network labels allows you to greatly simplify the administrative workload associated with assigning logical networks to host network interfaces. Setting a label on a role network (for instance, a migration network or a display network) causes a mass deployment of that network on all hosts. Such mass additions of networks are achieved through the use of DHCP. This method of mass deployment was chosen over a method of typing in static addresses, because of the unscalable nature of the task of typing in many static IP addresses. There are two methods of adding labels to a host network interface: Manually, in the Administration Portal Automatically, with the LLDP Labeler service Adding Network Labels in the Administration Portal Click Compute Hosts . Click the host's name to open the details view. Click the Network Interfaces tab. Click Setup Host Networks . Click Labels and right-click [New Label] . Select a physical network interface to label. Enter a name for the network label in the Label text field. Click OK . Adding Network Labels with the LLDP Labeler Service You can automate the process of assigning labels to host network interfaces in the configured list of clusters with the LLDP Labeler service. By default, LLDP Labeler runs as an hourly service. This option is useful if you make hardware changes (for example, NICs, switches, or cables) or change switch configurations. Prerequisites The interfaces must be connected to a Juniper switch. The Juniper switch must be configured to provide the Port VLAN using LLDP. Procedure Configure the username and password in /etc/ovirt-lldp-labeler/conf.d/ovirt-lldp-credentials.conf : username - the username of the Manager administrator. The default is admin@internal . password - the password of the Manager administrator. The default is 123456 . Configure the LLDP Labeler service by updating the following values in etc/ovirt-lldp-labeler/conf.d/ovirt-lldp-credentials.conf : clusters - a comma-separated list of clusters on which the service should run. Wildcards are supported. For example, Cluster* defines LLDP Labeler to run on all clusters starting with word Cluster . To run the service on all clusters in the data center, type * . The default is Def* . api_url - the full URL of the Manager's API. The default is https:// Manager_FQDN /ovirt-engine/api ca_file - the path to the custom CA certificate file. Leave this value empty if you do not use custom certificates. The default is empty. auto_bonding - enables LLDP Labeler's bonding capabilities. The default is true . auto_labeling - enables LLDP Labeler's labeling capabilities. The default is true . Optionally, you can configure the service to run at a different time interval by changing the value of OnUnitActiveSec in etc/ovirt-lldp-labeler/conf.d/ovirt-lldp-labeler.timer . The default is 1h . Configure the service to start now and at boot by entering the following command: To invoke the service manually, enter the following command: You have added a network label to a host network interface. Newly created logical networks with the same label are automatically assigned to all host network interfaces with that label. Removing a label from a logical network automatically removes that logical network from all host network interfaces with that label. 9.4.8. Changing the FQDN of a Host Use the following procedure to change the fully qualified domain name of hosts. Updating the FQDN of a Host Place the host into maintenance mode so the virtual machines are live migrated to another host. See Section 10.5.15, "Moving a Host to Maintenance Mode" for more information. Alternatively, manually shut down or migrate all the virtual machines to another host. See Manually Migrating Virtual Machines in the Virtual Machine Management Guide for more information. Click Remove , and click OK to remove the host from the Administration Portal. Use the hostnamectl tool to update the host name. For more options, see Configure Host Names in the Red Hat Enterprise Linux 7 Networking Guide . Reboot the host. Re-register the host with the Manager. See Section 10.5.1, "Adding Standard Hosts to the Red Hat Virtualization Manager" for more information. 9.4.9. IPv6 Networking Support Red Hat Virtualization supports static IPv6 networking in most contexts. Note Red Hat Virtualization requires IPv6 to remain enabled on the computer or virtual machine where you are running the Manager (also called "the Manager machine"). Do not disable IPv6 on the Manager machine, even if your systems do not use it. Limitations for IPv6 Only static IPv6 addressing is supported. Dynamic IPv6 addressing with DHCP or Stateless Address Autoconfiguration are not supported. Dual-stack addressing, IPv4 and IPv6, is not supported. OVN networking can be used with only IPv4 or IPv6. Switching clusters from IPv4 to IPv6 is not supported. Only a single gateway per host can be set for IPv6. If both networks share a single gateway (are on the same subnet), you can move the default route role from the management network (ovirtmgmt) to another logical network. The host and Manager should have the same IPv6 gateway. If the host and Manager are not on the same subnet, the Manager might lose connectivity with the host because the IPv6 gateway was removed. Using a glusterfs storage domain with an IPv6-addressed gluster server is not supported. 9.4.10. Setting Up and Configuring SR-IOV This topic summarizes the steps for setting up and configuring SR-IOV, with links out to topics that cover each step in detail. 9.4.10.1. Prerequisites Set up your hardware in accordance with the Hardware Considerations for Implementing SR-IOV 9.4.10.2. Set Up and Configure SR-IOV To set up and configure SR-IOV, complete the following tasks. Configuring the host for PCI passthrough Editing the virtual function configuration on a NIC . Enabling passthrough on a vNIC Profile . Configuring Virtual Machines with SR-IOV-Enabled vNICs to Reduce Network Outage during Migration . Notes The number of the 'passthrough' vNICs depends on the number of available virtual functions (VFs) on the host. For example, to run a virtual machine (VM) with three SR-IOV cards (vNICs), the host must have three or more VFs enabled. Hotplug and unplug are supported. Live migration is supported from RHV version 4.1 onward. To migrate a VM, the destination host must also have enough available VFs to receive the VM. During the migration, the VM releases a number of VFs on the source host and occupies the same number of VFs on the destination host. On the host, you will see a device, link, or ifcae like any other interface. That device disappears when it is attached to a VM, and reappears when it is released. Avoid attaching a host device directly to a VM for SR-IOV feature. To use a VF as a trunk port with several VLANs and configure the VLANs within the Guest, please see Cannot configure VLAN on SR-IOV VF interfaces inside the Virtual Machine . Here is an example of what the libvirt XML for the interface would look like: ---- <interface type='hostdev'> <mac address='00:1a:yy:xx:vv:xx'/> <driver name='vfio'/> <source> <address type='pci' domain='0x0000' bus='0x05' slot='0x10' function='0x0'/> </source> <alias name='ua-18400536-5688-4477-8471-be720e9efc68'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </interface> ---- Troubleshooting The following example shows you how to get diagnostic information about the VFs attached to an interface. 9.4.10.3. Additional Resources How to configure SR-IOV passthrough for RHV VM? How to configure bonding with SR-IOV VF(Virtual Function) in RHV How to enable host device passthrough and SR-IOV to allow assigning dedicated virtual NICs to virtual machines in RHV

Commands:
forward_delay=1500 gc_timer=3765 group_addr=1:80:c2:0:0:0 group_fwd_mask=0x0 hash_elasticity=4 hash_max=512 hello_time=200 hello_timer=70 max_age=2000 multicast_last_member_count=2 multicast_last_member_interval=100 multicast_membership_interval=26000 multicast_querier=0 multicast_querier_interval=25500 multicast_query_interval=13000 multicast_query_response_interval=1000 multicast_query_use_ifaddr=0 multicast_router=1 multicast_snooping=1 multicast_startup_query_count=2 multicast_startup_query_interval=3125
--coalesce em1 rx-usecs 14 sample-interval 3 --offload em2 rx on lro on tso off --change em1 speed 1000 duplex half
--coalesce * rx-usecs 14 sample-interval 3
Changing certain properties (e.g. VLAN, MTU) of the management network could lead to loss of connectivity to hosts in the data center, if its underlying network infrastructure isn't configured to accommodate the changes. Are you sure you want to proceed?
yum install vdsm-hook-extra-ipv4-addrs
engine-config -s 'UserDefinedNetworkCustomProperties=ipv4_addrs=.*'
systemctl restart ovirt-engine.service
systemctl enable --now ovirt-lldp-labeler
/usr/bin/python /usr/share/ovirt-lldp-labeler/ovirt_lldp_labeler_cli.py
hostnamectl set-hostname NEW_FQDN
---- <interface type='hostdev'> <mac address='00:1a:yy:xx:vv:xx'/> <driver name='vfio'/> <source> <address type='pci' domain='0x0000' bus='0x05' slot='0x10' function='0x0'/> </source> <alias name='ua-18400536-5688-4477-8471-be720e9efc68'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </interface> ----
ip -s link show dev enp5s0f0 1: enp5s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT qlen 1000 link/ether 86:e2:ba:c2:50:f0 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 30931671 218401 0 0 0 19165434 TX: bytes packets errors dropped carrier collsns 997136 13661 0 0 0 0 vf 0 MAC 02:00:00:00:00:01, spoof checking on, link-state auto, trust off, query_rss off vf 1 MAC 00:1a:4b:16:01:5e, spoof checking on, link-state auto, trust off, query_rss off vf 2 MAC 02:00:00:00:00:01, spoof checking on, link-state auto, trust off, query_rss off