wiki.TerraBase.info

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

← Older edit
VisualWikitext
mNo edit summary
mNo edit summary
 
(8 intermediate revisions by the same user not shown)
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;
 
*Virtual Machine Manager GUI
*nm-connection-editor: Basic GUI for Network Management (more powerful than the GNOME Network GUI, and in fact the GNOME Network GUI is just plain unreliable and inaccurate, so don't use)
*Terminal (AKA "Command Prompt")
 
Useful Commands;
 
*virsh net-list --all
*nmcli connection show
*ip link show
*ifconfig
*systemctl restart libvirtd.service
*systemct. restart NetworkManager
 
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 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.);
**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"
**ifconfig WhatEverConnectionName down OR ip link set dev WhatEverConnectionName down
*Create the "Virtual Ethernet Switch" (AKA Virtual Bridge)
**nm-connection-editor: Using this GUI makes it easy.
***"Connect / Extend the Ethernet Cable plugged into the Physical Host's Network Jack" to a "Port" on the "Virtual Ethernet Switch"
****Bridge Tab, Add Button, Select the Physical Interface
***Configure IP Information (which should be the same as the Ethernet Adapter disabled above).
***Name the Connections and Interface Name as: bridge0 (although it can be anything, plus keeping the names similar cuts down on Alias Names causing confusion later)
****Another useful naming convention would be a hybrid approach where one could start the name with the old fashion "br", then append the name of the physical adapter, so a "bridge" connected to eno4 (a naming convention for Rocky Linux 9 Ethernet Adapter / Connections) would be breno4
***The end result is the is a Virtual Ethernet Switch with a single Port that has one Cable plugged into it.  Later, if viewed when a Virtual Machine is powered on, the additional Ports for the Virtual Machines will be seen here.
**OR, to do the same as above from the command line (minus adding IP information): mcli connection add type bridge autoconnect yes con-name bridge0 ifname bridge0
*Configure the Virtual Machine's Network Adapter. There should be one created by default.
**Edit the Virtual Machine in Virtual Machine Editor
***Set the Network Source to: Bridge device
***Set the name to: bridge0 (or whatever it was named)
***Set Device Model to: virtio


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.
...done.  Well, configure the Virtual Machine's network information as would be done for any other physical machine.


KEEP THIS IN MIND: In the QEMU / KVM world, here's how the networking thing functions:
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).  Virtual Machines as they're powered on will have their NICs show up as vnet0, vnet1, etc.


*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
And as gone into more detail below, it is simply not within the realm of reality for the libvirtd to automatically create the above "Switch" (AKA Virtual Bridge)


Here's the assumption (unlike all the other tutorials there);
'''Power Events (AKA Automatic Start Actions, Automatic Stop Actions, and "WatchDog")'''


*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.
One would ordinarily ever consider that Microsoft would make sense.  But they do in this instance.  Here's the question: When a QEMU / KVM Host Machine (that's the physical machine) is restarted / rebooted or shut down, what about the Virtual / Guest Machines?  Are they shut down properly / gracefully?  Are they paused / suspended?  Or are they just turned of, as in flip / press the power button to kill it?  In the Microsoft world with Hyper-V it's abundantly clear with Automatic Start Actions and Automatic Stop Actions.  Wow!  Cool!  Gravity can be reversed.  Not so evident with the QEMU / KVM architecture.  Yup, as the title might have given away, look under "WatchDog" for power settings.  Ummm, unless it was a couple of years ago, then it would be qemu-guest-agent.service and some settings tucked away in /etc/default/libvirt-guests, no wait, /etc/sysconfig/libvirt-guests.  But that file is gone now with nothing left behind, not even a file by the same name with a note in it explaining why it isn't used anymore, it's just gone.  Before that, some custom scripts and 'shutdown service(s)', but those aren't needed anymore, nor will they work the same way they used to because the new QEMU / KVM breaks that paradigm.  Anyway, here's the answer to the above question;
*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;
*In the Virtual Machine Manager GUI, open the Virtual Machine (AKA "Domain", wait, didn't Microsoft already take that term?), click Settings, err, the Gear Icon, no wait, the Light Bulb Icon, click WatchDog, then under Model select diag288, 16300esb, or ib700, and, no wait, you could also type anything you want, or leave it at the default of itco (which isn't in the drop down menu), then under Action select what you want the Virtual / Guest machine to do when the physical host machine is rebooted, shutdown, etc. (with the default set to Forcefully reset the guest, which is of course the best one for preserving data and the integrity of the guest machine, err, no wait, speeds shut down of the physical host machine by just killing the guest machine, losing data, settings, destroying databases, etc., so naturally Forcefully reset the guest is the default setting).


