Re: Network bridge with network-scripts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > Hi, can someone tell me if these instructions still work with fedora35
> > to build a bridge?
> >
> > https://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Guide/s2-networkscripts-interfaces_network-bridge.html
>
> In addition to Tom’s answer, with F36 it will no longer work. There is a change proposal to remove ifcfg support completely and most contributors agree with that.
>
> If you want your VMs to have access to the public network, then you have to share the host's public interface. The most convenient option is mac-vlan and to avoid a bridge. You don’t need to configure the host interface, but just the VMs to use „direct attachment“ in KVM/libvirt-speech.

This is an internet facing server only - only one interface and no
internal network. I should have mentioned the VMs (kvm) will have
their own public IPs so we don't have to reverse masq them.

> See Fedora Server documentation at https://docs.stg.fedoraproject.org/en-US/fedora-server/virtualization-vm-install-fedoraserver-cockpit/ (it’s the staging version).
>
> Konfiguration is much easier and it causes less system load. The only disadvantage is that the VMs cannot communicate directly with the host. But it is usually better to use an internal, protected network for this.

It's only an apache server, so until just now, it didn't even have
cockpit installed. So instead of just using vi to edit the text files
directly, I had to install 140+ packages to configure/enable cockpit,
lol. It does look kinda nice, though. I'm an old-school sysadmin from
before NetworkManager existed.

> If the host has a second physical interface that you want to use for an internal, protected network between VMs and the host as well as other hosts and VMs on that internal network, you have to reconfigure the second, internal network. My Fedora Server Doku is not yet ready, but you have to reconfigure the second interface as a bridge (because the VMs should be able to communicate with the host and vice versa). You man do (if is enp6s0 here)
>
> (a) create a bridge and assign it the internal physical interface. IPv4 is static, no IPv6 for internal network:
> […]# nmcli con add ifname vbr6s0 type bridge con-name vbr6s0 \
>      bridge.stp no
> […]# nmcli con mod vbr6s0 ipv4.method static \
>      ipv4.address "10.10.10.XXX/24" \
>      ipv4.gateway "10.10.10.10" \
>      ipv4.dns "10.10.10.1" \
>      ipv4.dns-search "localnet" \
>      ipv6.method disabled \
>      connection.zone "trusted"
> […]# nmcli con add ifname enp6s0 type bridge-slave \
>      master vbr6s0 con-name vbr6s0-slave-enp6s0 \
>      connection.zone "trusted"
> […]# nmcli con show vbr6s0

I'm not sure I understand this part - do I substitute my public IP for
the localnet above, or is the config different in some other way when
using public IPs and not using virbr0?

Tips on how to set it up to support a kvm/qemu instance with a public
IP would be appreciated.

Thanks,
Alex




>
> You should specify dns-search to enable systemd-resolved to resolve internal node names (i.e. not FQDN)
>
> (b)  deactivate the original physical interface and activate the bridge:
>
> […]# nmcli con down enp6s0
> […]# nmcli con up vbr6s0
> […]# nmcli con reload
>
>
> If your internal network is virtual only (w/o physical interface), it’s best to use libvirt virbr0. See Server documentation at https://docs.stg.fedoraproject.org/en-US/fedora-server/virtualization-install/ about host configuration.
> (Leave out "stg." in the url to get the current published version)
>
>
> Best
> Peter
>
>
>
> _______________________________________________
> users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux