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
@@ -0,0 +1,15 @@
+ subject="Naming and other hard problems"
+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
@@ -0,0 +1,14 @@
+ subject="qcow and raw imgs"
+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