Initial commit, ported from systemd-units.git

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.