4000 Linux VT Solutions - revision history

Dank: /* FreeBSD guests */

2020-12-30T13:31:59Z

FreeBSD guests

← Older revision		Revision as of 13:31, 30 December 2020
Line 36:		Line 36:
	* 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>.		* 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].		* 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==		==See also==
	* [[SR-IOV]]		* [[SR-IOV]]

Dank: /* FreeBSD guests */

2020-12-30T13:29:44Z

FreeBSD guests

← Older revision		Revision as of 13:29, 30 December 2020
Line 35:		Line 35:
	==[[FreeBSD]] guests==		==[[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>.		* 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].

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

Dank at 02:52, 14 November 2020

2020-11-14T02:52:41Z

← Older revision		Revision as of 02:52, 14 November 2020
Line 35:		Line 35:
	==[[FreeBSD]] guests==		==[[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>.		* 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>.

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

Dank: /* FreeBSD guests */

2020-06-09T20:49:33Z

FreeBSD guests

← Older revision		Revision as of 20:49, 9 June 2020
Line 34:		Line 34:

	==[[FreeBSD]] guests==		==[[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).		* 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>.

Dank: /* FreeBSD guests */

2020-06-09T20:47:21Z

FreeBSD guests

← Older revision		Revision as of 20:47, 9 June 2020
Line 34:		Line 34:

	==[[FreeBSD]] guests==		==[[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.		* 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).

Dank: qemu + freebsd + sc/vt

2020-06-09T20:45:17Z

qemu + freebsd + sc/vt

← Older revision		Revision as of 20:45, 9 June 2020
Line 32:		Line 32:

	If stymied in your search for expected VT, inspect your BIOS to ensure it hasn't been disabled there.		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.

Dank: stop recommending 1and1

2020-06-09T20:36:06Z

stop recommending 1and1

← Older revision		Revision as of 20:36, 9 June 2020
Line 32:		Line 32:

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

	~~==I just need a VPS mang!==~~
	~~I have chartered a [http://www.1and1.com 1and1] Linux VPS since 2009-01-01, and find it pretty damn reasonable.~~

Dank at 05:49, 19 June 2009

2009-06-19T05:49:27Z

← Older revision		Revision as of 05:49, 19 June 2009
Line 2:		Line 2:

	* 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.		* 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''...		** 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.		** 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.		* 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.

WikiSysop: 1 revision

2009-01-28T07:32:13Z

1 revision

← Older revision	Revision as of 07:32, 28 January 2009
(No difference)

Dank: /* VT Hardware */

2009-01-19T13:59:53Z

VT Hardware

New page

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.

==I just need a VPS mang!==
I have chartered a [http://www.1and1.com 1and1] Linux VPS since 2009-01-01, and find it pretty damn reasonable.