wiki.TerraBase.info

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

← Older editNewer edit →
VisualWikitext
mNo edit summary
mNo edit summary
Line 41: Line 41:
'''Network Connectivity, don't forget that;'''
'''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).
Tools to use;
 
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:
* Virtual Machine Manager GUI
* nm-connection-editor: Basic GUI for Network Management (more powerful than the GNOME Network GUI)
* Terminal (AKA "Command Prompt")


*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
Useful Commands;
 
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.
* virsh net-list --all
*During the installation for QEMU / KVM, a Virtual Bridge Adapter was automatically configured
* nmcli connection show
* ip link show
* ifconfig
* systemctl restart libvirtd.service
* systemct. restart NetworkManager


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;
OK, here's what to do for creating what is essentially an Ethernet Switch.  IE, this is about as close as it comes to 'typical' reality where computers, servers, and other devices are all connected to each other via Ethernet Cables to an Ethernet Switch.  The below method uses a GUI interface as much as possible in order for one to understand and see what is going on, VS being a 'parrot' that types in commands as suggested by someone else.  It also assumes the reader knows the basics of what they're doing, so for instance when it is noted that something needs to be disabled, the reader knows how to do it (because it's easy) and doesn't need five additional steps stating, "...click here, type this, etc.);


*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
*Identify current Ethernet Adapter(s) and Virtual Bridge(s) get oriented by obtaing the names of various Network Adapters or Virtual Devices (eth0, enp1s0of0, virbr0, bridg0, br0, whatever, etc.);
*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 show (or use the nm-connection-editor)
**brctl show
**ip link show
*Disable the ''existing target'' Ethernet Adapter (this equates to the Physical Network Adapter that is connected to the Subnet / LAN / Network) through a GUI or command line interface.  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).  Also prevent it from starting by default.
**nmcli connection modify WhatEverConnectionName connection.autoconnect "no"
**nmcli connection modify WhatEverConnectionName connection.autoconnect "no"
**ifconfig WhatEverConnectionName down OR ip link set dev WhatEverConnectionName down
**ifconfig WhatEverConnectionName down OR ip link set dev WhatEverConnectionName down
Line 69: Line 74:
***nmcli connection show WhatEverConnectionName (ipv4.address = configured value AND IPV4.ADDRESS = "live / actual value")
***nmcli connection show WhatEverConnectionName (ipv4.address = configured value AND IPV4.ADDRESS = "live / actual value")
**systemctl restart NetworkManager
**systemctl restart NetworkManager
The result will be a Virtual Bridge named bridge0 (it can be anything, but bridge0 keeps with the 'suggested' Rocky Linux 9 naming convention, with the equivalent CentOS 7 naming convention being br0)
*
*


Line 114: Line 122:
***
***
***⇌  ⇌  ⇌  ⇌  ⇌  ⇌
***⇌  ⇌  ⇌  ⇌  ⇌  ⇌
MAN (Manual) Page, or the closest equivalent to: https://libvirt.org/formatnetwork.html  But watch out on some stuff.  Here's an example
* <forward mode="open" /> AND / OR <forward mode="bridge" />
** in the Virtual Machine Management GUI the drop down box and XML only have mode="open", mode="bridge" is not available.  WTF???!
** In the documentation from https://libvirt.org/formatnetwork.html, there is only mention of mode="bridge", there's nothing on that webpage for mode="open".  Now that's not to say they don't mention 'open', it's just never used in an example.  Both bridge and open are documented.
*** open is a version of route (IE, something more similar to a router than a bridge)
*** bridge is just what is says (IE, it is a bridge)
**** BIG NOTE: While it is never explicitly stated, "YOU NEED TO CREATE A BRIDGE OUTSIDE OF LIBVERT, BECAUSE UNLIKE ''NAT'' LIBVERT WILL ''NOT'' CREATE THE INTERFACE AUTOMATICALLY.  YOU HAVE TO DO IT YOURSELF MANUALLY", it '''''SHOULD BE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!'''''
** In the book Mastering KVM Virtualization neither mentions mode="open" or mode='open', only mode='bridge' is mentioned (and only one time in the 2020 edition)
...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


'''ChatGPT to the Rescue'''
'''ChatGPT to the Rescue'''
Retrieved from "https://wiki.terrabase.info/wiki/KVM_Kernel_Virtualization_Machine_on_Rocky_Linux_9"