≡× МЕНЮ

•  Билайн
• Билайн
• Вопросы
• Мегафон
• МТС

Типы виртуализации: OVZ и KVM. Используем KVM для создания виртуальных машин на сервере Kvm описание

Мы в Cloud4Y считаем лидирующим решением для виртуализации продукты VmWare. Тем не менее, мы интересуемся и другими решениями, в том числе, Xen и KVM. И вот что мы заметили: существует не так уж много информации, позволяющей сравнить эти гипервизоры: последние дельные исследования, которые мы нашли в сети, относятся к 2012 году и, конечно, уже не могут считаться актуальными. Сегодня мы представим вашему вниманию тоже не самое новое, но, на наш взгляд, достаточно полезное исследование, посвященное производительности гипервизоров KVM и Xen.

Гипервизор KVM

Да простят нас гуру виртуализации, но для начала мы напомним читателям, что такое гипервизор и для чего он нужен. Для выполнения разных по смыслу задач (разработки программного обеспечения, хостинга и т. п.) проще всего использовать виртуальные машины: они позволят иметь несколько разных ОС с соответствующей программной средой. Для простоты работы с виртуальными машинами применяются гипервизоры — программные средства, позволяющие быстро развертывать, останавливать и запускать ВМ. KVM является одним из наиболее широко распространенных гипервизоров.

KVM — это ПО, позволяющее организовывать виртуализацию на основе ПК под управлением ОС Linux и похожих. С недавнего времени KVM считается составляющей Linux-ядра и развивается параллельно ему. Этот гипервизор может использоваться только в системах, где виртуализация поддерживается аппаратно — с помощью процессоров Intel и AMD.

В процессе работы KVM осуществляет доступ к ядру напрямую посредством процессор-специфичного модуля (kvm-intel или kvm-amd). К тому же, в состав комплекса включено основное ядро — kvm.ko и элементы UI, включая широко распространенный QEMU. KVM дает возможность напрямую работать с файлами ВМ и дисковыми образами. Каждая виртуальная машина обеспечивается своим изолированным пространством.

Гипервизор Xen

Изначально студентами Кембриджа был запущен проект, который в итоге стал коммерческой версией Xen. Первый релиз датирован 2003 годом, а в 2007 исходный код выкупила компания Citrix. Xen — это кроссплатформенный гипервизор с большим функционалом и огромными возможностями, что дает возможность применять его в корпоративной сфере. Xen поддерживает паравиртуализацию — особый режим ядра операционной системы, когда ядро настроено на одновременную работу с гипервизором.

В код Xen добавлен только необходимый комплект функций: управление виртуальной памятью и тактовой частотой процессора, работа с DMA, таймером реального времени и прерываниями. Остальной функционал вынесен в домены, то есть в работающие в это время виртуальные машины. Таким образом, Xen — самый легкий гипервизор.

Суть исследования

Тестирование основано на использовании двух серверов SuperMicro, у каждого из которых четырехядерный процессор Intel Xeon E3-1220 с тактовой частотой 3,10 Гц, 24GB Kingston DDR3 RAM и четырьмя драйверами Western Digital RE-3 160GB (RAID 10). Версии BIOS идентичны.
Для хостинга и виртуальных машин мы взяли Fedora 20 (с SELinux). Вот взятые нами версии ПО:

• Kernel: 3.14.8
• Для KVM: qemu-kvm 1.6.2
• Для Xen: xen 4.3.2

Все корневые файловые системы — XFS с конфигурацией по умолчанию. Виртуальные машины созданы с помощью virt-Manager с использованием настроек по умолчанию, применимых к KVM и Xen. Виртуальные диски использовали raw-образы и было выделено 8 Гб РАМ с 4 vCPU (виртуальными процессорами). ОС, запущенные на Xen, использовали PVHVM.

Пояснения

Кто-то из вас может начать возмущаться — мол, владелец Fedora 20, Red Hat, тратит значительное количество усилий на поддержку именно KVM. Уточним: Red Hat не делали значительных продвижений по части Xen долгие годы.

Кроме того, конкуренция между гипервизорами жестко контролируется и сведена к минимуму. На большинстве виртуальных серверов у вас будет несколько виртуальных машин, борющихся за время процессора, устройства ввода/вывода и доступ к сети. Наше тестирование не принимает это во внимание. Один гипервизор может иметь низкую производительность при низкой конкуренции за ресурсы, а затем показать куда большую эффективность, чем конкуренты, когда борьба за ресурсы выше.

Исследование проводилось на процессорах Intel, поэтому его результаты могут отличаться для AMD и ARM.

Результаты

Тесты для виртуальных машин, установленных непосредственно на «железо», то есть, без операционной системы (далее — «железо»), послужили основой для тестирования виртуальных машин. Отклонение в производительности между двумя серверами без виртуализации составило 0.51% или менее.

Производительность KVM упала в пределах 1,5% по сравнению с «железом» практически во всех тестах. Только два теста показали иной результат: один из них — тест 7-Zip , где KVM показал себя на 2,79% медленнее, чем «железо». Странно, что KVM был на 4,11% быстрее в тесте PostMark (который симулировал сильно загруженный почтовый сервер). Производительность Xen сильнее отличалась от производительности «железа», чем в ситуации с KVM. В трех тестах Xen отличался на 2,5% от скорости «железа», в остальных тестах он оказался еще медленнее.

В тесте PostMark Xen был медленнее на 14.41%, чем «железо». При перезапуске результаты теста отличались от первоначальных на 2%. Лучший тест для KVM, MAFFT, оказался вторым в списке худших для Xen.

Вот краткий итог тестирования:

	Best Value	Bare Metal	KVM	Xen
Timed MAFFT Alignment	lower	7.78	7.795	8.42
Smallpt	lower	160	162	167.5
POV-Ray	lower	230.02	232.44	235.89
PostMark	higher	3667	3824	3205
OpenSSL	higher	397.68	393.95	388.25
John the Ripper (MD5)	higher	49548	48899.5	46653.5
John the Ripper (DES)	higher	7374833.5	7271833.5	6911167
John the Ripper (Blowfish)	higher	3026	2991.5	2856
CLOMP	higher	3.3	3.285	3.125
C-Ray	lower	35.35	35.66	36.13
7-Zip	higher	12467.5	12129.5	11879

