?

Log in

Previous Entry | Next Entry

KVM

Виртуализаця серверов - тема нынче весьма и весьма актуальная. Помимо оптимизации использования аппаратных ресурсов серверов, это еще и экономия как капитальных, так и операционных затрат.
В моем ведении находится с десяток серверов-супервизоров с порядка пятью десятками виртуальных машин.
Все они работают в связке Linux KVM + QEMU + VirtIO + libvirt.
Долгое время был вне тренда лишь домашний сервер. После долгих и непродолжительных экспериментов c Linux-ами со времен компьютеров на процессорах Pentium 1-го поколения, устоявшаяся продуктивная конфигурация в режиме 24х7 появилась у меня на процессоре P3-500. Конечно. в те времена никакой речи о нормальной виртуализации не было, по этому сервер (ОС + окружение) несколько раз мигрировали из одной железки в другому в неизменной парадигме: одна ОС - одно железо.
И вот, в очередной раз очередной комплект железа (Core 2 Duo, 3 Gb RAM) начал умирать. Окончательно эту конфигурацию поканали работы с постоянным отключением света у Мосэнерго. И, как обычно, вынуждено в срочном порядке мне пришлось закупать новое жедезо (слава богу, что половина из того что было нужно, наскреблась по сусекам). Вот, наконец, возможности и необходимость наконец пересеклись - старый сервер по плану дожен был виртуализоваться.
Большая часть работы прошла как по маслу: с помошью dd с жесткого диска снят слепок, сконфигурированые VLAN-ы перенесены отдельными бриджами, протащены последовательные порты, переконфигурирован mdraid, пересобран initrd. И вот тут меня настиг virtfs.
Дело в том, что долгосрочные данные у меня на старом сервере находились на аппаратном массиве RAID5 за контроллером Pronise. В запасниках у меня был еще Adaptec и еще немного дисков, на которых были данные. Тащить все это хозяйство на новый массив слепком не было резона. Можно было бы и сделать некоторый изврат вроде NFS или SMB-шары, но это именно изврат. VirtFS для этой задачи подходит как нельзя кстати.
VirtFS - это достаточно свежая поделка в QEMU. В гостевой ОС для нее отображается новое устройство, а в ядро ОС включена поддержка сетевой файловой системы 9P (разработанной в рамках проекта Plan 9).
Для Debian Squeeze сейчас все это хозяйство доступно в BackPorts. Пишу эту простыню, чтоб обратить внимание на несколько важных моментов информационной безопастности. Большинство формумов показывает явное недопонимание проблематики у контингента.
И так, у host-системы есть две системы организации разграничения доступа - passthrough и mapped. Для гостевой - user, uid, client. Определяют они, как для VirtFS будут определяться фактические права для доступа к файлам.
Основаная заковырка связана именно с host-системой, по этому я остановлюсь на ней поподробнее. Passthrough - это режим, когда UID, GID и аттрибуты host системы отображаются на гостевую 1:1. Пока я экспериментировал с ней, напоролся на несколько важных граблей: важно понимать, что сами идентификаторы (а сдедовательно пользователи и группы) должны иметься в обоих системах, иначе при авторизации пользователя и делегировании QUEMU прав операция в большинстве случаев неуспешна, а результат доступности данных не очевиден. Все это приводит к тому, что большинство пользователей, не разобравшись в проблематике, лепят просто o+w на все файлы на общей папке. То, что это epic fail в безопастности - говорить не стоит. Второй неприятностью является то, что QEMU должен работать под root-ом, чтобы иметь возможность оперировать setuid / setgid. Иными словами, passthrough нужен и эффективен только тогда, когда вся инфраструктура имеет общую директорию пользователей, а непосредственное применение прав на файловой системе хранилища необходимо. Для всех остальных случаев лучше использовать предназначенный для этого инструментарий вроде NFS или SMB.
Режим mapped куда более интересный и нам подходит куда больше. Идея его в том, что на файловой системе host доступ должен соответствовать эффективным правам доступа QEMU, права доступа гостевой системы сохраняются в расщиренных атрибутах файла. Недопонимание того, что просто необходимо разрешить на файловой системе использование расширенных атрибутов (указать опцию user_xattr в /etc/fstab) связано в 100% случаев с неработоспособностью этого режима у пользователей, а соответственно, его редкого использования. Режим mapped, на мой взгляд, наиболее предпочтителен для ситуаций, аналогичных моей.
С клиентскими политиками все просто: user - передавать эффективный идентификатор пользователя в QEMU, uid - передавать конкретный идентификатор, client - не проверять эффективные права на гостевой системе, используются только эффективные права QEMU.
Вот, вкратце, все.

