KVM Kernel Virtualization Machine on Rocky Linux 9: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 43: | Line 43: | ||
Tools to use; | Tools to use; | ||
* Virtual Machine Manager GUI | *Virtual Machine Manager GUI | ||
* nm-connection-editor: Basic GUI for Network Management (more powerful than the GNOME Network 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") | *Terminal (AKA "Command Prompt") | ||
Useful Commands; | Useful Commands; | ||
* virsh net-list --all | *virsh net-list --all | ||
* nmcli connection show | *nmcli connection show | ||
* ip link show | *ip link show | ||
* ifconfig | *ifconfig | ||
* systemctl restart libvirtd.service | *systemctl restart libvirtd.service | ||
* systemct. restart NetworkManager | *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.); | 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.); | ||
| Line 65: | Line 65: | ||
**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 | ||
* | *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 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) | ...done. Well, configure the Virtual Machine's network information as would be done for any other physical machine. | ||
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. | |||
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) | |||
'''Power Events (AKA Automatic Start Actions, Automatic Stop Actions, and "WatchDog")''' | |||
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; | |||
*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). | |||
* | * | ||
| Line 126: | Line 141: | ||
MAN (Manual) Page, or the closest equivalent to: https://libvirt.org/formatnetwork.html But watch out on some stuff. Here's an example | 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" /> | *<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 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. | **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) | ***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) | ***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!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!''''' | ****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) | **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). | ...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). | ||
| Line 146: | Line 161: | ||
*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. | *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 | *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 543: | Line 569: | ||
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! | 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. | |||