Если вы хотите увидеть результаты полностью, пройдите по ссылке .

Вместо заключения

В нашем тестировании KVM был почти всегда на 2% медленнее, чем «железо». Xen оказался на 2,5% медленнее в трех тестах из десяти, а в остальных и того хуже: на 5-7%. Хотя KVM показал себя с лучшей стороны в тесте PostMark, следует отметить, что мы провели всего один I/O тест, и для получения более достоверной картины стоит провести еще несколько.

Для выбора правильного гипервизора необходимо правильно оценить характер своих нагрузок. Если ваши нагрузки предполагают меньший объем для процессора и больший для I/O, то можно провести больше I/O тестов. Если же вы работаете, в основном, с аудио и видео, попробуйте тесты x264 или mp3.

Как справедливо заметил mister_fog , в 2007 Citrix выкупила не исходный код Xen, а компанию XenSource, которая была основана разработчиками Xen и занималась коммерческим развитием этого открытого проекта. .

На днях вышел интересный отчет компании Principled Technologies, специализирующейся, в том числе, на всякого рода тестировании аппаратно-программных сред. В документе " " рассказывается о том, что на одном и том же оборудовании с помощью гипервизора ESXi можно запустить больше виртуальных машин, чем на гипервизоре KVM платформы RHEV.

Понятное дело, что исследование ангажированное (хотя бы, если посмотреть на заголовок), но поскольку таких документов не так много, мы решили обратить на него внимание.

Для тестирования использовался стоечный сервер Lenovo x3650 M5, на котором в виртуальных машинах работала СУБД Microsoft SQL Server 2016 с нагрузкой типа OLTP. В качестве основного показателя производительности использовался OPM (orders per minute), отображающий количественную оценку исполненных транзакций.

Если не использовать техники Memory Overcommit, то результат выполнения на 15 виртуальных машинах одного хоста в числе OPM примерно одинаковый на обоих гипервизорах:

А вот когда происходит увеличение числа виртуальных машин, то vSphere показывает себя значительно лучше:

Крестиками отмечены машины, которые на RHV просто не запустились, консоль продукта выдала вот такую ошибку:

Несмотря на включение техник оптимизации памяти в Red Hat Virtualization Manager (RHV-M), таких как memory ballooning и kernel shared memory, шестнадцатая виртуальная машина все равно отказывалась запускаться на KVM:

Ну а на vSphere продолжали наращивать число ВМ, пока не уперлись в недостаток ресурсов:

Получилось, что с техниками overcommit на vSphere получилось запустить 24 виртуальных машины, а на RHV - всего 15 штук. По итогу сделали вывод, что на VMware vSphere в 1,6 раза можно запустить больше виртуальных машин:

Не сказать, что это объективное тестирование, но очевидно, что ESXi в данном случае работает лучше KVM с точки зрения всяких оптимизаций памяти и прочих ресурсов ВМ.

Таги: VMware, Red Hat, Performance, RHV, vSphere, ESXi, KVM
Таги: KVM, oVirt, Open Source, Update

Напомним, что RHEV основана на гипервизоре Kernel-based Virtual Machine (KVM) и поддерживает открытую облачную архитектуру OpenStack. Давайте посмотрим, что нового появилось в обновленном RHEV версии 3.4.

Инфраструктура

• Сервис настройки SNMP для поддержки сторонних систем мониторинга.
• Сохранение настроек облачной инсталляции RHEV для возможности ее восстановления при сбое или для целей тиражирования в других облаках.
• Переписаны и улучшены сервисы аутентификации RHEV.
• Возможность горячего добавления процессора в ВМ (Hot Plug CPU). Тут нужна поддержка со стороны ОС.
• Нерутовые юзеры теперь имеют доступ к логам.
• Новый установщик, основанный на TUI (textual user interface).
• Поддержка IPv6.
• Возможность выбора соединения с консолью ВМ в режиме Native Client или noVNC.
• Возможность изменения некоторых настроек запущенной виртуальной машины.
• Полная поддержка RHEL 7 в качестве гостевой ОС.
• Возможность включения/отключения KSM (Kernel Samepage Merging) на уровне кластера.
• Возможность перезагрузки ВМ из RHEVM или консольной командой.

Сетевое взаимодействие

• Более плотная интеграция с инфраструктурой OpenStack:
• Улучшения безопасности и масштабируемости для сетей, развернутых с помощью Neutron .
• Поддержка технологии Open vSwitch (расширяемый виртуальный коммутатор) и возможностей SDN -сетей.
• Network Labels - метки, которые можно использовать при обращении к устройствам.
• Корректный порядок нумерации виртуальных сетевых адаптеров (vNIC).
• Поддержка iproute2.
• Единая точка конфигурации сетевых настроек множества хостов в указанной сети.

Возможности хранилищ

• Смешанные домены хранилищ (mixed storage domains) - возможность одновременного использования дисковых устройств из хранилищ iSCSI, FCP, NFS, Posix и Gluster для организации хранения виртуальных машин.
• Multiple Storage Domains - возможность распределить диски одной виртуальной машины по нескольким хранилищам в пределах датацентра.
• Возможность указания дисков, которые будут участвовать в создании снапшотов, а также тех, которые не будут.
• Улучшен механизм восстановления ВМ из резервной копии - теперь есть возможность указать снапшот состояния, в которое хочется откатиться.
• Асинхронное управление задачами Gluster-хранилищ.
• Read-Only Disk for Engine - эта функция дает средству управления Red Hat Enterprise Virtualization Manager возможность использовать диски только для чтения.
• Доступ по нескольким путям (multipathing) для хранилищ iSCSI.

Средства виртуализации

• Агенты гостевых ОС (ovirt-guest-agent) для OpenSUSE и Ubuntu.
• SPICE Proxy - возможность использовать прокси-серверы для доступа пользователей к своим ВМ (если они, например, находятся за пределами инфраструктурной сети).
• SSO (Single Sign-On) Method Control - возможность переключаться между различными механизмами сквозной аутентификации. Пока есть только два варианта: guest agent SSO и без SSO.
• Поддержка нескольких версий одного шаблона виртуальной машины.

