Results 1 to 9 of 9

Thread: A minimal kvm-host/bootloader distro?

Hybrid View

  1. #1
    Join Date
    Jan 2010
    Location
    Ghent
    Posts
    219

    Default A minimal kvm-host/bootloader distro?

    Hi

    I often play around with fringe operating systems but always fall back to Linux due to its amazing hardware support. I just got to think about a distro idea that I wonder if it already exist:

    A minimal linux distro that basically acts as a "bootloader" / KVM host. Ideally all the VM machine operations could be operated from the bootloader (syslinux) menu. During install it would basically just make two main partitions: A small boot partition containing the distro itself (in a file format accessible by most OSes .. perhaps vfat even) and another partition for the bootable disk images. The advantage with this would be to "abstract" the hardware in such a way that one could run just about any OS with the great hardware support of Linux.

    Some components:

    - Kernel: Linux (in its distributed condition, as many drivers enabled as possible)
    - bootloader: Syslinux
    - LibC: musl or uclibc
    - userland: toybox or busybox
    - virtualization: Qemu or linux-kvm (can this one boot anything else than linux?)
    - anything else? Is X or directfb needed for graphics?

    The distro would not have to be self-hosting (self-compiling) or have any packages by itself. An aim would however be to have it "guest-hosted" (that is, the minimal virtualization host distro should be possible to recompile and update from inside a guest OS that can run a build environment able to build its components (Linux, *BSD, Illumos, ...))

  2. #2
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,269

    Default

    Not exactly that, but making TinyCore do that would be pretty easy. It does use glibc instead of uC/musl.

    Graphics depend on how you want the output. Qemu's native output needs X, but it can also output via VNC and some other methods.

  3. #3
    Join Date
    Jan 2010
    Location
    Ghent
    Posts
    219

    Default

    Quote Originally Posted by curaga View Post
    Not exactly that, but making TinyCore do that would be pretty easy. It does use glibc instead of uC/musl.

    Graphics depend on how you want the output. Qemu's native output needs X, but it can also output via VNC and some other methods.
    I guess X would be the easiest method - I have seen that there is directfb/sdl etc too but I do not know if that would reduce complexity and size.

    TCL does indeed look like an interesting alternative (especially that it is so light but still present an X session). Perhaps I should try that once. I do however wonder if it could be pushed to be even more minimal using a light libc (the aim would not be to have app compatibility other than the minimal host utilities - and those could even be statically linked so no libraries included)

    EDIT: Alpine linux looks like an interesting TCL alternative... and uses uclibc

    I might have to look at that one too....

    EDIT2: Alpine apparently has a Xen Dom0 alternative, which might be similar to what I wanted... just do not know Xen good enough to judge whether it is.

    http://wiki.alpinelinux.org/wiki/Xen_Dom0
    Last edited by staalmannen; 06-05-2013 at 05:08 PM.

  4. #4
    Join Date
    Aug 2007
    Posts
    6,645

    Default

    You gain nothing from hardware support in first place when you only want to use virtualisation. Even if you want to use kvm or xen your hardware needs to be initialized first. Without X you can only use kvm via console or vnc. A bootloader only provides access to boottime flags, so you would need to parse custom options later. Of course you can boot live mode systems from a fat partition (it does not require syslinux, grub2 installs onto fat too, even onto ntfs - a normal hd install could be used aswell from a loopback device stored into an uncompressed 4gb-1byte max single image file onto fat, ubuntu used that trick even from ntfs). Basically your goals are a bit stupid defined, of course you could parse a custom option to preselect kvm options from a bootloader but i see absolutely no reason to do that at this point - grub 2 however is scriptable like bash and could be used if you REALLY want to implement it with a menu from the bootloader - syslinux would be too static.

  5. #5
    Join Date
    Jan 2010
    Location
    Ghent
    Posts
    219

    Default

    Quote Originally Posted by Kano View Post
    You gain nothing from hardware support in first place when you only want to use virtualisation. Even if you want to use kvm or xen your hardware needs to be initialized first. Without X you can only use kvm via console or vnc. A bootloader only provides access to boottime flags, so you would need to parse custom options later. Of course you can boot live mode systems from a fat partition (it does not require syslinux, grub2 installs onto fat too, even onto ntfs - a normal hd install could be used aswell from a loopback device stored into an uncompressed 4gb-1byte max single image file onto fat, ubuntu used that trick even from ntfs). Basically your goals are a bit stupid defined, of course you could parse a custom option to preselect kvm options from a bootloader but i see absolutely no reason to do that at this point - grub 2 however is scriptable like bash and could be used if you REALLY want to implement it with a menu from the bootloader - syslinux would be too static.
    For hardware support: The way I imagined it would be that the minimal host distro would boot and initialize the harware, and then via the VM present all the hardware as generic devices supported by most OSes.
    I sort of imagine it as basically an initrd image or ramdisk.

    For bootloader: The way I imagined this was that one would have some generic menu options that would start a custom init script (so the scriptable part would not have to be in syslinux):
    1) booting into the minimal host environment to (script/text menu assisted) create a new disk image, install an OS to the disk image (from iso, cdrom, usb...), add disk image as boot option
    2) booting kernel, initializing hardware, booting VM image will full system resources allocated (one entry per OS/image/snapshot generated under [1])

    Sorry for not being very clear... I just got the idea and started looking around if there was something similar already out there. The closest would probably be TCL or Alpine Xen Dom0 but not exactly what I imagined.

  6. #6
    Join Date
    Aug 2007
    Posts
    6,645

    Default

    For me what you want is complete non-sense, but if you want it, it should not be so hard to implement. Test your scripting skills.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •