Hello everyone,
I installed fresh RL 9.4 yesterday and it seems it was successful. Now I am going to install and configure the KVM for the guest system installation. What I did was like follows:
The very first thing I always do when setting up for VMs is to remove the virbr0 completely. I’ve never had a use case where it makes any sense to keep it. Why it’s even there by default has always baffled me.
It creates a distinct subnet for VMs and the host routes between that and external subnet, with NAT.
Analogous to VMs being machines at home LAN and the host being the “home router”.
If you “just” need to run a VM, the “default” is easy setup.
When we create a bridge on the host without the libvirt, we turn the host into network switch that extends the external subnet to the guests. VM on that bridge is “directly” on the external subnet.
Look at the log messages with: sudo journalctl -xe -u libvirtd
That does create a bridge. However, it is only for the runtime. Not stored. Not there after reboot.
Do use nmcli (or other NetworkManager tool) to create a more persistent bridge.
Yep, that’s exactly where I need them to be. My VMs need to be part of the same network as the physical machines. I’ve never had a use case where that hasn’t been the case, either at home or any of the corporate networks I’ve managed over the years.
Sweh:
thank you! It seems likely and therefore, the libvirtd inactive state should not be of any concern then. However, both commands you suggested: virsh list and virsh net-list --all returned ampty lists. Is that normal?
Ritov:
Thanks for the suggestion. I ran the find /usr/lib/systemd/ |grep virt command and it returned a full screen of filenames. What should one do about it, sorry?
Yes; virsh list shows all the running VMs. If there’s no VM defined then it’ll be empty. virsh net-list --all shows all networks defined. If you deleted the default one (as was mentioned in an earlier post) then that will also be empty.
That you didn’t get any error then it likely means it’s working properly.
Thanks! But now there is the next step… and there is no clear guidelines for it. This is about the bridge setup. I configured it using the following commands
# Create a bridge connection
sudo nmcli con add type bridge autoconnect yes ifname br0
# Add an interface to the bridge
sudo nmcli con add type bridge-slave ifname eth0 master br0
# Bring up the bridge connection
sudo nmcli con up bridge-br0
however one of the sources says I also need to add the full IP configuration by specifying IP address (which BTW?), DNS servers, and gateway IP like:
The networks you have managed. I’m in the same boat; usually manage the network and can thus hand out addresses for the guests. However, I did once use the default (routed+NAT) because I could not ask for separate address for a VM.
I don’t delete the definition of the “default”; I just disable its auto-start. It being autostarted, FirewallD, etc, seem to be convenience features for “simple use”. We could ask from Red Hat why they deem that useful.
How do you access your host? Is it local login, or remotely (via ssh)?
If it is remotely, does your host have just one network interface or many?
If you access remotely and the host has only one IP address, then changing the network config can easily leave you with no connection to the host. That would be akward.
In other words, your “admin connection” dictates how careful you have to be.
I did wrote earlier that the “bridged” setup is like a network switch. Unmanaged switches have no IP address. Guests can talk via the bridge to outside even when the host has no IP address at all.
Naturally, the host preferably does have an IP address, so that it can do things like dnf up. If the host has one interface and the interface is a “port on switch” br0, then the IP configuration must be on the br0, not on the interface.
Don’t you have DHCP server on your (external) network? DHCP is a convenient (and default) way to get the IP config. Setting config manually is rather static.
Compare:
virsh net-list --all
sudo virsh net-list --all
Regular account sees only the things that that account has started.
Root account sees only the things that root has started. (Most?) Libvirt services run as root.
Hmm, on my RL9 machine as a non-root user I see everything. Maybe because I’m in the libvirt group…
$ id
uid=500(sweh) gid=500(sweh) groups=500(sweh),0(root),10(wheel),18(dialout),494(libvirt)
$ virsh list
Id Name State
-----------------------------
1 plexserver9 running
2 pinky9 running
$ virsh net-list --all
Name State Autostart Persistent
----------------------------------------------
default inactive no yes
If it helps, here’s my network setup. It’s a little complicated because I use VLANs (10=main LAN, 11=guest, 12=IoT, 13=test) so I build 4 bridges, one for each VLAN. The naming scheme I use possibly isn’t needed any more, but it matches what it used to look like on C7, so I’m sticking with it.
Only VLAN 10 gets an IP address 'cos that’s how I access the machine.
I like the old bridge-utils for seeing things, so this is the result
% brctl show
bridge name bridge id STP enabled interfaces
br-guest 8000.b0416f0e52ab no enp1s0.11
v-pinky9-guest
br-iot 8000.b0416f0e52ab no enp1s0.12
v-pinky9-iot
br-lan 8000.b0416f0e52ab no enp1s0.10
v-pinky9
v-plexserver9
br-temp 8000.b0416f0e52ab no enp1s0.13
and
b) when I try to create a virtual machine it says “no suitable network” not obviously seeing br0 like follows
What I did while creating the interface was:
sudo nmcli con add type bridge autoconnect yes ifname br0
sudo nmcli con add type bridge-slave ifname eth0 master br0
sudo nmcli con up bridge-br0
Note: one can usually copy-paste text from terminals (and use code tags) screenshots are inconvenient.
Note2: There is one thing that nmcli can’t do on create connection and that is to bind by MAC-address (the 802-3-ethernet.mac-address); it requires ifname (aka connection.interface-name). That is not important here, where the name of interface is persistent. The interesting part is that the (Anaconda) installer creates connections that bind by MAC, rather than by name.
If you have no IPv6 in usa, then you can disable it: