KVM Kernel Virtualization Machine on Rocky Linux 9: Difference between revisions
mNo edit summary |
mNo edit summary |
||
| Line 71: | Line 71: | ||
***Configure IP Information (which should be the same as the Ethernet Adapter disabled above). | ***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) | ***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. | ***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 | **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 | ||
| Line 89: | Line 90: | ||
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; | 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). | *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). | ||
* | * | ||