View source for 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 [[4000_Linux_VT_Solutions#VT_Hardware|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 <tt>virt*</tt> kernel modules:<pre>
[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) $ </pre>
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 <tt>/proc/cpuinfo</tt> or use <tt>x86info(1)</tt> etc to look for the VT capability flags as extracted from [[cpuid]] data. Intel machines will show <tt>vmx</tt> like so:<pre>[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) $ </pre>

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

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

* If your boot locks up, ensure you've provided <tt>-serial stdio</tt>. See [https://docs.netgate.com/pfsense/en/latest/troubleshooting/boot-issues.html#Booting_with_an_alternate_console Booting with an alternate console] at NetGate and [https://www.digitalocean.com/community/tutorials/how-to-recover-from-file-system-corruption-using-freebsd-s-single-user-mode Recovering File System Corruption] from DigitalOcean.

==See also==
* [[SR-IOV]]