KVM Kernel Virtualization Machine on Rocky Linux 9: Difference between revisions

← Older edit Newer edit →

VisualWikitext

@@ Line 44: / Line 44: @@
 The first issue is with the destruction of a perfectly network interface.  The second issue is with the creation of a Bridge Interface that was already created as part of the installation process of QEMU / KVM.  Keeping in mind this article here was written based on Rocky Linux 9 and the iteration of QEMU / KVM as of late 2023.  Earlier versions may have required the creation of a Bridge Interface.
+KEEP THIS IN MIND: In the QEMU / KVM world, here's how the networking thing functions:
+* After installing QEMU / KVM, it creates a Virtual Bridge Adapter intended to be used with NAT.  Leave this one as is if you want to use it.  But if you just want a simple bridge to connect to the rest of your network, keep reading.  This Virtual Bridge
+Here's the assumption (unlike all the other tutorials there);
+* There is an existing Ethernet Adapter on the Host Machine for QEMU / KVM that has been configured with an IP Address, Subnet Mask, IE, everything needed to communicate via a Network.
+* During the installation for QEMU / KVM, a Virtual Bridge Adapter was automatically configured
+OK, here's what to do for creating your own Virtual Bridge Adapter to be used for 'bridging' between your existing network and the Virtual Machine;
+* Identify Ethernet Adapter and Virtual Bridge to be used, IE, get their names (eth0, enp1s0of0, virbr0, etc.) using these commands: brctl show AND / OR ip link show
+* Disable the ''existing'' Ethernet Adapter (through GUI or command line).  Don't delete it as most tutorials would have you do (if needed you can always enable it later instead of re-creating it from scratch)
+** nmcli connection modify WhatEverConnectionName connection.autoconnect "no"
+** ifconfig WhatEverConnectionName down OR ip link set dev WhatEverConnectionName down
+* nmcli connection add type bridge autoconnect yes con-name virbr1 ifname virbr1
+* Other example NMCLI commands;
+** nmcli connection show
+** Modify the /etc/NetworkManager/system-connections File?  Nope!
+*** nmcli connection modify WhatEverConnectionName ipv4.address "WhatEverIPAddress/SubnetMaskNumber" (192.168.1.1/24)
+*** nmcli connection up WhatEverConnectionName (essentially restarts the adapter and adopts new configuration information)
+*** Does NOT work as one might think to 'reload' or restart a Network Adapter after configuration changes are made: nmcli connection reload
+*** nmcli connection show WhatEverConnectionName (ipv4.address = configured value AND IPV4.ADDRESS = "live / actual value")
+** systemctl restart NetworkManager
+*
 '''Tricks, Tips, and Other Useful Information (all of which applies to Rocky Linux 9, and others based on Red Hat)'''
 *Rocky Linux 9 Network Configuration Files Directory: /etc/Network/Manager/system-connections (NOT /etc/sysconfig/network-scripts)
+*Network Configuration: nm-connection-editor
+*If a Bridged Network Adapter is configured for a Virtual Machine, it will show up in the Host Machine as: vnet1, etc.
 *QEMU / KVM Configuration Files: /etc/libvirt/qemu/
 **Heed the warning notes on some of these files as they should not be edited directly.  Although a workaround is to edit the files directly, then restart the libvirtd.service (systemctl restart libvirtd.service)
@@ Line 63: / Line 91: @@
 *Network Remapping End Result(s) (IE, if you want to see how the "Predictable Network Interface Naming" decided on how things were to be done: /sys/class/net
 **In short, here's how it goes with Rocky Linux 9 mapping a physical Network Adapter to a configuration file;
 ***Physical Network Adapter (represented by files located in /sys/devices and below / down)
 ***⇌
 ***Calculations done in the name of "Predictable Network Interface Naming", whose 'scripts' are located in /lib/udev/rules.d/80-net-setu-link.rules and whose result(s) are located in the Symbolic Links located in /sys/class/net (which in turn point to 'device files' in /sys/devices)
 ***⇌
 ***Configuration File (in /etc/NetworkManger)
 ***
 ***⇌  ⇌  ⇌  ⇌  ⇌  ⇌
+'''ChatGPT to the Rescue'''
+Why is the UUID for the virbr0 Virtual Bridge Adapter displayed in the QEMU / KVM Host using the IP LINK SHOW command different than the UUID setting configured in the /etc/libvirt/qemu/networks/default.xml File, even though the MAC Address is the same in the Host (using IP LINK SHOW) and the default.xml File?
+ChatGPT's explanation is below;<syntaxhighlight lang="text">
+The discrepancy between the UUID in the default.xml file and the one displayed by the ip link show command might be due to the fact that the UUID in the XML configuration file refers to the libvirt network object's UUID, not the actual bridge interface's UUID.
+Here's a breakdown:
+UUID in default.xml:
+The default.xml file typically contains the XML configuration for the default libvirt network (virbr0). The UUID in this file corresponds to the libvirt network's unique identifier. This UUID is associated with the network object managed by libvirt.
+UUID displayed by ip link show:
+When you use ip link show, you are querying information about the actual bridge interface (virbr0). The UUID displayed here refers to the bridge interface itself, not the libvirt network object.
+While the libvirt network and the bridge interface are closely related, they are distinct entities with different UUIDs. The libvirt network configuration includes settings for the bridge interface but also encompasses additional configuration options managed by libvirt.
+If you want to inspect the libvirt network configuration and UUID programmatically, you can use the virsh command:
+bash
+Copy code
+virsh net-dumpxml default
+This command will display the XML configuration for the default network, including the libvirt network UUID.
+If you specifically need the UUID of the bridge interface (virbr0), you can extract it using the nmcli command (assuming NetworkManager is used for managing the bridge):
+bash
+Copy code
+nmcli connection show virbr0 | grep UUID
+This will display the UUID associated with the virbr0 connection managed by NetworkManager.
+In summary, the libvirt network and the bridge interface have separate UUIDs, and the discrepancy arises from the different contexts in which these UUIDs are used.
+</syntaxhighlight>