diff options
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 52 |
1 files changed, 52 insertions, 0 deletions
diff --git a/README.md b/README.md new file mode 100644 index 0000000..e931295 --- /dev/null +++ b/README.md @@ -0,0 +1,52 @@ +## Scope + +This contains a "framework" I have written around virsh for controlling KVM +machines and setups more easily. More easily here focuses on two objectives: + +1. Become able to start and stop everything at boot time. While a shutdown is + rather uninteresting in terms of dependencies and whatnot and libvirt-guests + can take this over, a boot out of the blue and in proper order is something + I wanted to take into my own hands +2. Integration into systemd. More dependencies, groups of units, ... and isn't + it nice to see every more important KVM yoke report itself at boot time? + (Yes, I have a more verbose boot, a black screen and then a prompt is for + the Windows/Apple generation.) +3. Finally, with 1. and 2.: you need to do things on your own from here. I + heavily use virsh, but I wrap around that, because if I shutdown a machine + that is already shutdown for whatever reason, I would not consider the + systemd unit's shutdown to be failed, virsh does. +4. Automation. See what you automate, but don't care anymore :) This point is + actually a summary of all of the above. + +## To-Do + +* [ ] Create a configuration file /etc/kvmheklper.conf and an update script + that will place the respective systemd units inside /etc/systemd for + you +* [ ] Make the systemd service and target units mroe abstract, i.e. it should + *really* not have any names anymore and reflect the 4 layer principle + only + + +## Content + +The directories *etc/systemd/system*, *etc/tmpfiles.d*, and *usr/local/[s]bin* should be +self-explanatory. Therein, you'll find the following: + +### Systemd units + +* **kvm-SOMETHING@.service:** Designed to control machines or networks. I view + my setups basically as a compound of four layers: Network, network VMs + like routing/firewall/manages switching, infrastructural machines such + as an iscsi provider, and then the slave-only machines. This more or + less is reflected in what is pushed in this repository and will improve + in the near future (more abstraction, more generalisms, better layer + steering). +* **cluster-SOMETHING.target:** Basically just an example. I have three slave + only machines, so I put them in there to have them boot parallelly. + +* **kvmhelper:** The actual script administering the environment through virsh. + It can be entirely quiet (but isn't by default, it also tells you if it's + successful)), and it will also terminate successfully if you try to start + something that is already up or try to kill something that is already + down. |