?

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

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)