Улучшения планировщика и средств обеспечения уровня обслуживания

• Улучшения планировщика виртуальных машин.
• Группы Affinity/Anti-Affinity (правила существования виртуальных машин на хостах - размещать машины вместе или раздельно).
• Power-Off Capacity - политика электропитания, позволяющая выключить хост и подготовить его виртуальные машины к миграции в другое место.
• Even Virtual Machine Distribution - возможность распределения виртуальных машин по хостам на базе количества ВМ.
• High-Availability Virtual Machine Reservation - механизм позволяет гарантировать восстановление виртуальных машин в случае отказа одного или нескольких хост-серверов. Он работает на базе расчета доступной емкости вычислительных ресурсов хостов кластера.

Улучшения интерфейса

• Фиксы багов, касающихся того, что интерфейс не всегда реагировал на происходящие в инфраструктуре события.
• Поддержка низких разрешений экрана (когда не было видно некоторых элементов консоли управления на низких разрешениях).

Скачать Red Hat Enterprise Virtualization 3.4 можно по этой ссылке . Документация доступна .

Таги: Red Hat, RHEV, Update, Linux, KVM

Новая версия ОС RHEL имеет множество новых интересных возможностей, среди которых немало касаются технологий виртуализации. Некоторые основные новые возможности RHEL 7:

• Встроенная поддержка упакованных приложений в формате Docker.
• Kernel patching utility Technology Preview - патчинг ядра без перезагрузки ОС.
• Прямая и непрямая интеграция с Microsoft Active Directory, подробнее описано .
• Для разделов boot, root и user data дефолтной файловой системой теперь является XFS.
  • Для XFS максимальный размер файловой системы увеличен со 100 ТБ до 500 ТБ.
  • Для ext4 этот размер увеличен с 16 ТБ до 50 ТБ.
• Улучшенный процесс установки ОС (новый визард).
• Возможность управления серверами Linux с использованием Open Linux Management Infrastructure (OpenLMI).
• Улучшения файловых систем NFS и GFS2.
• Новые возможности технологии виртуализации KVM.
• Возможность выполнять RHEL 7 в качестве гостевой OS.
• Улучшения NetworkManager и новая утилита командной строки для выполнения сетевых задач NM-CLI.
• Поддержка сетевых соединений Ethernet на скорости до 40 Гбит/с.
• Поддержка беспроводной технологии WiGig (IEEE 802.11ad) (на скорости до 7 Гбит/с).
• Новый механизм Team Driver, который виртуально объединяет сетевые устройства и порты в единый интерфейс на уровне L2.
• Новый динамический сервис FirewallD, представляющий собой гибкий сетевой экран, имеющий преимущество перед iptables и поддерживающий несколько трастовых зон (network trust zones).
• GNOME 3 в режиме классического рабочего стола.

Более подробно о новых возможностях RHEL 7 рассказано Red Hat.

В плане виртуализации в Red Hat Enterprise Linux 7 появились следующие основные нововведения:

• Технологическое превью возможности virtio-blk-data-plane, которая позволяет выполнять команды ввода-вывода QEMU в отдельном оптимизированном потоке.
• Появилось технологическое превью технологии PCI Bridge, позволяющей поддерживать более чем 32 PCI-устройства в QEMU.
• QEMU Sandboxing - улучшенная изоляция между гостевыми ОС хоста RHEL 7.
• Поддержка "горячего" добавления виртуальных процессоров машинам (vCPU Hot Add).
• Multiple Queue NICs - каждый vCPU имеет собственные очереди на передачу и получение, что позволяет не задействовать другие vCPU (только для гостевых ОС Linux).
• Технология сжатия страниц памяти при горячей миграции (Page Delta Compression) позволяет гипервизору KVM проводить миграцию быстрее.
• В KVM появились функции поддержки паравиртуализованных функций ОС Microsoft, например, Memory Management Unit (MMU) и Virtual Interrupt Controller. Это позволяет гостевым ОС Windows работать быстрее (по умолчанию эти функции отключены).
• Поддержка технологии EOI Acceleration, основанной на интерфейсе Advanced Programmable Interrupt Controller (APIC) от Intel и AMD.
• Технологическое превью поддержки USB 3.0 в гостевых ОС на KVM.
• Поддержка гостевых ОС Windows 8, Windows 8.1, Windows Server 2012 и Windows Server 2012 R2 на гипервизоре KVM.
• Функции I/O Throttling для гостевых ОС на QEMU.
• Поддержка технологий Ballooning и transparent huge pages.
• Новое устройство virtio-rng доступно как генератор случайных чисел для гостевых ОС.
• Поддержка горячей миграции гостевых ОС с хоста Red Hat Enterprise Linux 6.5 на хост Red Hat Enterprise Linux 7.
• Поддержка назначения устройств NVIDIA GRID и Quadro как второго устройства в дополнение к эмулируемому VGA.
• Технология Para-Virtualized Ticketlocks, улучшающая производительность, когда виртуальных vCPU больше чем физических на хосте.
• Улучшенная обработка ошибок устройств PCIe.
• Новый драйвер Virtual Function I/O (VFIO) улучшающий безопасность.
• Поддержка технологии Intel VT-d Large Pages, когда используется драйвер VFIO.
• Улучшения отдачи точного времени виртуальным машинам на KVM.
• Поддержка образов формата QCOW2 version 3.
• Улучшенные статистики Live Migration - total time, expected downtime и bandwidth.
• Выделенный поток для Live Migration, что позволяет горячей миграции не влиять на производительность гостевых ОС.
• Эмуляция процессоров AMD Opteron G5.
• Поддержка новых инструкций процессоров Intel для гостевых ОС на KVM.
• Поддержка форматов виртуальных дисков VPC и VHDX в режиме "только для чтения".
• Новые возможности утилиты libguestfs для работы с виртуальными дисками машин.
• Новые драйверы Windows Hardware Quality Labs (WHQL) для гостевых ОС Windows.
• Интеграция с VMware vSphere: Open VM Tools, драйверы 3D-графики для OpenGL и X11, а также улучшенный механизм коммуникации между гостевой ОС и гипервизором ESXi.

Release Notes новой версии ОС доступны по этой ссылке . О функциях виртуализации в новом релизе RHEL 7 можно почитать (а - на русском). Исходные коды rpm-пакетов Red Hat Enterprise Linux 7 теперь доступны только через Git-репозиторий .

Таги: Linux, QEMU, KVM, Update, RHEL, Red Hat

Компания Ravello нашла интересный способ использовать вложенную виртуализацию в своем продукте Cloud Application Hypervisor , который позволяет универсализовать развертывание ВМ разных платформ виртуализации в публичных облаках различных сервис провайдеров.

Основным компонентом этой системы является технология HVX - собственный гипервизор (на базе Xen), являющийся частью ОС Linux и запускающий вложенные виртуальные машины без их изменения средствами техник бинарной трансляции. Далее эти машины можно разместить в облаках Amazon EC2, HP Cloud, Rackspace и даже частных облаках, управляемых VMware vCloud Director (поддержка последнего ожидается в скором времени).

Продукт Ravello - это SaaS-сервис, а такие матрешки можно просто загружать на любой из поддерживаемых хостингов, вне зависимости от используемого им гипервизора. Виртуальная сеть между машинами создается через L2-оверлей над существующей L3-инфраструктурой хостера с использованием GRE-подобного протокола (только на базе UDP):

Сама механика предлагаемого сервиса Cloud Application Hypervisor такова:

• Пользователь загружает виртуальные машины в облако (поддерживаются машины, созданные на платформах ESXi/KVM/Xen).
• С помощью специального GUI или средствами API описывает многомашинные приложения.
• Публикует свои ВМ в одном или нескольких поддерживаемых облаках.
• Получившаяся конфигурация сохраняется в виде снапшота в облаке Ravello (потом в случае чего ее можно восстановить или выгрузить) - это хранилище может быть создано как на базе облачных хранилищ Amazon S3, CloudFiles, так и на базе собственных блочных хранилищ или NFS-томов.
• После этого каждый пользователь может получить многомашинную конфигурацию своего приложения по требованию.

Очевидный вопрос, который возникает первым: что с производительностью? Ну, во-первых, решение Cloud Application Hypervisor рассчитано на команды разработки и тестирования, для которых производительность не является критичным фактором.

А во-вторых, результаты тестов производительности таких вложенных матрешек показывают не такие уж и плохие результаты:

Для тех, кто заинтересовался технологией HVX, есть хорошее обзорное видео на рунглише:

Таги: Rovello, Nested Virtualization, Cloud, HVX, VMware, ESXi, KVM, Xen, VMachines, Amazon, Rackspace

Новая версия открытой платформы виртуализации RHEV 3.0 основана на дистрибутиве Red Ha Enterprise Linux версии 6 и, традиционно, гипервизоре KVM.

Новые возможности Red Hat Enterprise Virtualization 3.0:

• Средство управления Red Hat Enterprise Virtualization Manager теперь построен на базе Java, запущенной на платформе JBoss (ранее использовался.NET, и, соответственно, была привязка к Windows, теперь же можно использовать Linux для управляющего сервера).
• Портал самообслуживания пользователей, позволяющий им самостоятельно развертывать виртуальные машины, создавать шаблоны и администрировать собственные окружения.
• Новый RESTful API, позволяющиий получить доступ ко всем компонентам решения из сторонних приложений.
• Расширенный механизм администрирования, предоставляющий возможность гранулированного назначения пермиссий, делегирования полномочий на базе ролей пользователей и иерархическое управление привилегиями.
• Поддержка локальных дисков серверов в качестве хранилищ виртуальных машин (но для них не поддерживается Live Migration).
• Интегрированный механизм отчетности, позволяющий анализировать исторические данные о производительности и строить прогнозы по развитию виртуальной инфраструктуры.
• Оптимизация для WAN-соединений, включая технологии dynamic compression (сжатие картинки) и автоматической настройки эффектов рабочего стола и глубины цветности. Кроме того, новая версия SPICE имеет расширенную поддержку десктопов с гостевыми ОС Linux.
• Обновленный гипервизор KVM на основе последнего Red Hat Enterprise Linux 6.1, вышедшего в мае 2011 года.
• Поддержка до 160 логических CPU и 2 ТБ памяти для хост-серверов, 64 vCPU и 512 ГБ памяти - для виртуальных машин.
• Новые возможности по администрированию больших инсталляций RHEV 3.0.
• Поддержка больших страниц памяти (Transparant Huge Pages, 2 МБ вместо 4 КБ) в гостевых ОС, что увеличивает производительность за счет меньшего количества чтений.
• Оптимизация компонента vhost-net. Теперь сетевой стек KVM перемещён из пользовательского режима в режим ядра, что существенно увеличивает производительность и уменьшает задержки в сети.
• Использование функций библиотеки sVirt, обеспечивающей безопасность гипервизора.
• Появился паравиртуализованный контроллер x2paic, который уменьшает overhead на содержание ВМ (особенно эффективен для интенсивных нагрузок).
• Технология Async-IO для оптимизации ввода-вывода и повышения производительности.

Скачать финальный релиз Red Hat Enterprise Virtualization 3.0 можно по этой ссылке .

Ну и, напоследок, небольшой видео-обзор Red Hat Enterprise Virtualization Manager 3.0 (RHEV-M):

Таги: Red Hat, Enterprise, Update, KVM, Linux

Молодцы NetApp! Роман, ждем перевода на русский язык)

Таги: Red Hat, KVM, NetApp, Storage, NFS

Продукт ConVirt 2.0 Open Source позволяет управлять гипервизорами Xen и KVM, входящими в бесплатные и коммерческие издания дистрибутивов Linux, развертывать виртуальные серверы из шаблонов, осуществлять мониторинг производительности, автоматизировать задачи администратора и настраивать все аспекты виртуальной инфраструктуры. ConVirt 2.0 поддерживает функции горячей миграции виртуальных машин, "тонкие" виртуальные диски (растущие по мере наполнения данными), контроль ресурсов виртуальных машин (в т.ч. запущенных), обширные функции мониторинга и средства интеллектуального размещения виртуальных машин на хост-серверах (ручная балансировка нагрузки).

