From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id AB1EC94FA5 for ; Thu, 11 Apr 2024 16:21:40 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 9425532B49 for ; Thu, 11 Apr 2024 16:21:40 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Thu, 11 Apr 2024 16:21:39 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 53D0744A29 for ; Thu, 11 Apr 2024 16:21:39 +0200 (CEST) Date: Thu, 11 Apr 2024 16:21:35 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion References: <20240229104104.111188-1-s.hanreich@proxmox.com> <20240229104104.111188-3-s.hanreich@proxmox.com> In-Reply-To: <20240229104104.111188-3-s.hanreich@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1712844152.n48q89yisj.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.057 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH v3 docs 2/6] network: update specification for bridge names X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2024 14:21:40 -0000 On February 29, 2024 11:41 am, Stefan Hanreich wrote: > Signed-off-by: Stefan Hanreich > --- > pve-network.adoc | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) >=20 > diff --git a/pve-network.adoc b/pve-network.adoc > index d1ec64b..a5ad9b4 100644 > --- a/pve-network.adoc > +++ b/pve-network.adoc > @@ -13,11 +13,12 @@ page contains the complete format description. All {p= ve} tools try hard to keep > direct user modifications, but using the GUI is still preferable, becaus= e it > protects you from errors. > =20 > -A 'vmbr' interface is needed to connect guests to the underlying physica= l > -network. They are a Linux bridge which can be thought of as a virtual s= witch > -to which the guests and physical interfaces are connected to. This sect= ion > -provides some examples on how the network can be set up to accomodate di= fferent > -use cases like redundancy with a xref:sysadmin_network_bond['bond'], > +A bridge interface (commonly called 'vmbrX') is needed to connect guests= to the > +underlying physical network. They are a Linux bridge which can be thoug= ht of as both pre-existing, but while we are here: doubled space before the 'They' "*A* bridge interface .. *They* are.." I'd just combine the two? A Linux bridge interface .. . It can be though .. > +a virtual switch to which the guests and physical interfaces are connect= ed to. also pre-existing:=20 the first 'to' here can go IMHO ;) a virtual switch which the .. are connected to. > +This section provides some examples on how the network can be set up to > +accomodate different use cases like redundancy with a > +xref:sysadmin_network_bond['bond'], > xref:sysadmin_network_vlan['vlans'] or > xref:sysadmin_network_routed['routed'] and > xref:sysadmin_network_masquerading['NAT'] setups. > @@ -75,7 +76,9 @@ We currently use the following naming conventions for d= evice names: > scheme is used for {pve} hosts which were installed before the 5.0 > release. When upgrading to 5.0, the names are kept as-is. > =20 > -* Bridge names: `vmbr[N]`, where 0 =E2=89=A4 N =E2=89=A4 4094 (`vmbr0` -= `vmbr4094`) > +* Bridge names: Commonly `vmbr[N]`, where 0 =E2=89=A4 N =E2=89=A4 4094 (= `vmbr0` - `vmbr4094`), > +but you can use any alphanumeric string that starts with a character and= is at > +most 10 characters long. > =20 > * Bonds: `bond[N]`, where 0 =E2=89=A4 N (`bond0`, `bond1`, ...)