Tags:

Comments

( 6 comments — Leave a comment )
jgbobby
Dec. 11th, 2012 11:11 pm (UTC)
Просто ради интереса токмо - а почему именно QEMU? Есть же вроде как бесплатные ESXi и Citrix, например. чем QEMU так отличился?
cyanide_burnout
Dec. 12th, 2012 05:36 am (UTC)
Не совсем корректно ставишь вопрос: все же не QEMU, а KVM, пока они не срослись в один проект. QEMU - эмуляция аппаратуры (не только x86, может эмулировать процесссор, но метдленно), KVM - реализация самой виртуальной машины x86 на базе технологий VT. Гипервизор работает в linux-овом ядре.
Теперь по твоему вопросу. Сначала, почему не Citrix. В Linux-овом мире их продукт все же известен как XEN. XEN силен своей паравиртуализацией. К сожалееию, XEN уже не развивается почти. Это очень сложная тема :)
Почему не VMWare? Ну или VirtualBox? Все же KVM и XEN являются "родными" для Linux - очень сильная поддержка этих проектов со стороны разработчиков ядра, в ядро в большинстве дистрибутивов по-умолчанию входят драйвера VirtIO (фактически - паравиртуализация устройств), по производительности и совместимости Linux-on-Linux лучще KVM и XEN не найти. Ну и потом, VMWare - коммерческий продукт, ESXi - способ подсадить тебя на их продукт, ибо является обрезком от ESX.

Edited at 2012-12-12 06:08 am (UTC)
cyanide_burnout
Dec. 12th, 2012 05:52 am (UTC)
jgbobby
Dec. 13th, 2012 03:44 am (UTC)
Спасибо
rlex
Dec. 15th, 2012 03:40 pm (UTC)
Зря ты так про ESXi, виртуализация у них - пушка. На моем домашнем серваке вертится, сервак вообще без хардов - ESXi на флешке, виртуалки на NAS, который отдает их по iSCSI/NFS. Минус - вендоклиент. Но есть VNC, есть SSH, есть web client наконец (правда он за бабло идет вместе с vcenter, но рутрекер никто не отменял, вмваре насрать на крякнутые версии если ты их дома используешь, у них даже защиты как таковой нет).
А раз уж используешь debian + kvm, посмотри в сторону proxmox ve. Получишь приятную веб-панельку с консолью.
cyanide_burnout
Dec. 24th, 2012 01:08 pm (UTC)
Не, я же не против ESXi. Но если говорить о легальном применении, то:
1) нужно $$$ - не наш вариант
2) используется проприетарный клиент - тоже минус
3) панель управления, если разворачивать на серваке, тянет за собой кучу всякого го**на

Proxmox имел и он мне не нравится всеми этими ненужными фитюлками. Использовать virsh и virt-manager вполне достаточно и безопасно.

Что касается LVM, QEMU и VirtIO - в целом для Linux все же лучще, ибо поддерживается нативно ядрами, что, несомненно большой плюс. Как писал уже, эксплуатирую такие связки года три уже на различных площадках с совершенно разной загрузкой и вполне доволен.
Пишу для читатей - кто еще на грабли то наступит, всякое бывает :)
( 6 comments — Leave a comment )