summaryrefslogtreecommitdiff
path: root/doc/todo
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo')
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_4_dbd2c399c8ef8ac56ae06f1a701fdc45._comment19
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_5_364df45dda89ed83cf8db6fa4cbdc186._comment8
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_6_9c2792cec842dba7a8fabb24c2c33da0._comment14
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_7_246609ff0b30329fe64fe1c100b62c45._comment49
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_8_f7ceb2909d6884a9b13500b7c660469a._comment23
5 files changed, 113 insertions, 0 deletions
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_4_dbd2c399c8ef8ac56ae06f1a701fdc45._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_4_dbd2c399c8ef8ac56ae06f1a701fdc45._comment
new file mode 100644
index 00000000..8ce06a1c
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_4_dbd2c399c8ef8ac56ae06f1a701fdc45._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2018-10-14T01:10:16Z"
+ content="""
+I do think that the conditional property would be a good way for this to
+work.
+
+I think there could also be VMs where you don't want the overhead of
+running propellor inside the VM (especially if the emulation is slow, or
+you don't want to allocate that much memory to the VM, or just have a lot
+of VMs), and the content is disposable. Then propellor could restart the VM
+when it changes the disk image.
+
+There's room for multiple ways to do it..
+
+The disk image building side of this looks easy to me, so if you do the libvirt
+stuff, Sean, I might contribute something. :)
+"""]]
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_5_364df45dda89ed83cf8db6fa4cbdc186._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_5_364df45dda89ed83cf8db6fa4cbdc186._comment
new file mode 100644
index 00000000..5062ed5d
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_5_364df45dda89ed83cf8db6fa4cbdc186._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="insufficient magic"
+ date="2018-10-14T11:12:36Z"
+ content="""
+right, changing the backing image would probably break everything.
+"""]]
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_6_9c2792cec842dba7a8fabb24c2c33da0._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_6_9c2792cec842dba7a8fabb24c2c33da0._comment
new file mode 100644
index 00000000..931b21fe
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_6_9c2792cec842dba7a8fabb24c2c33da0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="creating the libvirt VM"
+ date="2018-11-04T01:03:06Z"
+ content="""
+I've now an adhoc, proof-of-concept libvirt VM provisioned by my config.hs, just using a raw disk image. It turns out that propellor should not be writing the XML configuration file in /etc, but having libvirt generate it. This is because the config is not meant to be directly edited. So, propellor should call virt-install(1) to setup and boot the VM.
+
+My code uses virt-install's --import option, also passing it the location of the disk image generated by propellor. The main problem is that the invocation of virt-install won't return until after the VM first shuts down; the idea is that you are running the OS installer and then you reboot. Possibly using --boot instead of --import will help here; not sure.
+
+We will need the user to specify how much RAM and how many vCPUs to assign to the VM. All the other parameters to virt-install can be determined by looking at the properties of the VM `Host`.
+
+Otherwise, the user will need to set an IP property on the VM so that it can be conducted. I think we will need to leave the user to do this, as there are so many possible network configurations for libvirt VMs. But we could probably provide helper properties. In particular, the standard setup will be to use `Network.static`, though I'm not sure about how to do that with indeterministic interface names.
+"""]]
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_7_246609ff0b30329fe64fe1c100b62c45._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_7_246609ff0b30329fe64fe1c100b62c45._comment
new file mode 100644
index 00000000..1aa82a09
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_7_246609ff0b30329fe64fe1c100b62c45._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="spwhitton"
+ avatar="http://cdn.libravatar.org/avatar/9c3f08f80e67733fd506c353239569eb"
+ subject="New design: requesting feedback"
+ date="2018-11-04T17:39:51Z"
+ content="""
+Having slept on it, and also looked at some more of virt-install(1), I have a new design. I'd be grateful for feedback on this, before implementation.
+
+We have two properties: `Libvirt.kvmRunning` and `Libvirt.kvmRunningConducted`, where
+
+ kvmRunningConnected host = conducts host `requires` kvmRunning host
+
+The basic reason for separating these two properties is that for the conducting to work, various network things have to be set up, and there isn't a configuration that it would be sensible to have as a default. More generally, libvirt isn't at all suited to declarative configuration. What propellor can do well is build an image and have libvirt generate a barebones XML configuration file to boot the image. This is what `Libvirt.kvmRunning` will do. After that, we're going to have to leave it up to the user. I suspect that outside of the very simplest cases, they are going to have to make a series of virsh(1) calls, using `flagFile` to ensure that it only happens once.
+
+`Libvirt.kvmRunning` will work like this:
+
+1. ensure libvirt etc. are installed
+2. build the image if it doesn't exist
+3. nuke the chroot used to build the image
+3. if VM config does not exist,
+ 1. `virt-install -n vm-hostname --description \"vm-hostname VM\" --os-type=Linux --os-variant=debian9 --ram=1024 --vcpus=2 --autostart --disk path=/var/lib/libvirt/images/vm-hostname.img,device=disk,bus=virtio --import --print-xml >/tmp/foo`
+ 2. `virsh define /tmp/foo`
+ - `virt-install --print-xml` and then `virsh define` avoids the problem of virt-install not exiting until after the VM has been shutdown at least once/the virt-viewer instance launched by virt-install has been closed
+ 3. `virsh start vm-hostname`
+
+Sample usage:
+
+ laptop :: Host
+ laptop = host \"iris.silentflame.com\" $ props
+ & osDebian (Stable \"stretch\") X86_64
+ & Libvirt.kvmRunning Raw 1GB 2 develacc -- specification of image type, RAM and vCPUs to assign
+
+ develacc :: Host
+ develacc = host \"develacc.iris.silentflame.com\" $ props
+ & osDebian Unstable X86_64
+ & hasPartition
+ ( partition EXT4
+ `mountedAt` \"/\"
+ `addFreeSpace` MegaBytes 10240
+ )
+ & Apt.installed [\"linux-image-amd64\"]
+ & Grub.installed PC
+
+ & ipv4 \"192.168.122.31\"
+ & Network.static \"ens3\" (IPv4 \"192.168.122.31\")
+ (Just (Network.Gateway (IPv4 \"192.168.122.1\")))
+ `requires` Network.cleanInterfacesFile
+ & Hostname.sane
+"""]]
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_8_f7ceb2909d6884a9b13500b7c660469a._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_8_f7ceb2909d6884a9b13500b7c660469a._comment
new file mode 100644
index 00000000..0af0baaa
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_8_f7ceb2909d6884a9b13500b7c660469a._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2018-11-05T16:40:57Z"
+ content="""
+Seems that kvmRunning would need a warning that changes to the propellor
+configuration of the VM's Host won't affect the VM. Because it's unusual for
+propellor to only be able to set something up and not change it afterwards.
+
+But kvmRunning is certianly a useful low level property, and combining with
+other properties like that is good.
+
+Hmm, it's actually possible to mount a qcow2 image using libguestfs-tools.
+<http://ask.xmodulo.com/mount-qcow2-disk-image-linux.html>
+So, propellor could temporarily take down the VM and run inside the qcow2
+to update it! Although doing that every time propellor is run seems
+suboptimal. It could keep the chroot around and only update the qcow2 image
+if the chroot needed to be updated. I am not sure how I feel about that
+idea.
+
+We could also make conducting easier to set up, perhaps not needing `main`
+to be modified to use it.
+"""]]