KVM Kernel Virtualization Machine on Rocky Linux 9: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| 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) | ||
* 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) | ||
*** | ***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) | |||
* | * | ||
| Line 126: | Line 134: | ||
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 154: | ||
*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''' | ||