Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Here's an alternate that uses some of your text with a lot of additions/subtractions:
A virtual guest's connection to any network is via software network components on the physical host. These software components can be rearranged and reconfigured via libvirt's virtual network configuration, so the host can be thought of as a virtual network switch that can be configured in many different ways to fit the guest's networking needs.
By default, all guests on a single host are connected to the same libvirt virtual network (aptly named "default"). Guests on this network can all make connections with each other (bidirectional, modulo any firewalls in the guest OS' network stack or libvirt nwfilter rules attached to the guest interface), with the virtualization host (also bidirectional modulo any fireall rules), and with other hosts on the network beyond the virtualization host (outbound only, via Network Address Translation (NAT) rules added to the host system firewall).
If needed, guest interfaces can instead be connected to:
* a network that doesn't allow any traffic beyond the virtualization host
(referred to in some documentation as "isolated" mode).
* a network that routes traffic between the guest and external hosts without
performing any NAT (this allows for incoming connections but requires extra
routing table entries for sytems on the external network. This is called
"route" mode in libvirt's virtual network configuration and documentation)
* a bridge device that is also connected directly to a physical
ethernet device which is connected to the local ethernet, making the
guest directly visible on the physical network (this also allows incoming
connections, but doesn't require any extra routing table entries. It is
referred to in documentation as "bridged mode")
For simple outbound-only network access from virtual machines, no additional network setup should be needed, as the network named "default" is installed along with libvirt, and automatically started when the libvirt service is started. If more advanced functionality is needed, additional networks can be created and configured using either virsh or virt-manager, and the guest XML configuration file can be edited to use one of these new networks.
From the point of view of the guest OS, a virtual network connection is no different from a normal physical network connection. For further information on configuring networks in RHEL7 guests, see the Red Hat Enterprise Linux 7 Networking Guide.
Here's an alternate that uses some of your text with a lot of additions/subtractions: A virtual guest's connection to any network is via software network components on the physical host. These software components can be rearranged and reconfigured via libvirt's virtual network configuration, so the host can be thought of as a virtual network switch that can be configured in many different ways to fit the guest's networking needs. By default, all guests on a single host are connected to the same libvirt virtual network (aptly named "default"). Guests on this network can all make connections with each other (bidirectional, modulo any firewalls in the guest OS' network stack or libvirt nwfilter rules attached to the guest interface), with the virtualization host (also bidirectional modulo any fireall rules), and with other hosts on the network beyond the virtualization host (outbound only, via Network Address Translation (NAT) rules added to the host system firewall). If needed, guest interfaces can instead be connected to: * a network that doesn't allow any traffic beyond the virtualization host (referred to in some documentation as "isolated" mode). * a network that routes traffic between the guest and external hosts without performing any NAT (this allows for incoming connections but requires extra routing table entries for sytems on the external network. This is called "route" mode in libvirt's virtual network configuration and documentation) * a bridge device that is also connected directly to a physical ethernet device which is connected to the local ethernet, making the guest directly visible on the physical network (this also allows incoming connections, but doesn't require any extra routing table entries. It is referred to in documentation as "bridged mode") For simple outbound-only network access from virtual machines, no additional network setup should be needed, as the network named "default" is installed along with libvirt, and automatically started when the libvirt service is started. If more advanced functionality is needed, additional networks can be created and configured using either virsh or virt-manager, and the guest XML configuration file can be edited to use one of these new networks. From the point of view of the guest OS, a virtual network connection is no different from a normal physical network connection. For further information on configuring networks in RHEL7 guests, see the Red Hat Enterprise Linux 7 Networking Guide.