Прошел год с тех пор, как я начал вплотную заниматься виртуализацией KVM. Я долго откладывал кучу статей. Я мог бы сейчас написать кучу всякой патетики и всё такое. Но мне лениво. Начнем по делу.

За год я столкнулся с огромной кучей проблем. Действительно с огромной. Их было очень много. У меня волосы вставали дыбом. Некоторые проблемы мы не могли решить четырьмя командами (#linuxtalks, Ubuntu Loco, Russian Fedora, MLUG) в течении трех месяцев. Я матюгался, ронял серверы, сносил все виртуалки, люто-бешено гонял их по всему облаку (я уже говорил, что я организовал псевдооблако баш скриптами)? ), ковырял конфиги, перечитал огромную кучу разрозненной литературы.Честно — у меня не было времени разобраться как это работает внутри. Я даже не вникал в перипетии KVM/QEMU. Я просто получил прекрасную схему =)

*здесь и далее — 1 ядро — 1 поток от процессора core i7-920 (всего у него 4 физических ядра и HT — то есть 8 потоков. Одно ядро виртуалки — 1/8 процессора или 1 поток).

Начнем с плюсов. Что-то может повторится из первых статей, но всё же.
1) скорость виртуализации CPU и RAM. Это реально жесть. Сборка gcc в gentoo (на 1м ядре*, 1 гиг памяти) прошла за 40 минут. Сборка на P4 похожей частоты занимает около двух часов.
2) простота. Да, если понять как этим управлять — оно очень простое и понятное. Хотя, всё равно непонятно как работает, зато понятно как управлять.
3) гибкость. Можно вытворять что угодно.
4) возможности почти не отличаются от физической машины. single mode — пожалуйста. монтирование с noexec — да легко! ipfw/pf/iptables работают полностью.
5) устойчивость к перегрузкам. при высоком load average эти виртуалки немного отзываются и в принципе позволяют устранить проблему.
6) можно запускать почти любую ОС. FreeBSD, OpenBSD, Win Server, Linux…. Коллибри, андроид, ReactOS… продолжать) ?
7) куча всего другого.

Перечисленного мне хватило для выбора.

А вот теперь о минусах.
1) проблемы с io. Как дисковым, так и сетевым. С сетью — решаемо. С дисками — не очень. OpenVZ с дисками быстрее.
2) никому неизвестно как настроить сеть так, чтобы всё работало в условиях датацентра)
3) каждый чих требует ребута виртуалки.
4) нужно неплохо понимать в самом дебиане, чтобы полностью управлять гипервизором. Это не мышкотыкательный vbox.
5) нужно много писать в консоли =)
6) серверы всё же нужно иногда ребутить. И виртуалки тоже. Адекватный аптайм — 90 дней для виртуалки, 180 для сервера. Потом начинается деградация.
7) (лично для меня — плюс) оверселлинг памяти невозможен. Абсолютно. Отдаём работающим виртуалкам 8100 мб памяти, когда на сервере 7999 мб — и получаем wa в четверть проца =)

Я вас уже напугал) ? Ничего, я вас научу уму-разуму.

Давайте сразу оговоримся — вы не пишете что-то вроде «да вот такое решение уныло». Если критика — то конструктивная. Ибо других решений вы тупо не найдете =)

Ориентируюсь на максимальную прозрачность схемы и минимальное вмешательство в основную систему. Все мануалы актуальны для ДЦ hetzner’ов, российских ММТС-9, ТелеНета.

Переходим к подготовке дисковой подсистемы.