ConVirt 2.0 пока существует только в издании Open Source, однако разработчики обещают в скором времени выпустить издание ConVirt 2.0 Enteprise, которое будет отличаться от бесплатного следующими возможностями:

Feature	ConVirt 2.0 Open Source	ConVirt 2.0 Enterprise
Architecture
Multi-platform Support
Agent-less Architecture
Universal Web Access
Datacenter-wide Console
Administration
Start, Stop, Pause, Resume
Maintanence Mode
Snapshot
Change Resource Allocation on a Running VM
Monitoring
Real-time Data
Historical Information
Server Pools
Storage Pools
Alerts and Notifications
Provisioning
Templates-based Provisioning
Template Library
Integrated Virtual Appliance Catalogues
Thin Provisioning
Scheduled Provisioning
Automation
Intelligent Virtual Machine Placement
Live Migration
Host Private Networking
SAN, NAS Storage Support
Advanced Automation
High Availability
Backup and Recovery
VLAN Setup
Storage Automation
Dynamic Resource Allocation
Power Saving Mode
Security
SSH Access
Multi-user Administration
Auditing
Fine Grained Access Control
Integration
Open Repository
Command Line Interface
Programmatic API

Таги: Xen, KVM, Convirt, Citrix, Red Hat, Бесплатно, Open Source,

Компания Convirture, занимавшаяся в 2007 году проектом XenMan, представлявшим собой GUI для управления гипервизором XEN, выпустила недавно релиз бесплатного продукта Convirture ConVirt 1.0, на который изменил свое название XenMan.

С помощью ConVirt можно управлять гипервизорами Xen и KVM, используя следующие возможности:

• Управление несколькими хост-серверами.
• Снапшоты (snapshots).
• Горячая миграция виртуальных машин между хостами (Live Migration).
• Резервное копирование ВМ.
• Простейший мониторинг хостов и виртуальных машин.
• Поддержка виртуальных модулей (Virtual Appliances).

Скачать Convirture ConVirt 1.0 можно по этой ссылке:

Convirture ConVirt 1.0
Таги: Xen, KVM

Прежде, чем начать наш обзор, стоит разобраться, что представляет из себя гипервизор, и какие функции он выполняет. При выполнении большого количества разнообразных задач очень удобно пользоваться . Это связно с тем, что они дают возможность на одном физическом сервере размещать несколько операционных систем, каждая из которых оснащена собственным программным обеспечением для решения разнообразных задач. Чтобы обеспечить простое взаимодействие с такими виртуальными машинами, используются гипервизоры. Они представляют из себя программное обеспечение, которое и позволяет осуществлять управление виртуальными машинами: устанавливать, включать и выключать их. Одним из самых популярных гипервизоров на сегодняшний день можно назвать KVM.

Гипервизор KVM

Он дает возможность осуществлять виртуализацию на серверах с операционной системой Linux. Однозначным плюсом является то, что данный гипервизор входит в состав ядра Linux, поэтому он постоянно совершенствуется и обновляется. Использовать его можно только в случае аппаратной виртуализации – с помощью процессоров Intel или Amd. Процессорный модуль KVM дает ему возможность осуществлять доступ непосредственно к ядру. Благодаря этому можно напрямую управлять файлами виртуальных машин и образами дисков. Для каждой ВМ предназначено индивидуальное пространство.

Гипервизор Xen

Впервые разработанный еще Кэмбриджскими студентами, данный проект быстро стал коммерческим благодаря своей перспективности. Кроссплатформенность и широкий функционал Xen делает его возможности достаточно обширными для применения в офисах крупных компаний и корпораций. Его ядро обладает режимом паравиртуализации, то есть его можно настроить на одновременное взаимодействие с гипервизором.

Код этого гипервизора не перегружен лишними функциями. Он оснащен возможностями управления ОЗУ, частотой работы процессора, работы c прямым доступом к памяти, а также таймером. Все остальные функции выполняют подключенные к работе в данный момент ВМ. Перечисленные преимущества делают работу с Xen простой и удобной даже для человека, познания которого не очень глубоки в данной сфере.

Исследование

Для того, чтобы сравнить два гипервизора, нужно провести их тестирование. Для этого были взяты два сервера с абсолютно идентичным железом и ПО, за исключением, конечно же, рассматриваемых гипервизоров. Все настройки для созданных виртуальных машин были выставлены по умолчанию в соответствии с базовыми настройками обоих гипервизоров. Каждому варианту было выделено одинаковое количество памяти.

Уточним, что мнения о том, что выбранный нами дистрибутив для ОС – Fedora 20 от Red Hat – лучше подходит для KVM не совсем верны. Мы не рассматриваем борьбу ВМ за ресурсы процессора во время одновременной работы, так как при разной степени конкуренции гипервизоры могут показывать разную производительность. Поэтому мы считаем условия соревнования честными для обеих сторон.

Результаты

Тестирование основывалось на замере результатов тестов для ВМ, расположенных на одном только железе, исключая программное обеспечение. Отклонение в производительности двух серверов без виртуализации получилось меньше половины процента.

Первый кандидат – KVM показал производительность в среднем на полтора процента ниже производительности железа. В тесте на 7-ZIP данный гипервизор оказался почти на 3 процента медленнее, а в тесте на PostMark на целых 4 с лишним процента быстрее железа. Результаты Xen оказались хуже, он не превзошел своего конкурента ни в одном из тестов, отстав от железа на 2.5 процента в трех тестах, а в остальных показал себя еще хуже. Самое сильное отклонение выявилось, как и у KVM – в тесте на PostMark, но Xen не обогнал железо, как его конкурент, а отстал практически на 15 процентов. Повторные результаты теста отклонились от предыдущих не более, чем на 2 процента. Более подробно с результатами тестирования вы можете ознакомиться в таблице:

Итог

KVM всегда показывал себя медленнее железа примерно на 2 процента, но не более того. Xen же уступал железу на 2.5-7 процентов в большинстве из тестов. Хорошие результаты KVM в тесте на PostMark могут быть не совсем точными про причине недостаточного количества проведенных тестов. Чтобы принять правильное решение в выборе теста гипервизора, изучите характер нагрузок своего сайта. При необходимости проведите больше тестов для получения более точных результатов.

Проверка поддержки гипервизора

Проверяем, что сервер поддерживает технологии виртуализации:

cat /proc/cpuinfo | egrep "(vmx|svm)"

В ответ должны получить что-то наподобие:

flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm epb tpr_shadow vnmi flexpriority ept vpid dtherm ida arat

В противном случае, заходим в БИОС, находим опцию для включения технологии виртуализации (имеет разные названия, например, Intel Virtualization Technology или Virtualization) и включаем ее — задаем значение Enable .

Также проверить совместимость можно командой:

* если команда вернет ошибку «kvm-ok command not found» , установите соответствующий пакет: apt-get install cpu-checker .

Если видим:

INFO: /dev/kvm exists
KVM acceleration can be used

значит поддержка со стороны аппаратной части есть.

Подготовка сервера

Для нашего удобства, создадим каталог, в котором будем хранить данные для KVM:

mkdir -p /kvm/{vhdd,iso}

* будет создано два каталога: /kvm/vhdd (для виртуальных жестких дисков) и /kvm/iso (для iso-образов).

Настроим время:

\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

* данная команда задает зону в соответствии с московским временем.

ntpdate ru.pool.ntp.org

* выполняем синхронизацию с сервером времени.

Установка и запуск

Устанавливаем KVM и необходимые утилиты управления.

а) Ubuntu до версии 18.10

apt-get install qemu-kvm libvirt-bin virtinst libosinfo-bin

б) Ubuntu после 18.10:

apt-get install qemu-kvm libvirt-daemon-system libvirt-bin virtinst libosinfo-bin

* где qemu-kvm — гипервизор; libvirt-bin — библиотека управления гипервизором; virtinst — утилита управления виртуальными машинами; libosinfo-bin — утилита для просмотра списка вариантов операционных систем, которые могут быть в качестве гостевых.

Настроим автоматический запуск сервиса:

systemctl enable libvirtd

Запустим libvirtd:

systemctl start libvirtd

Настройка сети

Виртуальные машины могут работать за NAT (в качестве которого выступает сервер KVM) или получать IP-адреса из локальной сети — для этого необходимо настроить сетевой мост. Мы настроим последний.

Используя удаленное подключение, внимательно проверяйте настройки. В случае ошибки соединение будет прервано.

Устанавливаем bridge-utils:

apt-get install bridge-utils

а) настройка сети в старых версиях Ubuntu (/etc/network/interfaces).

Открываем конфигурационный файл для настройки сетевых интерфейсов:

vi /etc/network/interfaces

И приведем его к виду:

#iface eth0 inet static
# address 192.168.1.24
# netmask 255.255.255.0
# gateway 192.168.1.1
# dns-nameservers 192.168.1.1 192.168.1.2

Auto br0
iface br0 inet static
address 192.168.1.24
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.1 192.168.1.2
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off

* где все, что закомментировано — старые настройки моей сети; br0 — название интерфейса создаваемого моста; eth0 — существующий сетевой интерфейс, через который будет работать мост.

Перезапускаем службу сети:

systemctl restart networking

б) настройка сети в новых версиях Ubuntu (netplan).

vi /etc/netplan/01-netcfg.yaml

* в зависимости от версии системы, конфигурационной файл yaml может иметь другое название.

Приводим его к виду:

network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: false
dhcp6: false
wakeonlan: true

Bridges:
br0:
macaddress: 2c:6d:45:c3:55:a7
interfaces:
- eth0
addresses:
- 192.168.1.24/24
gateway4: 192.168.1.1
mtu: 1500
nameservers:
addresses:
- 192.168.1.1
- 192.168.1.2
parameters:
stp: true
forward-delay: 4
dhcp4: false
dhcp6: false

* в данном примере мы создаем виртуальный бридж-интерфейс br0 ; в качестве физического интерфейса используем eth0 .

Применяем сетевые настройки:

Настаиваем перенаправления сетевого трафика (чтобы виртуальные машины с сетевым интерфейсом NAT могли выходить в интернет):

vi /etc/sysctl.d/99-sysctl.conf

Добавляем строку:

net.ipv4.ip_forward=1

Применяем настройки:

sysctl -p /etc/sysctl.d/99-sysctl.conf

Создание виртуальной машины

Для создания первой виртуальной машины вводим следующую команду:

virt-install -n VM1 \
--autostart \
--noautoconsole \
--network=bridge:br0 \
--ram 2048 --arch=x86_64 \
--vcpus=2 --cpu host --check-cpu \
--disk path=/kvm/vhdd/VM1-disk1.img,size=16 \
--cdrom /kvm/iso/ubuntu-18.04.3-server-amd64.iso \
--graphics vnc,listen=0.0.0.0,password=vnc_password \
--os-type linux --os-variant=ubuntu18.04 --boot cdrom,hd,menu=on

• VM1 — имя создаваемой машины;
• autostart — разрешить виртуальной машине автоматически запускаться вместе с сервером KVM;
• noautoconsole — не подключается к консоли виртуальной машины;
• network — тип сети. В данном примере мы создаем виртуальную машину с интерфейсом типа «сетевой мост». Для создания внутреннего интерфейса с типом NAT вводим --network=default,model=virtio ;
• ram — объем оперативной памяти;
• vcpus — количество виртуальных процессоров;
• disk — виртуальный диск: path — путь до диска; size — его объем;
• cdrom — виртуальный привод с образом системы;
• graphics — параметры подключения к виртуальной машины с помощью графической консоли (в данном примере используем vnc); listen — на какой адресе принимает запросы vnc (в нашем примере на всех); password — пароль для подключения при помощи vnc;
• os-variant — гостевая операционная система (весь список мы получали командой osinfo-query os , в данном примере устанавливаем Ubuntu 18.04).

Подключение к виртуальной машине

На компьютер, с которого планируем работать с виртуальными машинами, скачиваем VNC-клиент, например, TightVNC и устанавливаем его.

На сервере вводим:

virsh vncdisplay VM1

команда покажет, на каком порту работает VNC для машины VM1. У меня было:

* :1 значит, что нужно к 5900 прибавить 1 — 5900 + 1 = 5901.

Запускаем TightVNC Viewer, который мы установили и вводим данные для подключения:

Кликаем по Connect . На запрос пароля вводим тот, что указали при создании ВМ, (vnc_password ). Мы подключимся к виртуальной машине удаленной консолью.

Если мы не помним пароль, открываем настройку виртуальной машины командой:

И находим строку:

* в данном примере для доступа к виртуальной машине используется пароль 12345678 .

Управление виртуальной машиной из командной строки

Примеры команд, которые могут пригодиться при работе с виртуальными машинами.

1. Получить список созданных машин:

virsh list --all

2. Включить виртуальную машину:

virsh start VMname

* где VMname — имя созданной машины.

3. Выключить виртуальную машину:

ubuntu-vm-builder — пакет, разработанный компанией Canonical для упрощения создания новых виртуальных машин.

Для его установки вводим:

apt-get install ubuntu-vm-builder

Гипервизоры (технологии виртуализации) существуют более 30 лет и за это время сумели стать одним из главных «винтиков» в составе облачной экосистемы. Многие компании, подбирающие решения для виртуализации, останавливают свой выбор на двух популярных гипервизорах - VMware и KVM. Предлагаем разобраться какой же из них лучше. Но для начала немного теории.

Что такое гипервизор?

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

Гипервизоры делятся на два типа: первые работают непосредственно с сервером, а операционная система пользователей работает поверх гипервизора. Эти гипервизоры могут предоставлять некоторым пользователям функции управления сервером и большинство предприятий используют именно такие гипервизоры.

Гипервизоры второго типа, также известные как размещенные гипервизоры (Hosted Hypervisor), работают с операционной системой, установленной на сервере. А операционные системы для новых пользователей создаются поверх гипервизора.

Настольные гипервизоры, такие как Oracle VirtualBox или VMware Workstation, являются гипервизорами второго типа, а VMware и KVM – первого. VMware и KVM устанавливаются непосредственно на сервер и не требуют установки какой-либо операционной системы.

VMware vSphere

Перед покупкой VMware vSphere можно попробовать поработать в пробной версии (60 дней), после чего необходимо покупать лицензию, либо мириться с ограничениями бесплатной версии.

В бесплатной версии, которая называется VMware Free vSphere Hypervisor, нет ограничений для хоста по процессорам и памяти, зато есть ряд других:

• API продукта доступно только для чтения;
• виртуальная машина не может иметь более 8 ядер;
• ее нельзя использовать вместе с Veeam для создания резервных копий;
• подключение к vCenter Server не поддерживается;
• не поддерживается и высокая доступность, а также технологии VM Host Live Migration и VM Storage Live Migration.

Продукт от VMware отличается от аналогов поддержкой большого количества операционных систем - Windows, Linux, Solaris, FreeBSD, Netware, MacOS и других.

Установка дистрибутива VMware на сервер очень проста: достаточно загрузиться с CD, флешки или через PXE. К тому же поддерживаются сценарии, позволяющие автоматизировать процесс инсталляции программного обеспечения, настройку сети и подключения к vCenter Server.

Немаловажно и наличие специального конвертера VMware vCenter Converter , позволяющего использовать в ESXi образы MS Virtual Server, Virtual PC, Hyper-V, а также физические серверы и образы дисковых разделов, созданных такими программами как Acronis True Image, Norton Ghost и другими.

У VMware vSphere есть встроенная интеграция с Microsoft Active Directory, то есть аутентификацию пользователей в частном или гибридном облаке можно производить при помощи доменных служб Microsoft. Гибкое распределение ресурсов позволяет использовать горячее добавление CPU, ОЗУ и жесткого диска (в том числе изменять размер текущего жесткого диска без перезагрузки).

VMware Fault Tolerate - технология VMware, предназначенная для защиты виртуальных машин с помощью кластеров непрерывной доступности. При отказе хоста (сервера ESXi) с основной (Primary) рабочей копией виртуальной машины, защищенная виртуальная машина мгновенно переключится на «вторичную» (Secondary) или «теневую» копию, работающую на другом сервере ESXi. Для машин, защищенных VMware Fault Tolerance, происходит постоянное (в реальном времени) копирование всего состояния памяти и процессорных инструкций с основной копии на «теневую». При сбое основного хоста ESXi, пользователи даже не заметят процесса переключения на второй узел. Именно этим Fault Tolerance отличается от High Availability. В High Availability при отказе физического сервера виртуальные машины будут перезапущены на других узлах, и пока операционные системы перезагружаются пользователи не смогут получить доступ к виртуальным серверам.

Кроме VMware Foult Tolerate, лицензия VMware vCloud Suite Enterprise обеспечивает высокую доступность, отказоустойчивость и восстановление после аварий с помощью функций vSphere HA, vMotion, Storage vMotion, и vCenter Site Recovery Manager.

Для уменьшения плановых остановок в обслуживании серверов или систем хранения данных (СХД), функции vMotion и Storage vMotion в онлайн-режиме переносят виртуальные машины и их диски без остановки работы приложений и пользователей. Функция vSphere Replication поддерживает разные варианты репликации vCenter Site Recovery Manager (SRM) для защиты от крупных аварий. SRM обеспечивает централизованное планирование послеаварийного восстановления, автоматические Failover и Failback с резервного сайта или из облака vCloud, а также тестирование послеаварийного восстановления без прерывания работы приложений.

К особенностям этого гипервизора стоит отнести избирательность к железу - перед установкой необходимо тщательно проверить имеющееся оборудование на совместимость с нужной версией ESXi. Для этого на сайте VMware есть специальная .

Лицензирование продуктов VMware имеет свои особенности. Дополнительную путаницу добавляют периодические изменения (от версии к версии vSphere) в лицензионной политике VMware. Существует несколько пунктов, которые нужно учесть перед приобретением лицензий VMware vSpere:

