Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 15. Configuring virtual machine network connections
For your virtual machines (VMs) to connect over a network to your host, to other VMs on your host, and to locations on an external network, the VM networking must be configured accordingly. To provide VM networking, the RHEL 10 hypervisor and newly created VMs have a default network configuration, which can also be modified further.
For example:
- You can enable the VMs on your host to be discovered and connected to locations outside the host, as if the VMs were on the same network as the host.
- You can partially or completely isolate a VM from inbound network traffic to increase its security and minimize the risk of any problems with the VM impacting the host.
15.1. How virtual networks work Copier lienLien copié sur presse-papiers!
The connection of virtual machines (VMs) to other devices and locations on a network is facilitated by the host hardware. Virtual networking uses the concept of a virtual network switch.
A virtual network switch is a software construct that operates on a host machine. VMs connect to the network through the virtual network switch. Based on the configuration of the virtual switch, a VM can use an existing virtual network managed by the hypervisor, or a different network connection method.
The following figure shows a virtual network switch connecting two VMs to the network:
From the perspective of a guest operating system, a virtual network connection is the same as a physical network connection. Host machines view virtual network switches as network interfaces. When the virtnetworkd service is first installed and started, it creates virbr0, the default network interface for VMs.
To view information about this interface, use the ip utility on the host.
$ ip addr show virbr0
3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UNKNOWN link/ether 1b:c4:94:cf:fd:17 brd ff:ff:ff:ff:ff:ff
inet 192.0.2.1/24 brd 192.0.2.255 scope global virbr0
By default, all VMs on a single host are connected to the same NAT-type virtual network, named default, which uses the virbr0 interface.
For basic outbound-only network access from VMs, no additional network setup is usually needed, because the default network is installed along with the libvirt-daemon-config-network package, and is automatically started when the virtnetworkd service is started.
If a different VM network functionality is needed, you can create additional virtual networks and network interfaces and configure your VMs to use them. In addition to the default NAT, these networks and interfaces can be configured to use one of the following modes:
- Routed mode
- Bridged mode
- Isolated mode
- Open mode
15.2. The default configuration for virtual machine networks Copier lienLien copié sur presse-papiers!
When the virtnetworkd service is first installed on a virtualization host, it contains an initial virtual network configuration in network address translation (NAT) mode.
By default, all VMs on the host are connected to the same libvirt virtual network, named default. VMs on this network can connect to locations both on the host and on the network beyond the host, but with the following limitations:
-
VMs on the network are visible to the host and other VMs on the host, but the network traffic is affected by the firewalls in the guest operating system’s network stack and by the
libvirtnetwork filtering rules attached to the guest interface. - VMs on the network can connect to locations outside the host but are not visible to them. Outbound traffic is affected by the NAT rules, as well as the host system’s firewall.
The following diagram illustrates the default VM network configuration:
15.3. Network connection types for virtual machines Copier lienLien copié sur presse-papiers!
To modify the networking properties and behavior of your VMs, change the type of virtual network or interface the VMs use. You can select from the following connection types available to VMs in RHEL 10.
15.3.1. Virtual networking with network address translation Copier lienLien copié sur presse-papiers!
By default, virtual network switches operate in network address translation (NAT) mode. They use IP masquerading rather than Source-NAT (SNAT) or Destination-NAT (DNAT). IP masquerading enables connected VMs to use the host machine’s IP address for communication with any external network. When the virtual network switch is operating in NAT mode, computers external to the host cannot communicate with the VMs inside the host.
Virtual network switches use NAT configured by firewall rules. Editing these rules while the switch is running is not recommended, because incorrect rules might result in the switch being unable to communicate.
15.3.2. Virtual networking in routed mode Copier lienLien copié sur presse-papiers!
When using Routed mode, the virtual switch connects to the physical LAN connected to the host machine, passing traffic back and forth without the use of NAT. The virtual switch can examine all traffic and use the information contained within the network packets to make routing decisions. When using this mode, the virtual machines (VMs) are all in a single subnet, separate from the host machine. The VM subnet is routed through a virtual switch, which exists on the host machine. This enables incoming connections, but requires extra routing-table entries for systems on the external network.
Routed mode uses routing based on the IP address:
A common topology that uses routed mode is virtual server hosting (VSH). A VSH provider may have several host machines, each with two physical network connections. One interface is used for management and accounting, the other for the VMs to connect through. Each VM has its own public IP address, but the host machines use private IP addresses so that only internal administrators can manage the VMs.
15.3.3. Virtual networking in bridged mode Copier lienLien copié sur presse-papiers!
In most VM networking modes, VMs automatically create and connect to the virbr0 virtual bridge. In contrast, in bridged mode, the VM connects to an existing Linux bridge on the host. As a result, the VM is directly visible on the physical network. This enables incoming connections, but does not require any extra routing-table entries.
Bridged mode uses connection switching based on the MAC address:
In bridged mode, the VM appear within the same subnet as the host machine. All other physical machines on the same physical network can detect the VM and access it.
Bridged network bonding
It is possible to use multiple physical bridge interfaces on the hypervisor by joining them together with a bond. The bond can then be added to a bridge, after which the VMs can be added to the bridge as well. However, the bonding driver has several modes of operation, and not all of these modes work with a bridge where VMs are in use.
Bonding modes 1, 2, and 4 are usable.
In contrast, modes 0, 3, 5, or 6 are likely to cause the connection to fail. Also note that media-independent interface (MII) monitoring should be used to monitor bonding modes, as Address Resolution Protocol (ARP) monitoring does not work correctly.
For more information about bonding modes, see the Red Hat Knowledgebase solution Which bonding modes work when used with a bridge that virtual machine guests or containers connect to?.
Common scenarios
The most common use cases for bridged mode include:
- Deploying VMs in an existing network alongside host machines, making the difference between virtual and physical machines invisible to the user.
- Deploying VMs without making any changes to existing physical network configuration settings.
- Deploying VMs that must be easily accessible to an existing physical network. Placing VMs on a physical network where they must access DHCP services.
- Connecting VMs to an existing network where virtual LANs (VLANs) are used.
- A demilitarized zone (DMZ) network. For a DMZ deployment with VMs, Red Hat recommends setting up the DMZ at the physical network router and switches, and connecting the VMs to the physical network by using bridged mode.
15.4. Virtual networking in isolated mode Copier lienLien copié sur presse-papiers!
By using isolated mode, virtual machines connected to the virtual switch can communicate with each other and with the host machine, but their traffic will not pass outside of the host machine, and they cannot receive traffic from outside the host machine. Using dnsmasq in this mode is required for basic functionality such as DHCP.
15.4.1. Virtual networking in open mode Copier lienLien copié sur presse-papiers!
When using open mode for networking, libvirt does not generate any firewall rules for the network. As a result, libvirt does not overwrite firewall rules provided by the host, and the user can therefore manually manage the VM’s firewall rules.
15.5. Comparison of virtual machine connection types Copier lienLien copié sur presse-papiers!
The following table provides information about the locations to which selected types of virtual machine (VM) network configurations can connect, and to which they are visible.
| Connection to the host | Connection to other VMs on the host | Connection to outside locations | Visible to outside locations | |
|---|---|---|---|---|
| Bridged mode | YES | YES | YES | YES |
| NAT | YES | YES | YES | no |
| Routed mode | YES | YES | YES | YES |
| Isolated mode | YES | YES | no | no |
| Open mode | Depends on the host’s firewall rules | |||
15.6. Using the web console for managing virtual machine network interfaces Copier lienLien copié sur presse-papiers!
To manage the virtual network interfaces for virtual machines (VMs) on your host, you can use the RHEL 10 web console.
15.6.1. Viewing and editing virtual network interface information in the web console Copier lienLien copié sur presse-papiers!
To view and modify the virtual network interfaces on a selected virtual machine (VM), you can use the RHEL 10 web console.
Prerequisites
You have installed the RHEL 10 web console.
For instructions, see Installing and enabling the web console.
- The web console VM plug-in is installed on your system.
Procedure
- Log in to the RHEL 10 web console.
In the interface, click the VM whose information you want to see.
A new page opens with an Overview section with basic information about the selected VM and a Console section to access the VM’s graphical interface.
Scroll to .
The Network Interfaces section displays information about the virtual network interface configured for the VM as well as options to Add, Delete, Edit, or Unplug network interfaces.
The information includes the following:
Type - The type of network interface for the VM. The types include virtual network, bridge to LAN, and direct attachment.
NoteGeneric Ethernet connection is not supported in RHEL 10 and later.
- Model type - The model of the virtual network interface.
- MAC Address - The MAC address of the virtual network interface.
- IP Address - The IP address of the virtual network interface.
- Source - The source of the network interface. This is dependent on the network type.
- State - The state of the virtual network interface.
- To edit the virtual network interface settings, Click . The Virtual Network Interface Settings dialog opens.
- Change the interface type, source, model, or MAC address.
Click . The network interface is modified.
NoteChanges to the virtual network interface settings take effect only after restarting the VM.
Additionally, MAC address can only be modified when the VM is shut off.
15.6.2. Adding and connecting virtual network interfaces in the web console Copier lienLien copié sur presse-papiers!
To create a virtual network interface and connect a virtual machine (VM) to it, you can use the RHEL 10 web console.
Prerequisites
You have installed the RHEL 10 web console.
For instructions, see Installing and enabling the web console.
- The web console VM plug-in is installed on your system.
Procedure
- Log in to the RHEL 10 web console.
In the interface, click the VM whose information you want to see.
A new page opens with an Overview section with basic information about the selected VM and a Console section to access the VM’s graphical interface.
Scroll to .
The Network Interfaces section displays information about the virtual network interface configured for the VM as well as options to Add, Edit, or Plug network interfaces.
If no network interfaces are available that meet your requirements, you can create a new interface by clicking the .
- In the Add network interface dialog, select the type and source of the interface, as well as other options, based on your requirements.
- Click .
Click in the row of the virtual network interface you want to connect.
The selected virtual network interface connects to the VM.
15.6.3. Disconnecting and removing virtual network interfaces in the web console Copier lienLien copié sur presse-papiers!
To disconnect virtual network interfaces connected to a selected virtual machine (VM), you can use the RHEL 10 web console.
Prerequisites
You have installed the RHEL 10 web console.
For instructions, see Installing and enabling the web console.
- The web console VM plug-in is installed on your system.
Procedure
- Log in to the RHEL 10 web console.
In the interface, click the VM whose information you want to see.
A new page opens with an Overview section with basic information about the selected VM and a Console section to access the VM’s graphical interface.
Scroll to .
The Network Interfaces section displays information about the virtual network interface configured for the VM as well as options to Add, Delete, Edit, or Unplug network interfaces.
Click in the row of the virtual network interface you want to disconnect.
The selected virtual network interface disconnects from the VM.
- Optional: If you want to delete the virtual network interface from the host, click the menu button in the pane of the interface, then click .
15.7. Managing SR-IOV networking devices Copier lienLien copié sur presse-papiers!
An emulated virtual device often uses more CPU and memory than a hardware network device. This can limit the performance of a virtual machine (VM). However, if any devices on your virtualization host support Single Root I/O Virtualization (SR-IOV), you can use this feature to improve the device performance, and possibly also the overall performance of your VMs.
15.7.1. What is SR-IOV? Copier lienLien copié sur presse-papiers!
Single-root I/O virtualization (SR-IOV) is a specification that enables a single PCI Express (PCIe) device to present multiple separate PCI devices, called virtual functions (VFs), to the host system.
Each of these devices:
- Is able to provide the same or similar service as the original PCIe device.
- Appears at a different address on the host PCI bus.
- Can be assigned to a different VM by using VFIO assignment.
For example, a single SR-IOV capable network device can present VFs to multiple VMs. All of the VFs use the same physical card, the same network connection, and the same network cable, but each of the VMs directly controls its own hardware network device and uses no extra resources from the host.
How SR-IOV works
The SR-IOV functionality is possible thanks to the introduction of the following PCIe functions:
- Physical functions (PFs) - A PCIe function that provides the functionality of its device (for example networking) to the host, but can also create and manage a set of VFs. Each SR-IOV capable device has one or more PFs.
- Virtual functions (VFs) - Lightweight PCIe functions that behave as independent devices. Each VF is derived from a PF. The maximum number of VFs a device can have depends on the device hardware. Each VF can be assigned only to a single VM at a time, but a VM can have multiple VFs assigned to it.
VMs recognize VFs as virtual devices. For example, a VF created by an SR-IOV network device appears as a network card to a VM to which it is assigned, in the same way as a physical network card appears to the host system.
Figure 15.1. SR-IOV architecture
Advantages
The primary advantages of using SR-IOV VFs rather than emulated devices are:
- Improved performance
- Reduced use of host CPU and memory resources
For example, a VF attached to a VM as a vNIC performs at almost the same level as a physical NIC, and much better than paravirtualized or emulated NICs. In particular, when multiple VFs are used simultaneously on a single host, the performance benefits can be significant.
Disadvantages
- To modify the configuration of a PF, you must first change the number of VFs exposed by the PF to zero. Therefore, you also need to remove the devices provided by these VFs from the VM to which they are assigned.
- A VM with an VFIO-assigned devices attached, including SR-IOV VFs, cannot be migrated to another host. In some cases, you can work around this limitation by pairing the assigned device with an emulated device. For example, you can bond an assigned networking VF to an emulated vNIC, and remove the VF before the migration.
- In addition, VFIO-assigned devices require pinning of VM memory, which increases the memory consumption of the VM and prevents the use of memory ballooning on the VM.
15.7.2. Attaching SR-IOV networking devices to virtual machines Copier lienLien copié sur presse-papiers!
To assign an SR-IOV networking device to a virtual machine (VM), you must create a virtual function (VF) from an SR-IOV capable network interface on the host and assign the VF as a device to a specified VM.
Prerequisites
The CPU and the firmware of your host support the I/O Memory Management Unit (IOMMU).
- If using an Intel CPU, it must support the Intel Virtualization Technology for Directed I/O (VT-d).
- If using an AMD CPU, it must support the AMD-Vi feature.
The host system uses Access Control Service (ACS) to provide direct memory access (DMA) isolation for PCIe topology. Verify this with the system vendor.
For additional information, see Hardware Considerations for Implementing SR-IOV.
The physical network device supports SR-IOV. To verify if any network devices on your system support SR-IOV, use the
lspci -vcommand and look forSingle Root I/O Virtualization (SR-IOV)in the output.# lspci -v [...] 02:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) Subsystem: Intel Corporation Gigabit ET Dual Port Server Adapter Flags: bus master, fast devsel, latency 0, IRQ 16, NUMA node 0 Memory at fcba0000 (32-bit, non-prefetchable) [size=128K] [...] Capabilities: [150] Alternative Routing-ID Interpretation (ARI) Capabilities: [160] Single Root I/O Virtualization (SR-IOV) Kernel driver in use: igb Kernel modules: igb [...]The host network interface you want to use for creating VFs is running. For example, to activate the eth1 interface and verify it is running:
# ip link set eth1 up # ip link show eth1 8: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000 link/ether a0:36:9f:8f:3f:b8 brd ff:ff:ff:ff:ff:ff vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 2 MAC 00:00:00:00:00:00, spoof checking on, link-state auto vf 3 MAC 00:00:00:00:00:00, spoof checking on, link-state autoFor SR-IOV device assignment to work, the IOMMU feature must be enabled in the host BIOS and kernel. To do so:
On an Intel host, enable VT-d:
Regenerate the GRUB configuration with the
intel_iommu=onandiommu=ptparameters:# grubby --args="intel_iommu=on iommu=pt" --update-kernel=ALL- Reboot the host.
On an AMD host, enable AMD-Vi:
Regenerate the GRUB configuration with the
iommu=ptparameter:# grubby --args="iommu=pt" --update-kernel=ALL- Reboot the host.
On an ARM 64 host, the required SMMU feature is enabled by default. For better performance, configure also the
iommu=ptparameter:Regenerate the GRUB configuration with the
iommu=ptparameter:# grubby --args="iommu=pt" --update-kernel=ALL- Reboot the host.
Procedure
Optional: Confirm the maximum number of VFs your network device can use. To do so, use the following command and replace eth1 with your SR-IOV compatible network device.
# cat /sys/class/net/eth1/device/sriov_totalvfs 7Use the following command to create a virtual function (VF):
# echo VF-number > /sys/class/net/network-interface/device/sriov_numvfsIn the command, replace:
- VF-number with the number of VFs you want to create on the PF.
- network-interface with the name of the network interface for which the VFs will be created.
The following example creates 2 VFs from the eth1 network interface:
# echo 2 > /sys/class/net/eth1/device/sriov_numvfsVerify the VFs have been added:
# lspci | grep Ethernet 82:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) 82:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) 82:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)Make the created VFs persistent by creating a udev rule for the network interface you used to create the VFs. For example, for the eth1 interface, create the
/etc/udev/rules.d/eth1.rulesfile, and add the following line:ACTION=="add", SUBSYSTEM=="net", ENV{ID_NET_DRIVER}=="ixgbe", ATTR{device/sriov_numvfs}="2"This ensures that the two VFs that use the
ixgbedriver will automatically be available for theeth1interface when the host starts. If you do not require persistent SR-IOV devices, skip this step.WarningCurrently, the previously described setting does not work correctly when attempting to make VFs persistent on Broadcom NetXtreme II BCM57810 adapters. In addition, attaching VFs based on these adapters to Windows VMs is currently not reliable.
Hot plug one of the newly added VF interface devices to a running VM.
# virsh attach-interface <vm_name> hostdev 0000:82:10.0 --mac 52:54:00:00:01:01 --managed --live --configThe
--liveoption attaches the device to a running VM, without persistence between boots. The--configoption makes the configuration changes persistent. To attach the device to a shut down VM, do not use the--liveoption.The
--macoption specifies a MAC address for the attached interface. If you do not specify a MAC address for the interface, the VM automatically generates a permanent, pseudorandom address that begins with 52:54:00.ImportantIf you assign an SR-IOV VF to a virtual machine by manually adding a device entry to the <hostdev> section of your VM’s XML configuration file, the MAC address is not permanently assigned and network settings in the guest usually need to be reconfigured on every host reboot.
To avoid these complications, use the
virsh attach-interfacecommand as described in this step.
Verification
- If the procedure is successful, the guest operating system detects a new network interface controller.
15.7.3. Supported devices for SR-IOV assignment Copier lienLien copié sur presse-papiers!
Not all devices can be used for SR-IOV. The following devices have been tested and verified as compatible with SR-IOV in RHEL 10.
Networking devices
-
Intel 82599ES 10 Gigabit Ethernet Controller - uses the
ixgbedriver -
Intel Ethernet Controller XL710 Series - uses the
i40edriver -
Intel Ethernet Network Adapter XXV710 - uses the
i40edriver -
Intel 82576 Gigabit Ethernet Controller - uses the
igbdriver -
Broadcom NetXtreme II BCM57810 - uses the
bnx2xdriver -
Ethernet Controller E810-C for QSFP - uses the
icedriver -
SFC9220 10/40G Ethernet Controller - uses the
sfcdriver -
FastLinQ QL41000 Series 10/25/40/50GbE Controller - uses the
qededriver - Mellanox MT27710 Ethernet Adapter Cards
- Mellanox MT2892 Family [ConnectX-6 Dx]
- Mellanox MT2910 [ConnextX-7]
15.8. Booting virtual machines from a PXE server Copier lienLien copié sur presse-papiers!
Virtual machines (VMs) that use Preboot Execution Environment (PXE) can boot and load their configuration from a network. You can use libvirt to boot VMs from a PXE server on a virtual or bridged network.
The following procedures are provided only as examples. Ensure that you have sufficient backups before proceeding.
15.8.1. Setting up a PXE boot server on a virtual network Copier lienLien copié sur presse-papiers!
To configure virtual machines on your host to boot from a boot image available on the virtual network, you must configure a libvirt virtual network to provide Preboot Execution Environment (PXE).
Prerequisites
A local PXE server (DHCP and TFTP), such as:
- libvirt internal server
- manually configured dhcpd and tftpd
- dnsmasq
- Cobbler server
-
PXE boot images, such as
PXELINUXconfigured by Cobbler or manually.
Procedure
-
Place the PXE boot images and configuration in
/var/lib/tftpbootfolder. Set folder permissions:
# chmod -R a+r /var/lib/tftpbootSet folder ownership:
# chown -R nobody: /var/lib/tftpbootUpdate SELinux context:
# chcon -R --reference /usr/sbin/dnsmasq /var/lib/tftpboot # chcon -R --reference /usr/libexec/libvirt_leaseshelper /var/lib/tftpbootShut down the virtual network:
# virsh net-destroy defaultOpen the virtual network configuration file in your default editor:
# virsh net-edit defaultEdit the
<ip>element to include the appropriate address, network mask, DHCP address range, and boot file, where example-pxelinux is the name of the boot image file.<ip address='192.0.2.1' netmask='255.255.255.0'> <tftp root='/var/lib/tftpboot'/> <dhcp> <range start='192.0.2.2' end='192.0.2.254' /> <bootp file='example-pxelinux'/> </dhcp> </ip>Start the virtual network:
# virsh net-start default
Verification
Verify that the
defaultvirtual network is active:# virsh net-list Name State Autostart Persistent --------------------------------------------------- default active no no
15.8.2. Booting virtual machines by using PXE and a virtual network Copier lienLien copié sur presse-papiers!
To boot virtual machines (VMs) from a Preboot Execution Environment (PXE) server available on a virtual network, you must enable PXE booting.
Prerequisites
- A PXE boot server is set up on the virtual network as described in Setting up a PXE boot server on a virtual network.
Procedure
Create a new VM with PXE booting enabled. For example, to install from a PXE, available on the
defaultvirtual network, into a new 10 GB QCOW2 image file:# virt-install --pxe --network network=default --memory 2048 --vcpus 2 --disk size=10Alternatively, you can manually edit the XML configuration file of an existing VM. To do so, ensure the guest network is configured to use your virtual network and that the network is configured to be the primary boot device:
<interface type='network'> <mac address='52:54:00:66:79:14'/> <source network='default'/> <target dev='vnet0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> <boot order='1'/> </interface>
Verification
-
Start the VM by using the
virsh startcommand. If PXE is configured correctly, the VM boots from a boot image available on the PXE server.
15.8.3. Booting virtual machines by using PXE and a bridged network Copier lienLien copié sur presse-papiers!
To boot virtual machines (VMs) from a Preboot Execution Environment (PXE) server available on a bridged network, you must enable PXE booting.
Prerequisites
- Network bridging is enabled.
- A PXE boot server is available on the bridged network.
Procedure
Create a new VM with PXE booting enabled. For example, to install from a PXE, available on the
breth0bridged network, into a new 10 GB QCOW2 image file:# virt-install --pxe --network bridge=breth0 --memory 2048 --vcpus 2 --disk size=10Alternatively, you can manually edit the XML configuration file of an existing VM. To do so, ensure that the VM is configured with a bridged network and that the network is configured to be the primary boot device:
<interface type='bridge'> <mac address='52:54:00:5a:ad:cb'/> <source bridge='breth0'/> <target dev='vnet0'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> <boot order='1'/> </interface>
Verification
-
Start the VM by using the
virsh startcommand. If PXE is configured correctly, the VM boots from a boot image available on the PXE server.
15.9. Configuring externally visible virtual machines Copier lienLien copié sur presse-papiers!
In many scenarios, the default virtual machine (VM) networking configuration is sufficient. However, if you need to adjust the configuration for your VMs to become reachable from external systems, you can use the command line (CLI) or the RHEL 10 web console.
15.9.1. Configuring externally visible virtual machines by using the command line Copier lienLien copié sur presse-papiers!
If you require a virtual machine (VM) to appear on the same external network as the hypervisor, you must use bridged mode. To do so, attach the VM to a bridge device connected to the hypervisor’s physical network device.
By default, a newly created VM connects to a NAT-type network that uses virbr0, the default virtual bridge on the host. This ensures that the VM can use the host’s network interface controller (NIC) for connecting to outside networks, but the VM is not reachable from external systems.
Prerequisites
- A shut-down existing VM with the default NAT setup.
The IP configuration of the hypervisor. This varies depending on the network connection of the host. As an example, this procedure uses a scenario where the host is connected to the network by using an ethernet cable, and the hosts' physical NIC MAC address is assigned to a static IP on a DHCP server. Therefore, the ethernet interface is treated as the hypervisor IP.
To obtain the IP configuration of the ethernet interface, use the
ip addrutility:# ip addr [...] enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 54:ee:75:49:dc:46 brd ff:ff:ff:ff:ff:ff inet 192.0.2.1/24 brd 192.0.2.255 scope global dynamic noprefixroute enp0s25
Procedure
Create and set up a bridge connection for the physical interface on the host. For instructions, see the Configuring a network bridge.
Note that in a scenario where static IP assignment is used, you must move the IPv4 setting of the physical ethernet interface to the bridge interface.
Modify the VM’s network to use the created bridged interface. For example, the following sets testguest to use bridge0.
# virt-xml testguest --edit --network bridge=bridge0 Domain 'testguest' defined successfully.Start the VM.
# virsh start testguestIn the guest operating system, adjust the IP and DHCP settings of the system’s network interface as if the VM was another physical system in the same network as the hypervisor.
The specific steps for this differ depending on the guest operating system used by the VM. For example, if the guest operating system is RHEL 10, see Configuring an Ethernet connection.
Verification
Ensure the newly created bridge is running and contains both the host’s physical interface and the interface of the VM.
# ip link show master bridge0 2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bridge0 state UP mode DEFAULT group default qlen 1000 link/ether 54:ee:75:49:dc:46 brd ff:ff:ff:ff:ff:ff 10: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bridge0 state UNKNOWN mode DEFAULT group default qlen 1000 link/ether fe:54:00:89:15:40 brd ff:ff:ff:ff:ff:ffEnsure the VM is displayed on the same external network as the hypervisor:
In the guest operating system, obtain the network ID of the system. For example, if it is a Linux guest:
# ip addr [...] enp0s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:09:15:46 brd ff:ff:ff:ff:ff:ff inet 192.0.2.1/24 brd 192.0.2.255 scope global dynamic noprefixroute enp0s0From an external system connected to the local network, connect to the VM by using the obtained ID.
# ssh root@192.0.2.1 root@192.0.2.1's password: Last login: Mon Sep 24 12:05:36 2019 root~#*If the connection works, the network has been configured successfully.
Troubleshooting
In certain situations, such as when using a client-to-site VPN while the VM is hosted on the client, using bridged mode for making your VMs available to external locations is not possible.
To work around this problem, you can set destination NAT by using
nftablesfor the VM.
15.9.2. Configuring externally visible virtual machines by using the web console Copier lienLien copié sur presse-papiers!
If you require a VM to appear on the same external network as the hypervisor, you must use bridged mode. To do so, attach the VM to a bridge device connected to the hypervisor’s physical network device. To use the RHEL 10 web console for this, follow the instructions below.
By default, a newly created VM connects to a NAT-type network that uses virbr0, the default virtual bridge on the host. This ensures that the VM can use the host’s network interface controller (NIC) for connecting to outside networks, but the VM is not reachable from external systems.
Prerequisites
You have installed the RHEL 10 web console.
For instructions, see Installing and enabling the web console.
- The web console VM plug-in is installed on your system.
- A shut-down existing VM with the default NAT setup.
The IP configuration of the hypervisor. This varies depending on the network connection of the host. As an example, this procedure uses a scenario where the host is connected to the network by using an ethernet cable, and the hosts' physical NIC MAC address is assigned to a static IP on a DHCP server. Therefore, the ethernet interface is treated as the hypervisor IP.
To obtain the IP configuration of the ethernet interface, go to the
Networkingtab in the web console, and see theInterfacessection.
Procedure
Create and set up a bridge connection for the physical interface on the host. For instructions, see Configuring network bridges in the web console.
Note that in a scenario where static IP assignment is used, you must move the IPv4 setting of the physical ethernet interface to the bridge interface.
Modify the VM’s network to use the bridged interface. In the Network Interfaces tab of the VM:
- Click
In the
Add Virtual Network Interfacedialog, set:-
Interface Type to
Bridge to LAN -
Source to the newly created bridge, for example
bridge0
-
Interface Type to
- Click
- Optional: Click for all the other interfaces connected to the VM.
- Click to start the VM.
In the guest operating system, adjust the IP and DHCP settings of the system’s network interface as if the VM was another physical system in the same network as the hypervisor.
The specific steps for this will differ depending on the guest operating system used by the VM. For example, if the guest operating system is RHEL 10, see Configuring an Ethernet connection.
Verification
- In the Networking tab of the host’s web console, click the row with the newly created bridge to ensure it is running and contains both the host’s physical interface and the interface of the VM.
Ensure the VM is displayed on the same external network as the hypervisor.
In the guest operating system, obtain the network ID of the system. For example, if it is a Linux guest:
# ip addr [...] enp0s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:09:15:46 brd ff:ff:ff:ff:ff:ff inet 192.0.2.1/24 brd 192.0.2.255 scope global dynamic noprefixroute enp0s0From an external system connected to the local network, connect to the VM by using the obtained ID.
# ssh root@192.0.2.1 root@192.0.2.1's password: Last login: Mon Sep 24 12:05:36 2019 root~#*If the connection works, the network has been configured successfully.
Troubleshooting
- In certain situations, such as when using a client-to-site VPN while the VM is hosted on the client, using bridged mode for making your VMs available to external locations is not possible.
15.9.3. Replacing macvtap connections Copier lienLien copié sur presse-papiers!
Using macvtap connections is supported in RHEL 10. However, in comparison to other available virtual machine (VM) networking configurations, macvtap has suboptimal performance and is more difficult to set up correctly. If your use case does not explicitly require macvtap, use a different supported networking configuration.
macvtap is a Linux networking device driver that creates a virtual network interface, through which VMs have direct access to the physical network interface on the host machine. If you are using a macvtap mode in your VM, consider instead using the following network configurations:
- Instead of macvtap bridge mode, use the Linux bridge configuration.
- Instead of macvtap passthrough mode, use PCI Passthrough.
15.10. Configuring bridges on a network bond to connect virtual machines with the network Copier lienLien copié sur presse-papiers!
The network bridge connects virtual machines (VMs) with the same network as the host. If you want to connect VMs on one host to another host or to VMs on another host, a bridge establishes communication between them. However, the bridge does not provide a fail-over mechanism.
To handle failures in communication, a network bond handles communication in case of failure of a network interface. To maintain fault tolerance and redundancy, the active-backup bonding mechanism determines that only one port is active in the bond and does not require any switch configuration. If an active port fails, an alternate port becomes active to retain communication between configured VMs in the network.
15.10.1. Configuring network interfaces on a network bond by using nmcli Copier lienLien copié sur presse-papiers!
To configure a network bond on the command line, use the nmcli utility.
Prerequisites
-
Two or more physical network devices are installed on the server, and they are not configured in any
NetworkManagerconnection profile.
Procedure
Create a bond interface:
# nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup"This command creates a bond named
bond0that uses theactive-backupmode.Assign the Ethernet interfaces to the bond:
# nmcli connection add type ethernet slave-type bond con-name bond0-port1 ifname enp7s0 master bond0 # nmcli connection add type ethernet slave-type bond con-name bond0-port2 ifname enp8s0 master bond0These commands create profiles for
enp7s0andenp8s0, and add them to thebond0connection.Configure the IPv4 settings:
- To use DHCP, no action is required.
To set a static IPv4 address, network mask, default gateway, and DNS server to the
bond0connection, enter:# nmcli connection modify bond0 ipv4.addresses 192.0.2.1/24 ipv4.gateway 192.0.2.254 ipv4.dns 192.0.2.253 ipv4.dns-search example.com ipv4.method manual
Configure the IPv6 settings:
- To use stateless address autoconfiguration (SLAAC), no action is required.
To set a static IPv6 address, network mask, default gateway, and DNS server to the
bond0connection, enter:# nmcli connection modify bond0 ipv6.addresses 2001:db8:1::1/64 ipv6.gateway 2001:db8:1::fffe ipv6.dns 2001:db8:1::fffd ipv6.dns-search example.com ipv6.method manual
Optional: If you want to set any parameters on the bond ports, use the following command:
# nmcli connection modify bond0-port1 bond-port.<parameter> <value>Configure that Red Hat Enterprise Linux enables all ports automatically when the bond is enabled:
# nmcli connection modify bond0 connection.autoconnect-ports 1Activate the bridge:
# nmcli connection up bond0
Verification
Temporarily remove the network cable from the host.
Note that there is no method to properly test link failure events using software utilities. Tools that deactivate connections, such as nmcli, show only the bonding driver’s ability to handle port configuration changes and not actual link failure events.
Display the status of the bond:
# cat /proc/net/bonding/bond0
15.10.2. Configuring a network bridge for network bonds by using nmcli Copier lienLien copié sur presse-papiers!
To create a network bridge for network bonds, configure a bond interface that combines multiple network interfaces for improved traffic handling. As a result, VMs can use the network bridge to access the network through the bonded network interfaces. To configure this, you can use the nmcli utility.
Prerequisites
- You have created and configured a network bond. For instructions, see Configuring network interfaces on a network bond by using nmcli
Procedure
Create a bridge interface:
# nmcli connection add type bridge con-name br0 ifname br0 ipv4.method disabled ipv6.method disabledAdd the
bond0bond to thebr0bridge:# nmcli connection modify bond0 master br0Configure that Red Hat Enterprise Linux enables all ports automatically when the bridge is enabled:
# nmcli connection modify br0 connection.autoconnect-ports 1Reactivate the bridge:
# nmcli connection up br0
Verification
Use the
iputility to display the link status of Ethernet devices that are ports of a specific bridge:# ip link show master br0 6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:38:a9:4d brd ff:ff:ff:ff:ff:ff ...Use the
bridgeutility to display the status of Ethernet devices that are ports of any bridge device:# bridge link show 6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100 ...To display the status for a specific Ethernet device, use the
bridge link show dev <ethernet_device_name>command.
15.10.3. Creating a virtual network in libvirt with an existing bond interface Copier lienLien copié sur presse-papiers!
To enable virtual machines (VM) to use the br0 bridge with the bond, first add a virtual network to the libvirtd service that uses this bridge.
Prerequisites
-
You installed the
libvirtpackage. -
You started and enabled the
libvirtdservice. -
You configured the
br0device with the bond on Red Hat Enterprise Linux. For instructions, see Configuring a network bridge for network bonds by using nmcli.
Procedure
Create the
~/bond0-bridge.xmlfile with the following content:<network> <name>bond0-bridge</name> <forward mode="bridge" /> <bridge name="br0" /> </network>Use the
~/bond0-bridge.xmlfile to create a new virtual network inlibvirt:# virsh net-define ~/bond0-bridge.xmlRemove the
~/bond0-bridge.xmlfile:# rm ~/bond0-bridge.xmlStart the
bond0-bridgevirtual network:# virsh net-start bond0-bridgeConfigure the
bond0-bridgevirtual network to start automatically when thelibvirtdservice starts:# virsh net-autostart bond0-bridge
Verification
Display the list of virtual networks:
# virsh net-list Name State Autostart Persistent ---------------------------------------------------- bond0-bridge active yes yes ...
15.10.4. Configuring virtual machines to use a bond interface Copier lienLien copié sur presse-papiers!
To configure a VM to use a bridge device with a bond interface on the host, create a new VM that uses the bond0-bridge virtual network or update the settings of existing VMs to use this network.
Perform this procedure on the RHEL hosts.
Prerequisites
-
You configured the
bond0-bridgevirtual network inlibvirtd. For instructions, see Creating a virtual network in libvirt with an existing bond interface.
Procedure
To create a new VM and configure it to use the
bond0-bridgenetwork, pass the--network network:bond0-bridgeoption to thevirt-installutility when you create the VM:# virt-install ... --network network:bond0-bridgeTo change the network settings of an existing VM:
Connect the VM’s network interface to the
bond0-bridgevirtual network:# virt-xml <example_vm> --edit --network network=bond0-bridge
Shut down the VM, and start it again:
# virsh shutdown <example_vm> # virsh start <example_vm>
Verification
Display the virtual network interfaces of the VM on the host:
# virsh domiflist <example_vm> Interface Type Source Model MAC ------------------------------------------------------------------- vnet1 bridge bond0-bridge virtio 52:54:00:c5:98:1cDisplay the interfaces attached to the
br0bridge:# ip link show master br0 18: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 2a:53:bd:d5:b3:0a brd ff:ff:ff:ff:ff:ff 19: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 52:54:00:c5:98:1c brd ff:ff:ff:ff:ff:ff ...Note that the
libvirtdservice dynamically updates the bridge’s configuration. When you start a VM which uses thebond0-bridgenetwork, the correspondingvnet*device on the host is displayed as a port of the bridge.
15.11. Configuring the passt user-space connection Copier lienLien copié sur presse-papiers!
If you require non-privileged access to a virtual network, for example when using a session connection of libvirt, you can configure your virtual machine (VM) to use the passt networking back end.
Prerequisites
The
passtpackage has been installed on your system.# dnf install passt
Procedure
Open the XML configuration of the VM on which you want to use a
passtconnection. For example:# virsh edit <testguest1>In the
<devices>section, add an<interface type='user'>element that usespasstas its backend type.For example, the following configuration sets up a
passtconnection that uses addresses and routes copied from the host interface associated with the first default route:<devices> [...] <interface type='user'> <backend type='passt'/> </interface> </devices>Optionally, when using
passt, you can specify multiple<portForward>elements to forward incoming network traffic for the host to this VM interface. You can also customize interface IP addresses. For example:<devices> [...] <interface type='user'> <backend type='passt'/> <mac address="52:54:00:98:d8:b7"/> <source dev='eth0'/> <ip family='ipv4' address='192.0.2.1' prefix='24'/> <ip family='ipv6' address='::ffff:c000:201'/> <portForward proto='tcp'> <range start='2022' to='22'/> </portForward> <portForward proto='udp' address='1.2.3.4'> <range start='5000' end='5020' to='6000'/> <range start='5010' end='5015' exclude='yes'/> </portForward> <portForward proto='tcp' address='2001:db8:ac10:fd01::1:10' dev='eth0'> <range start='8080'/> <range start='4433' to='3444'/> </portForward> </interface> </devices>This example configuration sets up a
passtconnection with the following parameters:-
The VM copies the network routes for forwarding traffic from the
eth0host interface. -
The interface MAC is set to
52:54:00:98:d8:b7. If unset, a random one will be generated. -
The IPv4 address is set to
192.0.2.1/24, and the IPv6 address is set to::ffff:c000:201. -
The TCP port
2022on the host forwards its network traffic to port22on the VM. -
The TCP address
2001:db8:ac10:fd01::1:10on host interfaceeth0and port8080forwards its network traffic to port8080on the VM. Port4433forwards to port3444on the VM. -
The UDP address
1.2.3.4and ports5000 - 5009and5016 - 5020on the host forward their network traffic to ports6000 - 6009and6016 - 6020on the VM.
-
The VM copies the network routes for forwarding traffic from the
- Save the XML configuration.
Verification
Start or restart the VM you configured with
passt:# virsh reboot <vm-name> # virsh start <vm-name>If the VM boots successfully, it is now using the
passtnetworking back end.