I am posting this as a completely new thread although it’s written as a continuation of a couple recent other threads titled “Bridging is broken on virt-manager” and “Beginning with KVM” because this topic about virtualization networking is an independent topic and although this is written mainly for libvirt KVM/Xen/LXC Users, is almost completely applicable to Users of VBox, VMware, Hyper-V and many other virtualization technologies as well.
As I mentioned in one of my links to my earlier criticisms of the current community openSUSE virtualization documentation, this is one of the areas which IMO was lacking. And, most current SLES documentation which describes virtual networking is rather brief and generally not complete… something that might be helpful for someone with prior experience with other virtualization but not likely enough for someone brand new. The following is all off the top of my head and is not double-checked against other sources for accuracy, so as usual “Use at your own Risk” and maybe people will submit succeeding posts that will correct, clarify or ask for more about what follows.
Let me first fill in some gaps in the** KVM reference**(https://www.linux-kvm.org/page/Networking) since it’s the only one mentioned in a post in this thread up to this point.
The reference describes several types of networking, but doesn’t do so in simple, common terms that people might recognize.
First is SLIRP.
Although listed first, it’s not often used.
This is the primary means of configuring networking if you were running User Mode Linux (UML). For those who want to explore basics, I encourage looking into this. It’s very simple to set up and execute, but I probably wouldn’t run it for more than educational purposes… You don’t need to install anything new, but you may want to download a kernel you want to use for your “machine.”
The Private Virtual Bridge and Public Virtual Bridge
These are used in probably over 99% of all virtualization technologies granting Guests networking functionality. The “Private Virtual Bridge” is probably more easily recognized as “Host Only” networking in VBox, VMware and Hyper-V. The “Public Virtual Bridge” can be configured a number of ways, as bridging(The traditional definition where the supported ip network is the same as the existing interface) and NAT (possible variations included). Note the warning about the Public Virtual Bridge and wireless interfaces in the KVM documentation! That is where the MacVtap can be implemented instead.
Is a relatively new type of virtual networking.
But since today the above “virtual networking bridge” aka Linux Bridge Devices aks ?? (you might find this described many ways in different documentation) is almost always used, VDE should not be important unless you have a special need.
An additional useful general concept is that you can usually recognize and determine the origin of networking devices you’re displaying or connecting to by its name… Note that no matter how a virtual networking bridge device is name and by what it was created, it’s the <same thing>
Physical Devices - Names like eth0, wlan0, eppl0
Bridging Devices created by YaST, brctl, other standard tools - Names like br0, br2
Bridging Devices created by libvirt - Names like virbr0, virbr2
Bridging Devices created by VMware - Names like VMnet0, VMnet2
Bridging Devices created by VBox - Unknown, on my personal machine VBox looks like it’s running virtual networking bridge devices supporting IPv4 networking on top of HostOS Ipv6 interfaces
Now that the above has been gotten out of the way, for those who are experienced virtualization Users with experience in other technologies should have a leg up on understanding what is typically configured and might be able to just open vm manager, create a virtual network and recognize familiar stuff without needing more explanation.
For the newbies and people who haven’t paid any attention to virtual networks and virtualization bridge devices, read on. The following might serve as a first draft for something with more thought later on…
The Network Bridge Device (aka virtualization bridge device, bridge device, etc)
Goes by many names, but is the way you set up networking in practically every known type of virtualization and isolation on top of every major OS including Windows and Unix. Notable exceptions are UML and Docker although I suspect that those can also be configured this way if you dig beyond the standard documentation.
Although to the new User this might seem like an extra complication, it’s actually not because it solves a number of problems and gives you powerful options compared to accessing the network interface directly (which you would do if you configured SLIRP or MacVtap).
And, it should be recognized that libvirt like practically everywhere else will automatically set up and manage your Guests configured to use virtual networks that implement the described virtual networking bridge devices.
Network bridge devices should not be confused with configuring a network interface in bridging mode…
- A Network bridge device is a networking component that stands on its own and is bound to at least one networking interface.
. A network bridging mode configuration is not a separate component, it’s a standard configuration of a network interface (which can be physical or virtual) which results in the device or machine becomes invisible on the network. So, for instance a multi-homed machine’s network interfaces connecting to two differnt physical networks in which the NetworkID is the same, so the machine is acting as a “network bridge” instead of a router which would require the networks to have different NetworkIDs. In the case of virtual bridge devices, this would mean that the virtual machine is seen and communicates with other remote machines like any ordinary physical or non-physical machine on the network.
Common ways a network bridge device is configured
As a completely separate and independent component, it can optionally define an entire virtual network internally, and possibly provide network services like DHCP to that virtual network without having to install and configure a full blown DHCP server.
Typical and common configurations include
Bridging - Seen and communicates on the regular physical network with physical and virtual machines both on the same HostOS and remotes on other physical machines.
Host-Only- A virtual network in which only virtual machines on the same physical machine can communicate with each other.
NAT - A private network. Essentially similar to a Host-Only network but with a defined DG to access the physical network. Optionally, DHCP services can be provided to the virtual network.
When a network bridge device is bound to the network interface, depending on how it’s created and configured, the HostOS may lose access to the physical interface. The simple solution in this case is to re-configure the Host to use a bridging device configured for network bridging functionality (The typical default configuration for br0).
Creating a virtual network bridging device
This is the best way to do this, because unlike others you are walked through a graphical “wizard” of configuration steps to complete your task. There are very few ways you can make a mistake doing this and there is almost no way to create a conflicting device.
Just create a new device, specifying a “bridge” type.
If you’re trying to replicate the bridge device normally set up when using YaST to install virtualization, configure it as a DHCP client.
Do not remove the physical interface as recommended in a prior post in this thread…
Sorry, I don’t generally do this… Maybe if I was on some other distro than openSUSE, but one of the nice things about using openSUSE is that we can ignore a lot of things that are required. I do run brctl often to display bridge device information though and recommend Users become familiar with this use.
Configuring Networking for a new Install
When running virt-install which is part of libvirt, on the last screen before the install configuration ends, you will be presented with a dropdown populated with choices for any virtual networks that are available(ie configured virtual networking bridge devices), MacVtap or custom other…
If you configured your virtual networking first, you’ll have more options so I highly recommend reviewing your existing virtual networks before you create your first VM, and if necessary create any new networks you may need.
But, there is no requirement for creating virtual networks first.
It’s easy to switch virtual networks later and can even be done while the Guest is running.
HTH and as stated in the beginning…
Corrections and suggested rewording, and questions about what is described in this post is welcomed and requested.