From 0621fa5756c478f7e3c7fe91daeca2b6dd62ed92 Mon Sep 17 00:00:00 2001 From: david Date: Sat, 13 Oct 2018 23:16:07 +0000 Subject: Added a comment: Naming and other hard problems --- .../comment_4_33cf3405000896fb42b9165a206e2417._comment | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/forum/support_for_non-bootable_disk_images/comment_4_33cf3405000896fb42b9165a206e2417._comment 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. + + + +"""]] -- cgit v1.2.3 From 61ac03c489782795ee83cc54641333ea7d72d296 Mon Sep 17 00:00:00 2001 From: david Date: Sat, 13 Oct 2018 23:48:46 +0000 Subject: Added a comment: qcow and raw imgs --- .../comment_2_9aa111329fc476a2b978aabe4cc4c0f0._comment | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/todo/support_for_libvirt_KVM_VMs/comment_2_9aa111329fc476a2b978aabe4cc4c0f0._comment 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 +\"\"\"]] + +"""]] -- cgit v1.2.3