KVM Kernel Virtualization Machine on Rocky Linux 9

Wiki.TerraBase.info
Revision as of 16:15, 25 December 2023 by Root (talk | contribs)
Jump to navigation Jump to search

...below are just rough notes from three different sources, including ChatGPT. They are ordered in each section as below from the following sources;

Check for VM Support in CPU;

  • cat /proc/cpuinfo | egrep "vmx|svm"
  • lscpu | grep Virtualization
  • No Comment

Install all the Stuff (for the first two sources there were duplicate items on multiple lines that were cleaned up, oops, no proof reading on their part, huh, just a copy and paste);

  • dnf install qemu-kvm virt-manager libvirt virt-install virt-viewer libguestfs-tools bridge-utils virt-top
  • dnf install qemu-kvm virt-manager libvirt virt-install virt-viewer libguestfs-tools bridge-utils virt-top
  • dnf install qemu-kvm libvirt virt-install virt-manager AND apparently installing virt-manager again (just to make sure)

NOTES: And of course there are about a hundred or so other dependencies that are downloaded and installed too.

ISSUES: bridge-utils virt-top might give issues if attempting to install at the same time, so try installing separately.

Check Installation;

  • lsmod | grep kvm
  • lsmod | grep kvm
  • lsmod | grep kvm AND virsh list --all

Start AND Enable Automatic Starting of the "KVM" Services AND see if they're actually running;

  • sudo systemctl start libvirtd AND systemctl enable --now libvirtd AND systemctl status libvirtd
  • sudo systemctl start libvirtd AND sudo systemctl enable libvirtd AND systemctl status libvirtd
  • sudo systemctl start libvirtd AND sudo systemctl enable libvirtd AND No Comment

Permissions and User Related Stuff;

  • No Comment
  • usermod -aG libvirt $USER AND newgrp libvirt
  • usermod -aG libvirt $(whoami)

Network Connectivity, don't forget that;

...and now comes the part where the above noted references show their true colors. IE, the content in the articles on those websites was not created by the people who own those websites. It was aggregated from other websites and put into a format that Google likes. And does it ever show on the Networking aspect of what they document. In short, ignore it. You'll hose your system if you do what is written. Go ahead and try it (no, don't really do that).

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)
    • virsh net-edit default (it uses the VI editor)
      • VI Editor
        • i = Insert (AKA Edit) Mode
        • ESC = Command Mode
        •  : (Colon) = "Beginning of Command"
        • w = Write (as in :w)
        • x = Exit / Quit and Save (AKA Write) (as in :x)
        • q = Quit (AKA Exit)
  • QEMU / KVM Additional Bridge Configuration: /etc/qemu-kvm/
  • Documentation from QEMU / KVM on Bridges and Networking: https://libvirt.org/formatnetwork.html
  • All, or most of the documentation for Rocky Linux 9 that steers one towards /etc/udev/rules.d is now located in /lib/udev/rules.d
  • 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;

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.











Retrieved from "https://wiki.terrabase.info/index.php?title=KVM_Kernel_Virtualization_Machine_on_Rocky_Linux_9&oldid=1964"