git.lirion.de

Of git, get, and gud

aboutsummaryrefslogtreecommitdiffstats
path: root/README.md
diff options
context:
space:
mode:
Diffstat (limited to 'README.md')
-rw-r--r--README.md52
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.