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.
Bug 1010807 - [Doc] Add introduction to networking section
Summary: [Doc] Add introduction to networking section
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: doc-Virtualization_Getting_Started_Guide
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Jiri Herrmann
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On: 971231
Blocks: 1064610 1425467
TreeView+ depends on / blocked
 
Reported: 2013-09-23 06:06 UTC by Dayle Parker
Modified: 2019-03-06 01:32 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 971231
Environment:
Last Closed: 2017-03-29 17:36:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Comment 7 Laine Stump 2017-02-09 15:33:28 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.