• лицензирование гипервизора выполняется по числу физических процессоров (CPU). Каждый CPU сервера требует отдельной лицензии vSphere (ядра не являются физическими процессорами и не учитываются в лицензировании);
• доступный функционал сервера ESXi определяется установленной на нем лицензией vSphere. Подробное руководство по лицензиям есть на ;
• для каждой купленной лицензии vShpere необходимо приобретать пакет сервисной поддержки (минимум на год);
• VMware не накладывает ограничения на количество памяти (RAM), установленной на сервере, и на количество запущенных виртуальных машин.

Управлять множеством хостов с гипервизорами ESXi, СХД и сетевым оборудованием можно с помощью еще одного продукта VMware - Vcenter Server. Подключаемые модули клиента vSphere, предоставляемые партнерами VMware, дают IT-администраторам возможность управлять сторонними элементами в дата-центре непосредственно из этой консоли. Поэтому пользователи vCenter могут выполнять резервное копирование, защищать данные, управлять серверами, сетями и безопасностью непосредственно из интерфейса vCenter. В этой же консоли можно настроить триггеры, которые оповестят о возникших проблемах, и получить данные о работе всей инфраструктуры в виде графиков или таблиц.

KVM

KVM - простой в использовании, легкий, нетребовательный к ресурсам и довольно функциональный гипервизор. Он позволяет за минимальные сроки развернуть площадку виртуализации и организовать виртуализацию под управлением операционной системы Linux. В процессе работы KMV осуществляет доступ к ядру операционной системы через специальный модуль (KVM-Intel или KVM-AMD). Изначально KVM поддерживал только процессоры x86, но современные версии KVM поддерживают самые разные процессоры и гостевые операционные системы, в том числе Linux, BSD, Solaris, Windows и др. Кстати, все Wiki-ресурсы (MediaWiki, Wikimedia Foundation, Wikipedia, Wikivoyage, Wikidata, Wikiversity) используют именно этот гипервизор.

Поскольку гостевые операционные системы взаимодействуют с гипервизором, который интегрирован в ядро Linux, у гостевых операционных систем есть возможность обращаться напрямую к оборудованию без нужды изменения гостевой операционной системы. За счет этого замедления работы гостевой операционной системы почти не происходит.

KVM позволяет виртуальным машинам использовать немодифицированные образы дисков QEMU, VMware и другие образы, содержащие операционные системы. Каждая виртуальная машина имеет своё собственное виртуальное аппаратное обеспечение: сетевые карты, диск, видеокарту и другое железо.

Благодаря поддержке немодифицированных образов VMware, физический сервер можно легко виртуализовать при помощи все той же утилиты VMware vServer Converter, а затем перенести полученный файл в гипервизор.

Установка KVM в операционной системе Linux заключается в инсталляции пакета KVM и библиотеки виртуализации Libvirt, а также в тщательной настройке среды виртуализации. В зависимости от используемой на хосте операционной системы необходимо настроить мост или подключение к VNC-консоли, с помощью которой виртуальные машины будут взаимодействовать с хостом.

Администрировать KVM сложнее, так как прозрачный доступ к файлам, процессам, консолям и сетевым интерфейсам отсутствует, это приходится настраивать самостоятельно. Перестройка параметров VM в KVM (CPU, RAM, HDD) не очень удобна и требует дополнительных действий, включающих перезагрузку ОС.

Сам проект не предлагает удобных графических инструментов для управления виртуальными машинами, только утилиту Virsh, реализующую все необходимые функции. Для удобного управления виртуальными машинами можно дополнительно установить пакет Virt-Manager.

У KVM нет встроенных инструментов, подобных Fault Tolerate для VMware, поэтому единственный способ создать кластер высокой доступности - использовать сетевую репликацию при помощи DRDB. Кластер DRBD поддерживает только два узла, а узлы синхронизируются без шифрования. То есть для более безопасной связи необходимо использовать VPN-соединение.

Кроме того, для построения кластера высокой доступности понадобится программа Heartbeat, которая позволяет обмениваться служебными сообщениями о своем состоянии узлам в кластере, и Pacemaker - менеджер ресурсов кластера.

Гипервизор KVM распространяется как продукт с открытым исходным кодом, а для корпоративных пользователей существует коммерческое решение Red Hat Virtualization (RHEL), основанное на KVM и платформе управления виртуальной инфраструктурой oVirt.

Несомненным преимуществом этого гипервизора является то, что он способен работать на любом сервере. Гипервизор довольно неприхотлив к ресурсам, что позволяет с легкостью использовать его для задач тестирования.

Следует учесть, что у KVM нет службы поддержки. Если что-то не получится, можно рассчитывать на форумы и помощь сообщества. Или перейти на RHEL.

Так что же выбрать?

Оба гипервизора являются зрелыми, надежными, высокопроизводительными системами виртуализации, у каждой из которых есть свои особенности, которые нужно учитывать при выборе.

KVM обычно более масштабируем, чем VMware, в первую очередь потому что vSphere имеет некоторые ограничения на серверы, которыми он может управлять. Кроме того, VMware добавила большое количество сетей хранения данных (SAN) для поддержки различных поставщиков. Эта функция означает, что VMware имеет больше вариантов хранения, чем KVM, но также усложняет поддержку хранилища VMware при расширении.

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

Исследования показали, что совокупная стоимость владения KVM, как правило, на 39 процентов ниже, чем у VMware, хотя фактическая совокупная стоимость владения зависит от специфичных факторов, таких как эксплуатационные параметры и рабочая нагрузка площадки.

Тесная интеграция с операционной системой на хосте является одной из наиболее распространенных причин, по которой разработчики выбирают KVM. Особенно те, кто использует Linux. Включение KVM во многие дистрибутивы Linux также делает его удобным выбором для разработчиков.

Облачные провайдеры, предлагающие своим клиентам услуги по модели IaaS, обычно выбирают инфраструктуру, построенную на продуктах VMware. Решения на основе VMware Sphere содержат все важные корпоративные функции по обеспечению высокой и непрерывной доступности, обеспечивают поддержку большего числа гостевых операционных систем и имеют возможность сопряжения инфраструктуры заказчика с облачными сервисами.