*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) ===
===Tricks, Tips, and Other Useful Information (all of which applies to Rocky Linux 9, and others based on Red Hat)===
'''Network Configuration;'''
'''Network Configuration (from''' https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/configuring_and_managing_networking/index#configuring-an-ethernet-connection-with-a-static-ip-address-by-using-nmstatectl_configuring-an-ethernet-connection<nowiki/>)''';'''


* NMCLI ( nmcli ): Command Line Interface
*NMCLI ( nmcli ): Command Line Interface
* NMTUI ( nmtui ): Text Based GUI
*NMTUI ( nmtui ): Text Based GUI
* NM-CONNETION-EDITOR ( nm-connection-editor ): "Control Panel Version" GUI
*NM-CONNETION-EDITOR ( nm-connection-editor ): "Control Panel Version" GUI
* "Control Center" for GNOME: "Windows 11 Version" GUI (IE, less capable than all of the above)
*"Control Center" for GNOME: "Windows 11 Version" GUI (IE, less capable than all of the above)
*NMSTATECTL ( nmstatesctl ): nmstatectl show will provide a LOT of information (plus other things, including configuration)


'''Other Tips and Information;'''
'''Other Tips and Information;'''
Line 95: Line 119:
****x = Exit / Quit and Save (AKA Write) (as in<span> </span>:x)
****x = Exit / Quit and Save (AKA Write) (as in<span> </span>:x)
****q = Quit (AKA Exit)
****q = Quit (AKA Exit)
***...and that is not enough, ALL of the following commands need to be run for configuration changes to take effect (the below examples assume ''default'' is the name of the network device)
****virsh net-destroy default (essentially stops the device, and also deletes it, as apparently restarting it alone isn't enough)
****virsh net-define default (in reality, the intent is to 're-define' the interface, but from the VIRTLIBD perspective the interface has been 'destroyed' and isn't there, so it needs to be defined)
*****TOP TIP: When using the virsh net-define command, don't put the 'base' configuration file in /etc/libvirt/qemu/networks
****virsh net-start default
****Note: Hey, I've got an idea for you genzers that are programming this, why not create a virsh net-restart command that intuitively does what a bazillion other past command examples do to complete the above task?  And don't say virsh net-update add / modify, because that is just as convoluted.  Go ahead, read it right here and see if having a virsh net-restart command doesn't make good sense: https://wiki.libvirt.org/Networking.html#:~:text=If%20you%20edit%20the%20network,automatically%20done%20as%20a%20side  Now why would all of this be a big issue?  Well guess what, there's this thing called reality where you can get this error: "failed to get domain" when using the virsh net-destroy and then what?  Reboot MFer.  That's it.  Thanks Genzers!
*QEMU / KVM Additional Bridge Configuration: /etc/qemu-kvm/
*QEMU / KVM Additional Bridge Configuration: /etc/qemu-kvm/
*Documentation from QEMU / KVM on Bridges and Networking: https://libvirt.org/formatnetwork.html
*Documentation from QEMU / KVM on Bridges and Networking: https://libvirt.org/formatnetwork.html
Line 107: Line 137:
***
***
***⇌  ⇌  ⇌  ⇌  ⇌  ⇌
***⇌  ⇌  ⇌  ⇌  ⇌  ⇌
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
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


'''ChatGPT to the Rescue'''
'''ChatGPT to the Rescue'''
Line 501: Line 566:




===Rants and Temper Tantrums===
Delete a bridge created by using an XML file.  It works most of the time.  But what happens if you get a dreaded "failed to get a 'forking' domain" error message?  What then?  Well, your SOL until you reboot the machine.  NOTHING works!


 
'''QEMU Guest Agent / qemu-guest-agent.service VS libvirtd "guest" stuff:'''  There are hints that the former has been depricated or isn't needed or something.  Good fucking lucking getting a straight answer on any of this shit.  Here, try this: https://stackshare.io/stackups/libvirt-vs-qemu#:~:text=Hardware%20Emulation%3A%20QEMU%20includes%20its,not%20provide%20direct%20hardware%20emulation.  Yup, now it's all clear. Dear Linux developers.  You're brilliant.  But you can't communicate for shit.  You change things on a minutely basis and leave a wake of documentation destruction behind you.  How is anyone on this planet supposed to understand and keep up with what you're doing?  Part of your job should be to make this open source software available to everyone.  Nope, need a degree in Linuxology to understand stuff, and it shouldn't be that way.  Yes, there needs to be an understanding of fundamentals and expertise, but don't you get it?  There are people out there that have to be skilled in a myriad of technologies to actually make use of your stuff in the real world.  They're really smart and capable, but just don't have the time to understand stuff like you.  There's too much other stuff going on.  Rant over, because I'm tired of typing.
 
 




Retrieved from "https://wiki.terrabase.info/wiki/KVM_Kernel_Virtualization_Machine_on_Rocky_Linux_9"