|tagger||Andy Lutomirski <email@example.com>||Tue Sep 09 21:34:57 2014 -0700|
Virtme 0.0.1 This is the very first virtme release. It should not be considered stable. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJUD9T/AAoJEHJ/btyKT2u+XQIP/jEiHVzdQ9KEJXVVb7Zy6orr CasNknEE+Da7lQhafODN46/pSEYh773Y2FPHohc2ppz4IUvAVUIQtBSbPf6ZggE6 Xmxf7X+8S+9iR79VkPipNi/COT/CzNVV9Qz3/HaohANdM7afkop5xLeF6xCz8xUB zpOAY7NaN6PABpBU1l6Qk5k9ciWQlzXEDHqdkmN2I2TftTZN59Ogf1ycF/IwuYPn gz/aR2kvfcimebdC1PF7CxUabRZ2nqeNpIetxNBJ5mt7CPJlhzPN8BtCCFCZU88D /mjfGXFD576ai/ep4+9lMATy78qn3El0nLz1EfLD3hv0gePFMSbQl008lWOET1pN EcTena5gLsaSpdLwfn4WtRZ/6rxBfDsE3LHyDA7n9TG7vkpFzvCHb8GOfbi3ACb5 nlxZGyNInwomJgTYNa6RQrmevT2IZt27ocToXmp4kt0BwABd47tWZatOjcknbIVo WTMhlJAQYZTEjGL94zBxisCvML2AYOquY+A18AYzkspmwqkcXhB3mZAigBwm4AGD sVmNgcla9F03/TzbxAATM202UDmlu1jkRgS0NRBudrW6l/WzGMG8TdMBbGNPKafl jyptlpg5bgNxR6Ctjl1ht8Q7X4GNwVqWARPQEaF7uTq+yRFbd5LE2BvW4FP15/j9 Qvz8qyrQdSbUZixhDSYu =TV4b -----END PGP SIGNATURE-----
|author||Andy Lutomirski <firstname.lastname@example.org>||Tue Sep 09 21:29:48 2014 -0700|
|committer||Andy Lutomirski <email@example.com>||Tue Sep 09 21:29:48 2014 -0700|
Add make-release-tarball.sh Signed-off-by: Andy Lutomirski <firstname.lastname@example.org>
Virtme is a set of simple tools to run a virtualized Linux kernel that uses the host Linux distribution or a simple rootfs instead of a whole disk image.
Virtme is tiny, easy to use, and makes testing kernel changes quite simple.
Some day this might be useful as a sort of sandbox. Right now it's not really configurable enough for that.
You'll need a Linux kernel that has these options (built-in or as modules)
CONFIG_VIRTIO CONFIG_VIRTIO_PCI CONFIG_NET_9P CONFIG_NET_9P_VIRTIO CONFIG_9P_FS
For networking support, you also need CONFIG_VIRTIO_NET.
For script support, you need CONFIG_VIRTIO_CONSOLE.
For disk support, you need CONFIG_SCSI_VIRTIO.
That kernel needs to be sane. Your kernel is probably sane, but allmodconfig and allyesconfig generate insane kernels. Sanity includes:
CONFIG_CMDLINE_OVERRIDE=n CONFIG_BINFMT_SCRIPT=y CONFIG_TMPFS=y
You may also have better luck if you set:
CONFIG_EMBEDDED=n CONFIG_EXPERT=n CONFIG_MODULE_SIG_FORCE=n CONFIG_DEVTMPFS=y
An easy, somewhat-reliable way to generate a working config is to append the
prereqs.config file to your .config and then run
Your host system will need to satisfy some prerequisites:
busyboxbinary somewhere in your path.
Once you have such a kernel, run one of:
On x86, you can usually find a bzImage in
arch/x86/boot/bzImage once you've compiled your kernel.
Note that the --kimg mode does not support modules.
You can then do things like
cd /home/username and you will have readonly access to all your files.
Virtme gives you console input and output by default. Type ctrl-a x to exit. Type ctrl-a c to access the QEMU monitor.
For now, the virtme console is a serial console -- virtconsole seems to be unusably buggy. I don't know of any way to keep the tty state in sync between the host and guest, so resizing the host window after starting the guest may confuse guest libraries like readline.
If you want graphical output instead of console output, pass --graphics. Note that this is the opposite of QEMU's default behavior.
By default, virtme will use whatever architecture would be shown by
uname -m. You can override this with
--arch. Note that you may need to do some poorly documented fiddling for now to get non-native architectures working, and you will almost certainly need to set
--root to a root that matches the architecture.
x86 (both x86_64 and i386) is fully supported, although some odd KVM configurations may cause problems.
ARM is supported using qemu‘s
versatilepb machine. This is an unfortunate choice: that’s a rather outdated machine, and virtme should be using a different system (
virt) that is more modern and does not depend on PCI. There is no built-in KVM support for ARM right now, although it might work by accident -- I don't own a real KVM-capable ARM machine to test it on.
Aarch64 works out of the box if you have a new enough version of QEMU.
PPC64 appears to be reasonably functional.
Other architectures may or may not work. Adding support is trivial, so ping me if you need another architecture. Unrecognized architectures use a set of maybe-acceptable defaults.
In the near term, the high-priority features are: