KVM на CentOS 5.2: пробуем бюджетный гипервизор в production и сравниваем с VMware

В январе мы разбирали Hyper-V в бете Windows Server 2008 и объясняли клиентам, чем Type-1 гипервизор отличается от Virtual Server. Сейчас похожий вопрос, но со стороны Linux: KVM (Kernel-based Virtual Machine) попал в ядро Linux 2.6.20 ещё в прошлом году, и CentOS 5.2 его поддерживает из коробки. Значит, вместо покупки лицензий VMware можно поднять нормальный гипервизор на том же железе, на котором уже стоит Linux? Мы решили проверить, а не просто пересказать документацию.

Как это работает

KVM - это модуль ядра, который превращает Linux-хост в гипервизор. Точнее, технически это тоже Type-2 в классификации, но с важной оговоркой: KVM использует аппаратную виртуализацию процессора (Intel VT-x или AMD-V) напрямую через ядро, без посредника. В результате производительность гостей заметно ближе к нативной, чем у чисто программных решений.

В паре с KVM работает QEMU - эмулятор, который берёт на себя эмуляцию устройств (диск, сеть, видео). Самостоятельно QEMU работает медленно. В связке с KVM, когда CPU-инструкции уходят напрямую в железо через модуль ядра, а QEMU занимается только периферией - уже терпимо.

Установка на CentOS 5.2 выглядит примерно так:

yum install kvm kmod-kvm qemu libvirt python-virtinst
modprobe kvm-intel   # или kvm-amd, в зависимости от процессора

libvirt - это уровень управления поверх KVM/QEMU с нормальным API и командами типа virsh. Без него работать с несколькими VM можно, но неудобно.

Что мы гоняли на стенде

Стенд - двухъядерный сервер с Intel Xeon с поддержкой VT-x, 8 ГБ RAM, CentOS 5.2 x86_64. Запустили три гостевых VM: одну CentOS 5.2, одну Debian 4.0 и одну Windows Server 2003. Именно в таком порядке - потому что на Linux-гостях поставили virtio-драйверы (паравиртуализированные блочный контроллер и сетевой адаптер), а Windows Server 2003 пошёл без них на эмулированном Intel E1000 и IDE.

Разница ощутимая. Linux-гости с virtio работают заметно бодрее: дисковые операции быстрее, сетевая латентность ниже. Windows без virtio - это честный QEMU в режиме эмуляции IDE, и это чувствуется. Virtio-драйверы под Windows существуют, мы их нашли в исходниках, но ставить в production незнакомый неофициальный драйвер из исходников - сомнительное удовольствие.

Чего не хватает по сравнению с VMware

Тут честно, без прикрас.

Live migration - слабое место. У VMware ESX есть VMotion - живая миграция VM между хостами без остановки сервиса. В KVM/libvirt live migration есть, мы его потрогали, но в нашем конкретном тесте она прошла с секундным простоем - это не одно и то же. Для баз данных или чего-то чувствительного к паузам это важно. VMotion у VMware отполирован несколько лет, KVM - новичок в этой теме.

Snapshots - есть, но не такие. Снапшоты через QEMU работают, но уступают по интеграции с гостевой ОС. VMware Tools в гостевой системе позволяют делать consistent snapshot, то есть снимок с «заморозкой» файловой системы. Аналог через KVM требует возни.

Инструменты управления. virsh и virt-manager - это нормальные инструменты, и мы к ним привыкаем быстро. Но virt-manager - десктопное GTK-приложение, которое надо запускать с X11 (или через ssh -X). Для headless-сервера это неудобно. VMware VI Client на Windows-машине управляет ESX-хостами без таких приключений.

HA и кластер. VMware HA работает. KVM-кластер можно собрать через Heartbeat и общее хранилище, но это уже собственная архитектура, а не готовое решение.

Где KVM реально хорош

При этом есть ситуации, где KVM выигрывает не по очкам, а очевидно.

Dev-окружения. Поднять пачку Linux-VM для разработчиков или тестирования, без VMware-лицензий - KVM отлично справляется. Скорость достаточная, управление через virsh понятное, и это бесплатно.

Небольшие сервисы с Linux-гостями. Пара-тройка VM с веб-сервером, мониторингом, вспомогательными сервисами - на хорошем железе с virtio работает без нареканий. Мы подняли на стенде простой nginx-контейнер и Nagios-VM, обе работают стабильно несколько дней.

Экономия на лицензиях. VMware ESX + vCenter - это реальные деньги. Если задача не требует VMotion и полноценного HA, а серверов немного - можно обойтись.

Вывод, который у нас есть сейчас

Для клиентских сред, которые мы ведём в рамках сопровождения инфраструктуры, переводить production VMware на KVM мы не будем - не из-за снобизма, а потому что live migration и HA там реально нужны и работают. Но для dev-стендов и некритичных сервисов внутри той же инфраструктуры KVM смотрится как разумная опция.

Следующий шаг, который хочется сделать - поднять два KVM-хоста с общим хранилищем и посмотреть на live migration в более контролируемых условиях. Может, секундный простой в нашем тесте был следствием конфигурации, а не принципиальным ограничением. Посмотрим.