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.
Вот, вкратце, все.
В моем ведении находится с десяток серверов-супервизоров с порядка пятью десятками виртуальных машин.
Все они работают в связке 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.
Вот, вкратце, все.