4000 Linux VT Solutions

Holy god there's way too many ways to run a fake computer inside a real computer running Linux in the top ring. The most important thing is to learn tun/tap devices and bridges, since the builtin networking sucks in everything I've tried; tun/tap can back any reasonable choice. Just listing them off the top of my head:

• KVM/Qemu - I dig KVM. Always have. It slapped an open kernel module between cheap COTS VT hardware and the open, feature-rich qemu frontend, fixed and stabilized aforementioned frontend, and has been pretty awesome for years.
  • If you have VT, use kvm. Otherwise, qemu's closed-source hoopajoop module can provide a bit better performance than unaccelerated kvm/qemu. You'll want to set up a large tmpfs FIXME import from researchwiki...
  • There's GUIs for these, but they're uglier than they're worth.
• Xen - A juggernaut -- the Oracle to these 4000 solutions' fractured MySQL and postfreshSQL communities. I've ignored it almost completely, largely out of spite and contrarianism.
• lguest - I know of this primarily due to following Rusty Russell's blog.
• OpenVZ - No clue
• VMWare - It exists, sure. Why are you running closed source? Utterly uninteresting.

There's also the virt* kernel modules:

[recombinator](0) $ find /lib/modules/ -iname \*virt\* -type f
/lib/modules/2.6.28.1/kernel/drivers/virtio/virtio_pci.ko
/lib/modules/2.6.28.1/kernel/drivers/virtio/virtio_ring.ko
/lib/modules/2.6.28.1/kernel/drivers/virtio/virtio.ko
/lib/modules/2.6.28.1/kernel/drivers/virtio/virtio_balloon.ko
/lib/modules/2.6.28.1/kernel/drivers/char/virtio_console.ko
/lib/modules/2.6.28.1/kernel/drivers/net/virtio_net.ko
/lib/modules/2.6.28.1/kernel/drivers/block/virtio_blk.ko
[recombinator](0) $ 

These seem to be drivers geared towards the exposed virtualized devices, or perhaps towards accelerating those devices, who knows FIXME?

VT Hardware

Without AMD's Pacifica extensions or Intel's VMX, VT is pretty unpleasant on x86 no matter what memory you throw at it. The reasons for this are elaborate and deeply, deeply boring to anyone who doesn't already know them.

This applies to Intel and AMD's virtualization technologies as added to the x86 instruction set, under Linux, unless otherwise stated. Check /proc/cpuinfo or use x86info(1) etc to look for the VT capability flags as extracted from cpuid data. Intel machines will show vmx like so:

[recombinator](0) $ grep flags /proc/cpuinfo | sort -u
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est
tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow
[recombinator](0) $ 

If stymied in your search for expected VT, inspect your BIOS to ensure it hasn't been disabled there.

FreeBSD guests

• On FreeBSD11+, the vt driver has replaced the sc console driver. So far as I am aware, the latter is necessary to use vidcontrol to change virtual screen resolution. Once kern.vty=sc is added to /boot/loader.conf, qemu using the -vga std arguments ought be able to do high resolution with e.g. vidcontrol MODE_401 (1920x1080x24). Once the mode is verified, it can be set on boot by adding an e.g. allscreens_flags="MODE_401" line to /etc/rc.conf.

• If your boot locks up, ensure you've provided -serial stdio. See Booting with an alternate console at NetGate and Recovering File System Corruption from DigitalOcean.

See also

• SR-IOV