summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJoey Hess2018-10-13 20:38:22 -0400
committerJoey Hess2018-10-13 20:38:22 -0400
commitf0b5074f107d1da2043701894254f7e85b090331 (patch)
treeaece7105ee68a6ca4468b64ea330d3ec74e8373d
parent75c2ea35c0c1aeedd14414ba8f0f1c97b5ee53cd (diff)
parent61ac03c489782795ee83cc54641333ea7d72d296 (diff)
Merge branch 'master' of ssh://propellor.branchable.com
-rw-r--r--doc/forum/support_for_non-bootable_disk_images/comment_4_33cf3405000896fb42b9165a206e2417._comment15
-rw-r--r--doc/todo/support_for_libvirt_KVM_VMs/comment_2_9aa111329fc476a2b978aabe4cc4c0f0._comment14
2 files changed, 29 insertions, 0 deletions
diff --git a/doc/forum/support_for_non-bootable_disk_images/comment_4_33cf3405000896fb42b9165a206e2417._comment b/doc/forum/support_for_non-bootable_disk_images/comment_4_33cf3405000896fb42b9165a206e2417._comment
new file mode 100644
index 00000000..55e4e20b
--- /dev/null
+++ b/doc/forum/support_for_non-bootable_disk_images/comment_4_33cf3405000896fb42b9165a206e2417._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="Naming and other hard problems"
+ date="2018-10-13T23:16:07Z"
+ content="""
+I'm not too attached to the terminology, \"direct booting\" just what an unscientific survey of sysadmin types came up with. QemuBoot is more descriptive, although I do wonder if it's really specific to Qemu. As far as I understand (which is just from reading the Xen wiki), Xen dom0 can also (and originally could only) boot this way. In fact I think the last Xen VPS I had worked like this, which was a pain as a guest admin. Maybe the connecting thread is that the boot is controlled by the host rather than the guest VM. HostBoot would be one option, although NoBootloader is also fine with me. I think things like QemuBootloader or whatever would likely be layered on top.
+
+I'm less sure about copying kernel and initrd than when I first wrote that. If it's reasonable to depend on the existence of the foo.img.chroot, then it's quite convenient to boot from the already conveniently present kernel and initramfs.
+
+I'll have to see how hard it is to get basic networking with just qemu. It might make sense to use libvirt to run the VMs, especially since that's what the production deployment uses. I saw [[spwhitton]] had some ideas about libvirt.
+
+
+
+"""]]
diff --git a/doc/todo/support_for_libvirt_KVM_VMs/comment_2_9aa111329fc476a2b978aabe4cc4c0f0._comment b/doc/todo/support_for_libvirt_KVM_VMs/comment_2_9aa111329fc476a2b978aabe4cc4c0f0._comment
new file mode 100644
index 00000000..db451976
--- /dev/null
+++ b/doc/todo/support_for_libvirt_KVM_VMs/comment_2_9aa111329fc476a2b978aabe4cc4c0f0._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="david"
+ avatar="http://cdn.libravatar.org/avatar/22c2d800db6a7699139df604a67cb221"
+ subject="qcow and raw imgs"
+ date="2018-10-13T23:48:46Z"
+ content="""
+Maybe this is obvious, but it's cheap to generate a qcow image \"backed\" by an existing raw image
+
+To quote from a script I have lying around to let a non-root user boot a root owned, read-only image
+[[!format txt \"\"\"
+qemu-img create -b /srv/vm/$vm.img -f qcow2 $img
+\"\"\"]]
+
+"""]]