Что это kvm: Что такое виртуализация KVM | Losst

Что такое виртуализация KVM | Losst

Сегодня сложно представить мир без компьютеризированных устройств. Лет этак 20 назад почти все бытовые приборы были электро-механические, об использовании компьютерных схем повсеместно не было даже и речи. Самые первые компьютеры занимали значительные объемы пространства, и могли относительно не много. Компьютерно-вычислительные комплексы за последнее время прошли достаточно большой путь развития. Хотя, принципиально компьютеры ничем не изменились, но вычислительные мощности стремительно возросли. Наличие компьютера в простой семье теперь не является чем-то особенным.

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

Содержание статьи:

Общие сведения о виртуализации

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

Собственно видов виртуализации существует несколько:

• Программная виртуализация;
• Аппаратная виртуализация;
• Виртуализация уровня операционной системы.

Виртуализация в свою очередь бывает полной и частичной.

Программная виртуализация – вид виртуализации, который задействует различные библиотеки ОС, транслируя вызовы виртуальной машины в вызовы ОС. (DOSBox, Virtualbox, VirtualPC)

Аппаратная виртуализация – такой вид, который предусматривает специализированную инструкцию аппаратной части, а конкретно инструкций процессора. Позволяет исполнять запросы в обход гостевой ОС, и исполнять прямо на аппаратном обеспечении. (виртуализация KVM,виртуализация XEN, Parallels, VMware, Virtualbox)

Виртуализация уровня операционной системы – виртуализация только части платформы, без полной виртуализации аппаратной части. Подразумевает работы нескольких экземпляров среды ОС. (Docker, LXC)

Данная статья будет рассматривать Аппаратную виртуализацию, а конкретно виртуализацию KVM.

Схема 1. – Взаимодействие компонентов виртуальной машины с аппаратной частью

Особенности виртуализации для ядра Linux

Для исполнения прямых аппаратных запросов в ОС должна иметься библиотека, которая направляла бы эти запросы аппаратной части напрямую. На платформах базы Linux долгое время никакой встроенной системы виртуализации (встроенного гипервизора), просто не существовало. Каждый производитель ПО для виртуализации, который поддерживало технологию аппаратной виртуализации, вынуждены были создавать собственные модули для ядра Linux (vboxdrv в Virtualbox, vmware-service в VMWare и пр.) Естественно, это не могло продолжаться вечно, и компания Qumranet, Inc, выкупленая затем Radhat создала ассоциацию Open Virtualization Alliance, которая была признана решить проблему отсутствия базового гипервизора для ядра Linux. Так и был создан гипервизор KVM или Kernel-based Virtual Machine.

Гипервизор KVM представляет из себя загружаемый модуль ядра Linux, который предназначен для обеспечения виртуализации на платформе Linux x86. Сам модуль содержит компонент собственно виртуализации(kvm.ko), и процессорно-специфический загружаемый модуль kvm-amd.ko либо kvm-intel.ko.

Необходимым условием для использования KVM является поддержка инструкций виртуализации — Intel VT либо AMD , и ядро Linux версии 2.6.20 и выше. Существует также порт KVM под Free-BSD. Для вызова KVM традиционно используется QEMU, но также ведутся попытки добавить поддержку KVM в Virtualbox.

Сам по себе KVM не выполняет эмуляции. Вместо этого программа, работающая в пространстве пользователя, использует интерфейс /dev/kvm для настройки адресного пространства гостя виртуальной машины, через него же эмулирует устройства ввода-вывода и видеоадаптер.

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

Использование

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

Для наглядности рассматривается виртуализация KVM на базе библиотеку virt-manager.

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

Схема 2. – Взаимодействие компонентов libvirt

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

Существуют кроме того несколько графических оболочек, таких как Gnome-Boxes.

Выводы

Виртуализация – неотъемлемая часть современных корпоративных систем, она позволяет сэкономить колоссальные денежные и энергетические ресурсы. Развитие технологий виртуализации является приоритетным направлением многих организаций. Развиваются такие технологии как как VGAPassthrough (технология «проброса» видеокарты хост-устройства в виртуальную машину) и PCIPassthrough («проброс» PCI устройства).

Hyper-V или KVM? / Блог компании RUVDS.com / Хабр

Технология виртуализации серверов со своей более чем тридцатилетней историей сегодня стала одной из ключевых в ИТ, легла в основу облачных вычислений и сервисов нового поколения. Компании, выбирающие платформу для VPS или внедрения виртуализации в своей ИТ-инфраструктуре, наряду с продуктами VMware рассматривают в качестве альтернативы решения на основе других гипервизоров, прежде всего Microsoft Hyper-V и разработанного в рамках Open Source гипервизора KVM.

Разнообразие средств виртуализации заставляет задуматься: что именно выбрать? Это может оказаться непростой задачей. Например, сторонники Xen считают ее надежной и гибкой платформой с хорошим набором инструментов управления. Любители Hyper-V и KVM приведут весомые аргументы в пользу этих решений и перечислят их достоинства.

Можно исходить при выборе из таких параметров как производительность, стоимость, открытость, эффективность, управляемость, поддержка платформ… Однако эксперты советуют выбирать решение виртуализации, прежде всего, руководствуясь требованиями бизнеса. Развертываемое в корпоративной среде, оно должно подходить для обширного стека сертифицированных бизнес-приложений (ERP, MRP, HR, CRM и др.), а разработчик, если это коммерческий продукт, должен иметь четкие планы развития продукта по разным направлениям (аварийное восстановление, резервное копирование, SDN и др.). Наконец, хорошее программное обеспечение виртуализации обладает достаточной масштабируемостью и гибкостью.

Например, производительность KVM при увеличении нагрузки уменьшается быстрее, чем у Xen (если верить результатам тестирования). Xen отличает масштабируемость – способность поддерживать большое число одновременно работающих ВМ. Считается, что Xen превосходит KVM по возможностям резервного копирования и управления хранением данных.

Подобная дилемма возникает и при анализе предложений по аренде виртуальных серверов (VDS/VPS). Хостеры предлагают разнообразные средства виртуализации, включая Xen, KVM, Microsoft Hyper-V, OpenVZ, Virtuozzo, VDSmanager и др. (VMware – очень редко ввиду высокой стоимости), при этом провайдер всегда готов рассказать о достоинствах используемой системы, но продукты виртуализации редко сравнивают и столь же редко упоминают об их недостатках.

Попробуем отчасти восполнить этот пробел. В частности — сопоставить два популярных гипервизора виртуализации – Microsoft Hyper-V для серверных ОС семейства Windows и KVM для Linuх. Однако сразу стоит оговориться, что идеальной системы виртуализации для VPS нет, каждая подходит для своих задач. Например, многие из тех, кто использует платформу KVM, применяют и виртуальные машины (ВМ) на базе Linux.

Нужен VPS c Linux или FreeBSD? Можно выбрать KVM. VPS на KVM с Windows – тоже вариант, но для данной ОС предпочтительнее Microsoft Hyper-V. Последний считается лучшим решением для виртуализации серверов с ОС Windows, и активно используется хостинг-провайдерами.

Xen и KVM – продукты с открытым исходным кодом, причем очень близкие по функциям и производительности, но если в версии Сitrix XenServer первый постепенно превращается в облачную платформу, то развитие KVM идет в ногу с эволюцией дистрибутивов, таких как RHEV от Red Hat. Hyper-V — коммерческое ПО от Microsoft. Не удивительно, что Hyper-V отлично работает в инфраструктуре Windows. Все они позволяют виртуализировать серверные платформы x86-64 и представляют собой системы аппаратной виртуализации для VPS хостинга и не только.

Hyper-V, KVM, ESXi – гипервизоры первого типа (Type-I). Они работают непосредственно на физическом оборудовании, к которому операционная система получает доступ через гипервизор. Гипервизоры второго типа (Type-II), например, VMware Workstation, Oracle Virtual Box, OpenVZ функционируют поверх операционной системы, поэтому ВМ и гипервизор взаимодействует с оборудованием через ОС. Считается, что производительность гипервизоров второго типа ниже, чем первого, поскольку зависит также от ОС хоста.

Использование Hyper-V и KVM в разных отраслях, % респондентов (данные IT Central Station).

Использование Hyper-V и KVM в компаниях с разной численностью сотрудников, % респондентов (данные IT Central Station).

Эти два гипервизора сравнивают не только друг с другом. KVM иногда сопоставляют с VMware ESXi и IBM PowerVM, а Microsoft Hyper-V нередко — с Oracle VM VirtualBox, изредка — с Proxmox VE.
Альтернативы Hyper-V и KVM (в версии Open Source), по мнению отраслевой прессы (в порядке убывания; рейтинг составлен IT Central Station, 2016 год).

Microsoft Hyper-V

Продукт Microsoft существует в двух ипостасях: как автономный Hyper-V Server (в последней версии — Hyper-V Server 2012 R2) или как один из компонентов Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 или 64-разрядной версии Window 8/10 Pro. В любом случае он используется для создания на сервере виртуальной среды, предоставляя для этого соответствующие сервисы и инструменты.

Можно также виртуализировать рабочие места, развернув инфраструктуру VDI, или создать удобную среду для разработки и тестирования ПО. Экономичная и стабильная среда виртуализации Hyper-V позволяет одновременно запускать на хосте несколько операционных систем, включая Windows, Linux и другие. На текущий момент Hyper-V используют компании и организации практически любых отраслей, в их числе крупнейшие заказчики. Что это дает? Например, Hyper-V может служить основой для развертывания частного облака, позволяет оптимизировать использование аппаратных ресурсов, консолидировать серверы, запустив на одной физической системе несколько виртуальных машин, обеспечить отказоустойчивость для непрерывности бизнес-процессов. Впрочем, это свойственно не только данному гипервизору.

В «магическом квадранте» Gartner по виртуализации серверной инфраструктуры х86 (Magic Quadrant for x86 Server Virtualization Infrastructure), выпущенном в июле 2015 года, лидируют Micrоsoft и VMware. Xen и KVM представлены вендорами Citrix и Red Hat.

За что же именно ценят Hyper-V? Системные администраторы и ИТ-менеджеры называют такие качества как высокая стабильность работы Hyper-V и Windows, поддержка «живой миграции» ВМ (Live Migration) и кластеризации (для построения конфигураций высокой доступности), масштабируемость, возможность присваивания сетевых карт (NIC) виртуальным машинам, что позволяет избежать узких мест, подчас возникающих, когда виртуальному коммутатору назначен один физический сетевой адаптер.

Live Migration позволяет перемещать ВМ между физическими серверами Hyper-V, в том числе и автоматически, без участия пользователя.

Упоминают также возможность централизованного управления серверами — несколькими хостами Hyper-V, причем без дополнительной покупки лицензий, как в случае VMware vCenter. Относительно просто (хотя и более запутанно, чем в VMware) выполняется миграция физического сервера в виртуальный (P2V). Для этого создается образ VHD физической системы и присваивается новой ВМ. Удобный режим Enhanced Session Mode позволяет выполнять копирование/вставку внутри ВМ.

Hyper-V прост в использовании и управлении – хорошая альтернатива продукту VMware в сегменте SMB. Он включен и в Windows 10, причем это почти полнофункциональная версия. Сам гипервизор ничего не стоит, его можно скачать с сайта Microsoft (в виде Hyper-V Server), хорошо подходит для виртуализации ОС от Microsoft, его легко установить и настроить, а большинство системных администраторов умеют с ним работать. Hуper-V можно установить на любой поддерживающий Windows сервер. Еще в копилку плюсов: большинство продуктов Microsoft могут работать в виртуальной среде Hyper-V.

К негативным качествам относят ограниченные возможности настройки работы с СХД (например, сложности настройки iSCSI target в Windows Server 2012 R2. Более надежным и дружественным мог бы быть импорт/экспорт, создание шаблонов.

В Hyper-V достаточно сложно конфигурировать некоторые вещи, например, High Availability (HA), где требуется формирования кластера (Failover Clustering). В vSphere, например, это делается проще и естественнее. А миграция ВМ в Hyper-V, в отличие от vMotion, возможна только между серверами с процессорами одного семейства. Нет в Hyper-V и ничего похожего на Distributed Resource Scheduler (DRS) или Storage DRS, которые в среде виртуализации VMware можно использовать для балансирования нагрузок между ресурсами нескольких хостов с помощью vMotion и Storage vMotion.

Зато SCVMM (System Center Virtual Machine Manager 2012) в Hyper-V открывает возможности, выходящие за рамки собственно серверной виртуализации. Например, можно создать частное облако с функциями самообслуживания. В VMware есть vCloud Director, но это отдельное решение за отдельные деньги. У Microsoft SCVMM – бесплатное приложение к System Center 2012. Кроме того, SCVMM позволяет использовать в качестве платформ виртуализации хосты с Hyper-V, vSphere и гипервизором Citrix, в то время как vCenter поддерживает только управление хостами VMware.

Также можно упомянуть, что Debian и основанные на нем дистрибутивы способны отлично работать под Hyper-V и могут применяться для реализации инфраструктурных элементов работающих с большой нагрузкой. Также недавно компания Microsoft выпустила обновление Linux Integration Services 4.0 for Hyper-V, представляющее собой пакет драйверов, утилит и улучшений для гостевых ОС Linux, работающих в виртуальных машинах на платформах Hyper-V и Azure.

Особенности Microsoft Hyper-V в Windows Server 2012 R2 Datacenter Edition

KVM

А теперь пара слов о KVM. Хотя в деле построения виртуализированных инфраструктур для крупного бизнеса платформы от Microsoft и VMware по-прежнему являются несомненными лидерами, в последние отмечается рост интереса и к KVM.

KVM (Kernel-based Virtual Machine) – полное решение виртуализации для платформ Linux/x86, поддерживающее аппаратные расширения (Intel VT и AMD-V). В его составе – загружаемый модуль ядра kvm.ko, обеспечивающий базовую инфраструктуру виртуализации, и модуль для конкретного процессора — kvm-intel.ko или kvm-amd.ko.

Первоначально KVM поддерживал только процессоры x86, но в настоящее время к ним добавился широкий спектр процессоров и гостевых операционных систем, в том числе множество вариаций Linux, BSD, Solaris, Windows, Haiku, ReactOS и AROS Research Operating System.

В числе пользователей KVM – известные Wiki-ресурсы: MediaWiki, Wikimedia Foundation, Wikipedia, Wikivoyage, Wikidata, Wikiversity.

В 2015 году «Лаборатория Касперского» совместно с B2B International провела исследование, в ходе которого представителям компаний, использующих технологию виртуализации задавались вопросы про применяемые у них платформы. Выяснилось, что 15% компаний используют различные варианты коммерческих платформ на базе KVM, и еще 16% планируют их внедрять в течение ближайшей пары лет. Бесплатные версии  продукта используются в 8% крупных организаций и еще в 16% опрошенных компаний будут внедрены в будущем.

Исследование «Лаборатории Касперского» показало, что если основными гипервизорами, чаще всего, являются VMware vSphere и Microsoft Hyper-V, то в качестве дополнительного предпочитают использовать решения с открытым кодом или коммерческие решения на базе Open Source. Особенно часто — KVM.

В «Лаборатории Касперского» считают, что причин популярности KVM несколько. Во-первых, в некоторых сценариях, внедрение платформы виртуализации на базе KVM (даже коммерческой ее версии) обходится значительно дешевле, чем использование Microsoft Hyper-V и VMware vSphere. Во-вторых, в мире растет количество виртуализированных Linux-серверов. Их владельцам привычнее и удобнее применять и гипервизор на базе Linux. В большинстве случаев, это именно KVM. Кроме того, Linux-сообщество вносит вклад в развитие платформы, развивается экосистема решений, которые поддерживающих KVM.

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

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

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

Раз уж речь зашла об управлении, стоит упомянуть один из популярных вариантов управления VPS в случае KVM – SolusVM. Это универсальная панель управления виртуальными серверами Xen, KVM и OpenVZ.

Некоторые пользователи отмечают недостаточную стабильность KVM при выполнении задач с интенсивным вводом-выводам. Бытует мнение, что KVM – не вполне зрелый продукт для рабочих сред и больше подходит для экспериментов и в случаях, когда требуется модификация исходного кода. Hyper-V более стабилен, средства миграции ВМ в нем надежнее, эффективнее используется оборудование, чем в Linux-KVM.

Подготовка KVM к работе и настройка десятков параметров – процесс на любителя, хотя есть и интерфейс управления Virsh (и GUI-интерфейс virtmanager), позволяющий запускать гостевые системы в KVM, используя простой файл конфигурации. Для управления гипервизором KVM удобно также использовать инструменты OpenStack. Это помогает, в частности, внедрять облачные сервисы.

Службы поддержки как таковой нет, только сообщество. Но те, кому она необходима, могут выбрать коммерческий вариант — RHEV (Red Hat Enterprise Virtualization).

Заключение

Возможно, эта информация поможет вам сделать правильный выбор, однако, как уже отмечалось выше, очень многое зависит от решаемой задачи и многих других условий. А спектр таких задач сегодня чрезвычайно широк – от виртуального хостинга до построения программно-определяемых дата-центров (SDDC) и внедрения гибридных облаков. Например, среда виртуализации в ЦОД должна обеспечивать сочетание нескольких важных характеристик: зрелость, простота развертывания, управляемость и автоматизация, поддержка и сопровождение, производительность, масштабируемость, надежность, высокая готовность и работоспособность, безопасность.

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

Общие принципы работы QEMU-KVM / Хабр

Мое текущее понимание:

1) KVM

KVM (Kernel-based Virtual Machine) – гипервизор (VMM – Virtual Machine Manager), работающий в виде модуля на ОС Linux. Гипервизор нужен для того, чтобы запускать некий софт в несуществующей (виртуальной) среде и при этом, скрывать от этого софта реальное физическое железо, на котором этот софт работает. Гипервизор работает в роли «прокладки» между физическим железом (хостом) и виртуальной ОС (гостем).

Поскольку KVM является стандартным модулем ядра Linux, он получает от ядра все положенные ништяки (работа с памятью, планировщик и пр.). А соответственно, в конечном итоге, все эти преимущества достаются и гостям (т.к. гости работают на гипервизоре, которые работает на/в ядре ОС Linux).

KVM очень быстрый, но его самого по себе недостаточно для запуска виртуальной ОС, т.к. для этого нужна эмуляция I/O. Для I/O (процессор, диски, сеть, видео, PCI, USB, серийные порты и т.д.) KVM использует QEMU.

2) QEMU

QEMU (Quick Emulator) – эмулятор различных устройств, который позволяет запускать операционные системы, предназначенные под одну архитектуру, на другой (например, ARM –> x86). Кроме процессора, QEMU эмулирует различные периферийные устройства: сетевые карты, HDD, видео карты, PCI, USB и пр.

Работает это так:

Инструкции/бинарный код (например, ARM) конвертируются в промежуточный платформонезависимый код при помощи конвертера TCG (Tiny Code Generator) и затем этот платформонезависимый бинарный код конвертируется уже в целевые инструкции/код (например, x86).

ARM –> промежуточный_код –> x86

По сути, вы можете запускать виртуальные машины на QEMU на любом хосте, даже со старыми моделями процессоров, не поддерживающими Intel VT-x (Intel Virtualization Technology) / AMD SVM (AMD Secure Virtual Machine). Однако в таком случае, это будет работать весьма медленно, в связи с тем, что исполняемый бинарный код нужно перекомпилировать на лету два раза, при помощи TCG (TCG – это Just-in-Time compiler).

Т.е. сам по себе QEMU мега крутой, но работает очень медленно.

3) Protection rings

Бинарный программный код на процессорах работает не просто так, а располагается на разных уровнях (кольцах / Protection rings) с разными уровнями доступа к данным, от самого привилегированного (Ring 0), до самого ограниченного, зарегулированного и «с закрученными гайками» (Ring 3).

Операционная система (ядро ОС) работает на Ring 0 (kernel mode) и может делать с любыми данными и устройствами все, что угодно. Пользовательские приложения работают на уровне Ring 3 (user mode) и не в праве делать все, что захотят, а вместо этого каждый раз должны запрашивать доступ на проведение той или иной операции (таким образом, пользовательские приложения имеют доступ только к собственным данным и не могут «влезть» в «чужую песочницу»). Ring 1 и 2 предназначены для использования драйверами.

До изобретения Intel VT-x / AMD SVM, гипервизоры работали на Ring 0, а гости работали на Ring 1. Поскольку у Ring 1 недостаточно прав для нормального функционирования ОС, то при каждом привилегированном вызове от гостевой системы, гипервизору приходилось на лету модифицировать этот вызов и выполнять его на Ring 0 (примерно так, как это делает QEMU). Т.е. гостевой бинарный код НЕ выполнялся напрямую на процессоре, а каждый раз на лету проходил несколько промежуточных модификаций.

Накладные расходы были существенными и это было большой проблемой и тогда производители процессоров, независимо друг от друга, выпустили расширенный набор инструкций (Intel VT-x / AMD SVM), позволяющих выполнять код гостевых ОС НАПРЯМУЮ на процессоре хоста (минуя всякие затратные промежуточные этапы, как это было раньше).

С появлением Intel VT-x / AMD SVM, был создан специальный новый уровень Ring -1 (минус один). И теперь на нем работает гипервизор, а гости работают на Ring 0 и получают привилегированный доступ к CPU.

Т.е. в итоге:

• хост работает на Ring 0
• гости работают на Ring 0
• гипервизор работает на Ring -1

4) QEMU-KVM

KVM предоставляет доступ гостям к Ring 0 и использует QEMU для эмуляции I/O (процессор, диски, сеть, видео, PCI, USB, серийные порты и т.д., которые «видят» и с которыми работают гости).

Отсюда QEMU-KVM (или KVM-QEMU) 🙂

CREDITS
Картинка для привлечения внимания
Картинка Protection rings

P.S. Текст этой статьи изначально был опубликован в Telegram канале @RU_Voip в качестве ответа на вопрос одного из участников канала.

Напишите в комментариях, в каких местах я не правильно понимаю тему или если есть, что дополнить.

Спасибо!

Работа с виртуальными машинами KVM. Введение / Хабр

Как и обещал, начинаю серию статей о том, как мы делали услугу аренды выделенных серверов на базе KVM.

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

Debian

Почему Debian? Эта операционная система мне близка и понятна, так что при выборе дистрибутива мучений, терзаний и метаний испытано не было. Особых преимуществ перед Red Hat Enterprise Linux у него нет, но было принято решение работать со знакомой системой.

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

Мы же, повторюсь, решили использовать Debian Squeeze с набором пакетов из Sid/Experimental и некоторыми пакетами, бэкпортированными и собранными с нашими патчами.

В планах имеется публикация репозитория с пакетами.

KVM

При выборе технологии виртуализации рассматривались два варианта — Xen и KVM.

Замечу, что лично я не очень хорошо знаю Xen, его архитектуру и уж тем более мелкие особенности — в основном я знакомился с ним в качестве гостя. Нет повода сказать, что Xen чем-то плох (потому, что он ещё не полностью вошёл в ядро, или у него что-то не так с производительностью, или еще по какой-то причине). Ничего определённого нельзя сказать и в плане производительности: в каких-то тестах KVM на 10-20 процентов опережает Xen по всем показателям, а где-то выигрывает Xen. Фактически, на текущий момент они практически сравнялись по функционалу, производительности, надёжности. И в принципе, не за горами тот день, когда Xen также войдёт в ядро. Уже вошёл в состав ядра virtually-a-machine.blogspot.com/2011/06/xen-support-in-mainline-linux-kernel.html.

Также во внимание принимался факт наличия огромного количества разработчиков, хостеров, комерческих решений именно на базе Xen — тем интереснее было провести в жизнь решение именно на базе KVM.

Основной же причиной, по которой мы решили использовать именно KVM, является необходимость запуска виртуальных машин с FreeBSD и, в перспективе, MS Windows.

libvirt

Для управления виртуальными машинами оказалось чрезвычайно удобно использовать libvirt и продукты, использующие ее API: virsh, virt-manager, virt-install, пр.

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

Разумеется, решение не идеально. Из минусов libvirt следует назвать:

• Абсолютно невменяемые сообщения об ошибках.
• Невозможность изменять часть конфигурации виртуальной машины на лету, хотя QMP (QEMU Monitor Protocol) это вполне позволяет.
• Иногда к libvirtd по непонятной причине невозможно подключиться — он перестаёт реагировать на внешние события.

cgroups

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

В KVM ничего такого не было до появления механизма распределения ресурсов ядра cgroups. Как обычно в Linux, доступ к этим функциям был реализован посредством специальной файловой системы cgroup, в которой при помощи обычных системных вызовов write() можно было добавить процесс в группу, назначить ему его вес в попугаях, указать ядро, на котором он будет работать, указать пропускную способность диска, которую этот процесс может использовать, или, опять же, назначить ему вес.

Профит в том, что всё это реализуется внутри ядра, и использовать это можно не только для сервера, но и для десктопа (что и использовали в известном «The ~200 Line Linux Kernel Patch That Does Wonders»). И на мой взгляд, это одно из самых значительных изменений в ветке 2.6, не считая любимого #12309, а не запиливание очередной файловой системы. Ну, разве что, кроме POHMELFS (но чисто из-за названия).

libguestfs

Отношение к этой библиотеке-утилите у меня весьма неоднозначное.

С одной стороны это выглядит примерно так:

И ещё эту штуку чертовски сложно собрать из исходников и тем более в пакет: иногда мне кажется, что Linux From Scratch собрать с нуля несколько проще.

С другой стороны — очень мощная штука, которая позволяет создавать образы для виртуальных машин, модифицировать их, ужимать, ставить grub, модифицировать таблицу разделов, управлять конфигурационными файлами, переносить «железные» машины в виртуальную среду, переносить виртуальные машины с одного образа на другой, переносить виртуальные машины из образа на железо и, честно говоря, тут меня фантазия немного подводит. Ах, да: ещё можно запустить демон внутри виртуальной машины Linux и получить доступ к данным виртуальной машины вживую, и всё это делать на shell, python, perl, java, ocaml. Это краткий и далеко не полный список того, что можно сделать с libguestfs.

Интересно, что большая часть кода в libguestfs генерируется в момент сборки, равно как и документация к проекту. Очень широко используется ocaml, perl. Сам код пишется на C, который потом оборачивается в OCaml, и повторяющиеся куски кода генерируются сами. Работа с образами осуществляется путём запуска специального сервисного образа (supermin appliance), в который через канал внутрь него отправляются команды. Внутри этого образа содержится некоторый rescue набор утилит, таких как parted, mkfs и прочих полезных в хозяйстве системного администратора.

Я с недавнего времени его даже дома стал использовать, когда выковыривал из образа nandroid нужные мне данные. Но для этого требуется ядро с поддержкой yaffs.

Прочее

Ниже приведено ещё несколько интересных ссылок на описание использованных пограммных средств — почитать и поизучать самостоятельно, если интересно. Например, про утилиту для массовой работы с конфигурационными файлами, KVM best practices от товарищей из IBM. Рекомендую!

1. Пост Daniel Berrange об использовании cgroups с KVM и LXC.
2. Пост Richard Jones об использовании libguestfs для получения маленького размера «базового» образа виртуальной машины.
3. BKL #12309 на bugzilla.kernel.org

В следующей части

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

Использование виртуализации на основе KVM

Как приступить к использованию виртуализации на основе KVM – последнего поколения Linux-технологий виртуализации

Вильям фон Хаген
Опубликовано 04.08.2014

Возможность исполнения нескольких виртуальных машин на аппаратных средствах одного сервера позволяет улучшить такие показатели сегодняшней ИТ-инфраструктуры, как расходы, системное управление и гибкость. Хостинг нескольких виртуальных машин на одной аппаратной платформе уменьшает затраты на аппаратные средства и помогает свести к минимуму инфраструктурные издержки, например, энергозатраты на питание и охлаждение. Консолидация операционно различающихся систем на одной аппаратной платформе в виде виртуальных машин упрощает управление этими системами благодаря специальным слоям администрирования, таким как продукт с открытым исходным кодом libvirt (virtualization library) и инструменты на его основе, в том числе графические, такие как Virtual Machine Manager (VMM). Кроме того, виртуализация обеспечивает операционную гибкость, которая требуется для сегодняшних сервис-ориентированных ИТ-служб высокой степени готовности. Она позволяет осуществлять миграцию исполняющихся виртуальных машин между физическими хостами, когда возникают проблемы с аппаратными средствами или с физической инфраструктурой либо необходимо достичь максимальной производительности посредством выравнивания нагрузки или удовлетворения возросших потребностей в процессорных ресурсах и ресурсах памяти.

Приложения с открытым исходным кодом для виртуализации настольных систем, такие как VirtualBox, позволяют пользователям и даже некоторым небольшим корпоративным системам (компании малого — среднего размера или предприятия малого — среднего размера) исполнять на каждой физической системе по несколько виртуальных машин. Однако среды виртуализации, подобные VirtualBox, исполняются на настольном компьютере или на сервере как клиентские приложения. Корпоративные ИТ-инфраструктуры требуют более высокопроизводительных, ориентированных на серверы сред виртуализации, более приближенных к физическим аппаратным средствам (к «железу»), что позволяет исполнять виртуальные машины с гораздо меньшими накладными расходами для операционной системы. Механизмы виртуализации «на железе» способны лучше управлять аппаратными ресурсами, а также наилучшим образом использовать поддержку аппаратных средств виртуализации, которые встроены в большинство 64-разрядных процессоров с архитектурой x86 и PowerPC.

Механизмы виртуализации «на железе» используют небольшую операционную систему (т. н. гипервизор) для управления виртуальными машинами и связанными с ними ресурсами (в т. ч. для диспетчеризации). Гипервизоры «на железе» известны как гипервизоры первого типа (Type 1) (ссылка на дополнительную информацию по гипервизорам приведена в разделе
Ресурсы). Две самые популярные технологии с открытым исходным кодом для виртуализации «на железе» — это KVM (Kernel Virtual Machine) и Xen. Каждая из этих технологий — и Xen, и KVM — имеет свои преимущества и своих приверженцев, однако популярность и изощренность KVM непрерывно росли, вследствие чего на сегодняшний день технология KVM рекомендована для использования с большинством дистрибутивов Linux® в качестве механизма виртуализации по умолчанию.

Сравнение технологий KVM и Xen

Среда виртуализации Xen (ссылка приведена в разделе Ресурсы) традиционно была самой высокопроизводительной технологией виртуализации с открытым исходным кодом на Linux-системах. Xen использует гипервизор для управления виртуальными машинами и связанными ресурсами, а также поддерживает т. н. паравиртуализацию, которая способна обеспечить более высокую производительность в виртуальных машинах, «знающих» о том, что они виртуализированы. Технология Xen предоставляет гипервизор с открытым исходным кодом, который осуществляет управление ресурсами и их диспетчеризацию. При загрузке на физических аппаратных средствах без ОС (на «голом железе») гипервизор Xen запускает главную виртуальную машину (Domain0 или домен управления), которая предоставляет возможности для централизованного управления всеми остальными виртуальными машинами (Domain1 — DomainN или машины типа Xen guest), размещенными на этом физическом хосте.

В отличие от Xen-виртуализации, KVM-виртуализация использует в качестве гипервизора ядро Linux. Поддержка KVM-виртуализации является компонентом по умолчанию для основного ядра Linux начиная с выпуска 2.6.20. Использование Linux-ядра в качестве гипервизора — это существенная мишень для критиков KVM, поскольку (по умолчанию) Linux-ядро не соответствует традиционному определению гипервизора типа 1 — «небольшая операционная система». Это верно для ядер по умолчанию, поставляемых с большинством дистрибутивов Linux, однако Linux-ядро легко можно сконфигурировать для уменьшения его размера после компиляции — в этом случае оно будет поддерживать лишь возможности и драйверы, необходимые для функционирования этого ядра в качестве гипервизора первого типа. Собственное предложение компании Red Hat под названием Enterprise Virtualization полагается именно на такое, специальным образом сконфигурированное, относительно компактное Linux-ядро. Однако, что более важно, «небольшой размер» — это относительное понятие; современные 64-разрядные серверы, укомплектованные несколькими гигабайтами памяти, способны безболезненно предоставить несколько мегабайтов, которые требуются современному Linux-ядру.

Существует несколько причин, обуславливающих преимущество KVM перед Xen в качестве предпочтительной технологии виртуализации «на железе» с открытым исходным кодом для большинства корпоративных сред.

• Поддержка KVM автоматически присутствует в каждом Linux-ядре начиная с версии 2.6.20. До выпуска ядра Linux версии 3.0 интеграция поддержки Xen в ядро Linux требовала установки значительных патчей, однако и они не гарантировали, что каждый драйвер для каждого возможного аппаратного устройства будет корректно работать в среде Xen.
• Патчи исходного кода ядра, необходимые для поддержки Xen, предоставлялись лишь для определенных версий ядра. Это не позволяло средам Xen-виртуализации использовать новые драйверы, подсистемы, а также исправления и улучшения ядра, доступные только в других версиях ядра. Интеграция KVM в Linux-ядро позволила KVM-виртуализации автоматически использовать любые улучшения в новых версиях Linux-ядра.
• Технология Xen требует, чтобы специально сконфигурированное Linux-ядро исполнялось на физическом сервере виртуальной машины в качестве административного домена для всех виртуальных машин Xen, которые работают на этом сервере. KVM может использовать то же самое Linux-ядро на физическом сервере, которое используется в виртуальных Linux- машинах, исполняющихся на этой физической системе.
• Гипервизор Xen представляет собой отдельный автономный элемент исходного кода со своими потенциальными дефектами, которые независимы от дефектов операционной системы, хостинг которой осуществляет этот гипервизор. KVM — это неотъемлемая часть Linux-ядра, поэтому на использование KVM в качестве гипервизора способны влиять только дефекты этого ядра.

Хотя технология Xen по-прежнему может предложить виртуализацию «на железе» с более высокой производительностью, чем KVM, ценность этого повышения производительности зачастую перевешивается простотой и легкостью использования KVM-виртуализации.

Поскольку Xen — более зрелая технология виртуализации «на железе», чем KVM, она предоставляет собственный набор специализированных административных команд, наиболее примечательным из которых является пакет утилит командной строки xm. Как и в случае любого другого набора административных команд для определенной технологии, инструменты xm требуют специального обучения и известны далеко не всем системным администраторам Linux. Технология KVM унаследовала большую часть своей исходной административной инфраструктуры от QEMU (хорошо проработанного Linux-пакета для эмуляции и виртуализации), который имеет аналогичные требования к обучению и к наличию специализированных знаний.

Для любой уникальной технологии вполне естественно иметь собственный набор команд, однако увеличение количества технологий виртуализации побудило поставщиков Linux приступить к поиску единого административного интерфейса для управления всеми этими технологиями. Компания Red Hat не случайно имеет годовой доход более миллиарда долларов и занимает первое место среди поставщиков продукции с открытым исходным кодом. Именно она возглавила деятельность по разработке API-интерфейса виртуализации libvirt для поддержки последующего создания инструментов, позволяющих осуществлять управление и администрирование для нескольких технологий виртуализации. API-интерфейс libvirt поддерживает такие технологии виртуализации, как KVM, Xen, LXC (Linux Containers), OpenVZ, User-mode Linux, VirtualBox, Microsoft® Hyper-V®, а также множество технологий VMware.

Вместо того чтобы делать ставку на единственную технологию и связанный с ней набор команд, применение libvirt позволяет системным администраторам изучить единый набор команд командной строки и графических команд, которые зависят от этого API-интерфейса, а затем постоянно использовать эти инструменты безотносительно к изменениям в базовых технологиях виртуализации. Поставщики инструментов виртуализации благодаря непосредственному применению API-интерфейса libvirt получают аналогичные преимущества.

В нескольких следующих разделах описаны распространенные подходы, упрощающие типовые задачи администрирования для сред виртуализации на основе KVM при использовании инструментов на базе libvirt. В этих разделах основное внимание уделяется примерам с использованием утилит командной строки virsh
и virt-install, хотя все эти задачи также можно выполнить с помощью графического инструмента VMM
(virt-manager), основанного на libvirt. Все эти команды должны исполняться от имени пользователя root (или после ввода команды sudo).

Примеры в остальной части этой статьи предполагают, что в своем дистрибутиве Linux вы установили соответствующие пакеты для поддержки KVM-виртуализации и получения необходимых инструментов. В зависимости от используемой вами Linux-платформы требуются разные пакеты. К примеру, на системах RHEL (Red Hat Enterprise Linux) и на клонах RHEL необходимо установить следующие группы пакетов: Virtualization, Virtualization Client, Virtualization Platform и Virtualization Tools.

Использование пулов хранилищ

В статье на сайте developerWorks, посвященной созданию простой виртуальной машины на основе KVM (см. раздел Ресурсы),
объясняется, как установить виртуальную машину с использованием образа диска, который вы создаете в локальном дисковом хранилище сервера, осуществляющего хостинг этой виртуальной машины. Обычным способом для начального экспериментирования с виртуальными машинами является создание в ручном режиме каждого локального файла, который входит в состав образа диска. Однако этот способ быстро становится слишком трудоемким, слишком утомительным и слишком сложным в управлении

API-интерфейс libvirt обеспечивает удобную абстракцию для размещения образов виртуальной машины и файловых систем, которая носит название storage pools (пул хранилищ).
Пул хранилищ – это локальный каталог, локальное устройство хранения данных (физический диск, логический том или хранилище на основе хост-адаптера шины SCSI [SCSI HBA]), файловая система NFS (network file system), либо сетевое хранилище блочного уровня, управляемое посредством libvirt
и позволяющее создать и хранить один или более образов виртуальных машин. Локальное хранилище — это простое решение, которое, однако, может оказаться негибким и не поддерживает самое важное требование корпоративной виртуализации: способность перемещать виртуальные машины между серверами без остановки исполняющихся виртуальных машин (live
migration). Чтобы облегчить применение опции live migration, дисковый образ виртуальной машины должен находиться в NFS, в сетевом хранилище блочного уровня или в HBA-хранилище, доступном для нескольких хостов виртуальных машин.

В следующем примере используется команда virsh (входит в пакет команд на базе libvirt), которая предоставляет отдельные подкоманды для создания всех объектов, которые использует интерфейс
libvirt— виртуальных машин (доменов), томов, пулов хранилищ, сетей, сетевых интерфейсов, устройств и т. д., а также для управления всеми этими объектами.

По умолчанию команды на базе libvirt используют в качестве исходного пула хранилищ для каталога файловой системы каталог /var/lib/libvirt/images на хосте виртуализации. Новый пул хранилищ можно с легкостью создать с помощью команды
virsh pool-create-as. Например, следующая команда демонстрирует обязательные аргументы, которые вы должны указать при создании пула хранилищ на основе NFS (netfs):

virsh pool-create-as NFS-POOL netfs \
--source-host 192.168.6.238 \
--source-path /DATA/POOL \
--target /var/lib/libvirt/images/NFS-POOL

Первый аргумент (NFS-POOL) идентифицирует имя нового пула хранилищ, а второй аргумент идентифицирует тип пула хранилищ, который вы создаете. Аргумент опции --source-host
идентифицирует хост, который экспортирует каталог пула хранилищ посредством NFS. Аргумент опции --source-path определяет имя экспортируемого каталога на этом хосте. Аргумент опции
--target идентифицирует локальную точку монтирования, которая будет использоваться для обращения к пулу хранилищ.

После создания нового пула хранилищ он будет указан в выходной информации команды
virsh pool-list. В следующем примере показаны пул хранилищ по умолчанию и пул NFS-POOL, созданный в предыдущем примере.

virsh pool-list --all --details
Name        State    Autostart  Persistent   Capacity  Allocation  Available
----------------------------------------------------------------------------
default     running  yes        yes          54.89 GB    47.38 GB    7.51 GB
NFS-POOL    running  no         no          915.42 GB   522.64 GB  392.78 GB

В выходной информации этого примера обратите внимание, что опция Autostart (автозапуск) для нового пула хранилищ имеет значение no (нет), т. е. после перезапуска системы этот пул не будет автоматически доступен для использования, и что опция Persistent (персистентность) также имеет значение no, т. е. после перезапуска системы этот пул вообще не будет определен. Пул хранилищ является персистентным только в том случае, если он сопровождается XML-описанием пула хранилищ, которое находится в каталоге /etc/libvirt/storage. XML-файл описания пула хранилищ (файл с расширением xml) имеет такое же имя, как у пула хранилищ, с которым он ассоциирован.

Чтобы создать файл XML-описания для сформированного в ручном режиме пула хранилищ, воспользуйтесь командой
virsh pool-dumpxml указав в качестве ее заключительного аргумента имя пула, для которого вы хотите получить XML-описание. Эта команда осуществляет запись в стандартное устройство вывода, поэтому вам необходимо перенаправить ее выходную информацию в соответствующий файл. Например, следующие команды создадут надлежащий файл XML-описания для созданного ранее пула хранилищ NFS-POOL.

cd /etc/libvirt/storage
virsh pool-dumpxml NFS-POOL > NFS-POOL.xml

Даже после активации опции Persistent у пула хранилищ он не будет помечен для автоматического запуска при перезапуске хоста виртуализации. Чтобы задать для пула хранилищ опцию Autostart (автоматический запуск), можно воспользоваться командой virsh pool-autostart, сопровождаемой именем соответствующего пула хранилищ (см. следующий пример).

virsh pool-autostart NFS-POOL
Pool NFS-POOL marked as autostarted

Маркировка пула хранилищ как Autostart говорит о том, что этот пул хранилищ будет доступен после любого перезапуска хоста виртуализации. С технической точки зрения это означает, что каталог /etc/libvirt/storage/autostart будет содержать символьную ссылку на XML-описание этого пула хранилищ.

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

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

В следующем примере задействован пул хранилищ, который вы создали в предыдущем разделе, однако используется команда virt-install. Это команда на базе
libvirt, помогающая создавать виртуальные машины из командной строки.

В этом примере команда virt-install создает аппаратную виртуальную машину с именем RHEL-6.3-LAMP, на которой (как и следует из ее имени) исполняется выпуск RHEL 6.3 и которая используется в качестве стандартного веб-сервера для Linux-среды. По умолчанию при создании новых томов дискового пула используется имя вашей виртуальной машины, поэтому вам следует соблюдать осмотрительность при выборе этого имени. Имена виртуальных машин обычно соответствуют локальному соглашению о назначении имен. Их следует формировать таким образом, чтобы администраторам было проще идентифицировать тип и назначение каждой виртуальной машины.

virt-install --name RHEL-6.3-LAMP \
--os-type=linux \
--os-variant=rhel6 \
--cdrom /mnt/ISO/rhel63-server-x86_64.iso \
--graphics vnc\
--disk pool=NFS-01,format=raw,size=20 \
--ram 2048 \
--vcpus=2 \
--network bridge=br0 \
--hvm \
--virt-type=kvm \

Другие опции команды virt-install указывают, что данная виртуальная машина будет оптимизирована для дистрибутивов Linux и RHEL6 Linux (--ostype
и --osvariantсоответственно) и будет установлена с использованием ISO-образа /mnt/ISO/rhel63-server-x86_64.iso в качестве виртуального устройства CD-ROM (--cdrom). При загрузке с виртуального дисковода для компакт-дисков команда virt-install создает и пытается отобразить с использованием протокола VNC (Virtual Network Computing) графическую консоль (--graphics), в которой выполняется начальная загрузка и последующие процессы установки. Порядок вашего подключения к этой консоли зависит от особенностей вашего соединения с сервером виртуализации, от наличия у него графических возможностей и т. д., поэтому эта тема выходит за рамки данной статьи.

Аргументы опции --disk указывают, что эта виртуальная машина будет создана в пространстве хранения объемом 20 ГБ, которое автоматически выделяется из пула хранилищ NFS-POOL, созданного в предыдущем разделе. Образ диска для этой виртуальной машины будет создан в формате raw.
Это простой формат для дисковых образов, обладающий отличной переносимостью на большинство технологий виртуализации и эмуляции
(в разделе
Ресурсы приведена ссылка на страницу libvirt Storage Management, на которой можно получить информацию о других поддерживаемых форматах образов).

Другие аргументы команды virt-install
показывают, что в исходной конфигурации новая виртуальная машина имеет 2 ГБ оперативной памяти
(--ram) и два виртуальных центральных процессора (--vcpus),
а также сетевой мост br0
(--network). для доступа к сети. Для получения информации о создании сетевого моста обратитесь к статье под названием Creating a simple KVM virtual machine на сайте developerWorks, ссылка на которую приведена в разделе Ресурсы.

Последние две опции команды virt-install оптимизируют виртуальную машину для использования в качестве полностью виртуализированной системы (--hvm) и указывают, что KVM является базовым гипервизором (--virt-type)
для поддержки новой виртуальной машины. Обе этих опции обеспечивают определенную оптимизацию в процессе создания и установки операционной системы; если эти опции не заданы в явном виде, то вышеуказанные значения применяются по умолчанию. Явное задание этих опций рекомендуется применять, если вы сохраняете журналы команд по установкам своих виртуальных машин, поскольку в этом случае в вашем журнале сохранится информация о среде виртуализации для каждой виртуальной машины.

Можно использовать подобную команду для создания виртуальной машины, исполняющей другую операционную систему. С этой целью нужно задать надлежащее имя для виртуальной машины и соответствующим образом изменить аргументы опций
--cdrom, --os-type и
--os-variant.

Заключение

Основанные на Linux технологии виртуализации с открытым исходным кодом непрерывно развиваются. Простота использования и непрерывное совершенствование технологии KVM помогли ей вытеснить потенциально более мощную технологию виртуализации Xen в качестве стандартного средства с открытым исходным кодом для виртуализации в среде Linux. Безотносительно к выбранной вами технологии виртуализации эта эволюция демонстрирует ценность применения стандартных, независимых от технологии команд администрирования, таких, например, которые предоставляет API-интерфейс виртуализации libvirt.

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

Ресурсы для скачивания

Похожие темы

• Оригинал статьи: Using KVM virtualization.
• Virtual Machine Manager— основной сайт для получения информации о VMM и связанных с ним независимых от гипервизоров инструментах, таких как
  virsh и virt-install.
• Гипервизоры, виртуализация и облако: Анализ гипервизора KVM Бханупракаш Тхолети (Bhanuprakash Tholeti), developerWorks, сентябрь 2011 г. Данная статья представляет собой хорошее введение в технологию KVM и в ее базовую архитектуру.
• Create a
  KVM-based virtual server (Создание виртуального сервера на базе KVM), Да Шуан Хе (Da Shuang He), developerWorks, январь 2010 г. Статья представляет собой пошаговое руководство по созданию простого виртуального сервера в локальном дисковом хранилище. Кроме того, в ней объясняется, как создать сетевое подключение через мост с целью упрощения входящих и исходящих обращений для этой виртуальной машины.
• Отслеживание гостевых систем KVM с помощью libvirt и подсистемы аудита Linux, Марчело Черри (Marcelo H. Cerri), developerWorks, июнь 2012 г. В статье описывается превосходная методика, позволяющая использовать существующий механизм аудита Linux для отслеживания и мониторинга виртуальных машин на основе KVM.
• Управление ресурсами на KVM-системах, поддерживающих overcommitment, Адам Литке (Adam Litke), developerWorks, февраль 2011 г. В статье детально описывается максимизация загрузки виртуальных машин посредством использования механизма overcommitment при доступе виртуальных машин к физическим ресурсам.
• Посетите страницу libvirt
  Storage Management для получения дополнительной информации о поддерживаемых форматах образов.
• Материалы IBM по виртуализации в Твиттере (@IBMvirt).
• Веб-сайт libvirt Virtualization API содержит подробную информацию об этом API-интерфейсе, об абстракциях виртуализации, которые он поддерживает, и о формате XML, который он использует.
• Начальная страница веб-сайта KVMсодержит подробную информацию о KVM, а также ссылки на огромный массив разнообразных источников информации и релевантных сайтов.
• Начальная страница веб-сайта Xen Project предоставляет информацию общего характера о гипервизоре Xen и о релевантных технологиях.
• Начальная страница веб-сайта VirtualBox содержит ссылки на документы и на загрузку последних версий программного обеспечения VirtualBox для виртуализации на уровне домашнего офиса и малого предприятия.
• Оцените продукты IBM наиболее удобным для вас способом. Загрузите ознакомительные версии программных продуктов, воспользуйтесь их онлайновыми пробными версиями, примените продукты в облачной среде или обратитесь к ресурсу
  SOA
  Sandbox для изучения эффективной реализации решений на основе сервис-ориентированной архитектуры.

Работа с виртуальными машинами KVM. Подготовка хост-машины / Хабр

Вступление

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

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

$ egrep '(vmx|svm)' /proc/cpuinfo

Если есть — это замечательно.

Подготовка операционной системы

Установку Debian Squeeze я, пожалуй, описывать не буду: если уж вы добрались до KVM, то установка системы — плёвое дело.

Устанавливать нужно будет 64-битную OS, поскольку необходимые пакеты есть только для этой архитектуры.

В Debian Squeeze «свежесть» пакетов с KVM и сопутствующих программами нас совсем не устраивает, поскольку очень много всяких фиксов и фич попросту пройдут мимо нас. Поэтому мы добавим репозитории Debian Sid и experimental:

deb http://ftp.ru.debian.org/debian sid main contrib non-free

deb-src http://ftp.ru.debian.org/debian sid main contrib non-free

deb http://ftp.ru.debian.org/debian experimental main contrib non-free

deb-src http://ftp.ru.debian.org/debian experimental main contrib non-free

Указываем, что у нас базовый дистрибутив stable, а не то, что подумала система:

# echo 'APT::Default-Release "stable";' > /etc/apt/apt.conf.d/default

Оттуда нам понадобятся пакеты:

# aptitude -t experimental install linux-image-2.6.39-1-amd64 qemu-kvm virtinst libvirt-bin

Из стабильного репозитория нам будут нужны:

# aptitude install uml-utilities bridge-utils

На вашем рабочем десктопе вы можете поставить virt-manager (GUI-утилита), который позволит удобно создавать нужные конфигурации виртуальных машин.

Ядро

Ядро чем «свежее» — тем лучше (в известных пределах конечно: из git, например, я бы ставить не рекомендовал). Хорошим вариантом будет 2.6.39, вышедшее недавно.

Следует отметить, что в стандартном ядре отсутствует модуль для поддержки записи в UFS2, и если планируется запускать гостевую FreeBSD, потребуется собрать ядро с этим модулем. Ну и, конечно, в Debian-овском ядре отсутствуют свежие версии cgroups.

Что должно быть включено в ядре для использования максимального объема требуемого функционала:

CONFIG_VIRTIO_BLK=y

CONFIG_VIRTIO_NET=y

CONFIG_VIRTIO_CONSOLE=y

CONFIG_HW_RANDOM_VIRTIO=y

CONFIG_VIRTIO=y

CONFIG_VIRTIO_RING=y

CONFIG_VIRTIO_PCI=y

CONFIG_VIRTIO_BALLOON=y

CONFIG_CGROUPS=y

CONFIG_CGROUP_NS=y

CONFIG_CGROUP_FREEZER=y

CONFIG_CGROUP_DEVICE=y

CONFIG_CGROUP_CPUACCT=y

CONFIG_CGROUP_MEM_RES_CTLR=y

CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y

CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y

CONFIG_CGROUP_SCHED=y

CONFIG_BLK_CGROUP=y

CONFIG_NET_CLS_CGROUP=y

Затем идём по ссылке и устанавливаем все deb-пакеты оттуда, копируем insmod.static в /sbin/insmod.static (это нужно, поскольку в работе libguestfs использует статически скомпилированную версию insmod, а в Debian и Ubuntu такого файла просто нет, однако в последней версиии febootstrap эту проблему устранили, insmod.static более не нужно загружать на сервер). libguestfs позволяет нам получать доступ к диску VDS через API libguestfs(C, Perl, Python, PHP) или через утилиту guestfish.

Первый блин

Сейчас мы установили все, необходимое для запуска VDS, их доступа в сеть и установки самой виртуальной машины.

Давайте попробуем что-нибудь поставить, например, тот же самый Debian. Пока без настройки сети, просто, по умолчанию.

Скачиваем установщик netinstall:

$ wget cdimage.debian.org/debian-cd/6.0.1a/i386/iso-cd/debian-6.0.1a-i386-netinst.iso

Редактируем /etc/libvirt/qemu.conf, чтобы виртуальные машины работали у нас от непривилегированного пользователя:

user = "username"

group = "libvirt"

Поскольку у нас будут использоваться tun-устройства, нужно выставить capability CAP_NET_ADMIN, сделать это можно как для отдельного исполняемого файла, так и для пользователя в целом, или настроить чтобы libvirt не сбрасывал нужные права для qemu/kvm.

Выставляем для отдельного файла:

sudo setcap cap_net_admin=ei /usr/bin/kvm

Или выставляем для пользователя в целом в файле /etc/security/capability.conf:

cap_net_admin username

Или выставляем соответствующую настройку в /etc/libvirt/qemu.conf:

clear_emulator_capabilities = 0

Добавим пользователя в группу libvirt и kvm:

# adduser username libvirt

# adduser username kvm

Запустим установку виртуальной машины:

$ virt-install --connect qemu:///system -n debian_guest -r 512 --arch=i686 --vcpus=1 --os-type=linux --os-variant=debiansqueeze --disk debian-6.0.1a-i386-netinst.iso,device=cdrom --disk debian_guest.img,bus=virtio,size=2,sparse=false,format=raw --network=default,model=virtio --hvm --accelerate --vnc

Подробно разберём параметры, которые мы указали:

• —connect qemu:///system URL, по которому мы подключаемся к KVM. Подключаться можно через ssh.
• -n debian_guest Имя гостевой системы.
• -r 512 Выделяемый объём оперативной памяти в мегабайтах.
• —arch=i686 Архитектура гостевой операционной системы.
• —vcpus=1 Количество виртуальных процессоров, доступных гостю.
• —os-type=linux —os-variant=debianlenny Специфичные для данной операционной системы параметры.
• —disk debian-6.0.1a-i386-netinst.iso,device=cdrom Загружаемся с диска, образ которого указали.
• —disk debian_guest.img,bus=virtio,size=2,sparse=false,format=raw Создаём образ системы размером 2Гб, который сразу помещаем на диск (можно создать образ нулевого размера, но тогда возможна фрагментация, что получается несколько медленнее). Формат простой, можно сделать с dd файл. Драйвер диска virtio, использовать лучше virtio, чем ide: производительность их отличается если не на порядок, то в разы.
• —network=default,model=virtio Сетевые настройки по умолчанию. В этом случае libvirt создаст мост, сделает dhcp сервер и выдаст через него адрес для доступа виртуальной машины.
• —hvm Полная виртуализация — то есть, можно использовать собственные ядра.
• —accelerate Работа через /dev/kvm.
• —vnc Запускаем VNC, чтобы подключаться к текстовой консоли.

Утилиты настройки и управления

Для управления установкой и для клонирования виртуальных машин у нас есть две замечательные утилиты — графическая и консольная: virt-manager и virsh, соответственно. Конечно, консольная версия намного богаче по возможностям, но ничто не сравнится с видом графиков, от которых сердце сисадмина млеет.

Думаю с virt-manager вы и сами разберётесь, давайте попробуем покопаться в консольных внутренностях virsh. Вот несколько команд которые стоит выполнить и посмотреть что из этого получится:

$ virsh --connect qemu:///system list --all

$ virsh --connect qemu:///system dominfo debian_guest

$ virsh --connect qemu:///system stop debian_guest

Чтобы тысячу раз не писать —connect qemu:///system, добавьте:

export VIRSH_DEFAULT_CONNECT_URI= qemu:///system

В .bashrc или просто выполните эту команду в терминале.

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

В официальной документации предлагается использовать несколько вариантов организации сети: NAT, bridged и прямое использование сетевых карт. И, к сожалению, в различных примерах, которые я нашел в сети и на официальном сайте, рассматриваются только NAT и bridged сети.

В моей конфигурации используются TUN/TAP устройства, на которые с eth0 маршрутизируется трафик. Коротко опишу, почему выбран именно такой способ маршрутизации:

NAT нам не подходит, поскольку каждая VDS должна быть доступна из сети напрямую.

Схема с мостами не очень надёжная, поскольку теоретически есть возможность «захвата» IP адреса чужой виртуальной машины.

Итак:

<interface type='ethernet'>

    <mac address='52:54:00:ef:40:1d'/>

    <ip address='10.10.10.100'/>

    <target dev='debian_guest'/>

    <model type='virtio'/>

</interface>


Данный участок конфигурации нужно указывать непосредственно в конфигурационном файле гостя, расположенного по адресу /etc/libvirt/qemu/debian_guest.xml. Редактировать лучше всего через:

$ virsh edit debian_guest

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

Создадим необходимое нам виртуальное устройство.

Для начала нам нужно дать нашему пользователю возможность беспарольного обращения к системным командам. Для этого добавим в sudoers:

$ sudo visudo

Cmnd_Alias QEMU = /sbin/ifconfig, /sbin/modprobe, /usr/sbin/brctl, /usr/sbin/tunctl, /sbin/sysctl, /bin/ip, /usr/bin/cgcreate, /usr/bin/cgdelete, /sbin/tc

username ALL=(ALL:ALL) NOPASSWD: QEMU

Включим возможность форвардинга и проксирования arp-запросов:

sudo sysctl net.ipv4.conf.all.forwarding=1

sudo sysctl net.ipv4.conf.all.proxy_arp=1

Также можно добавить эти параметры в /etc/sysctl.conf и применить их:

sudo sysctl -p

Создадим виртуальную сетевую карту и поднимем устройство:

sudo tunctl -b -u username -t debian_guest

sudo ifconfig debian_guest 0.0.0.0 up

Создадим маршрут на нужное нам устройство с нужного IP-адреса:

sudo ip route add 10.10.10.100 dev debian_guest

Теперь можно запустить VDS:

$ virsh start debian_guest

Подключившись к консоли, мы увидим, что сети нет, но у нас появилось устройство eth2, вместо eth0. Это произошло потому, что система при загрузке в /etc/udev/rules.d/70-persistent-net.rules прописывает mac-адрес сетевой карты, и если mac сменился, она создаёт ещё одну запись о сетевой карте, вроде этой:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

Нужно удалить этот файл и перезагрузить VDS — после этого сетевая карта определится корректно.

Пропишем новые сетевые настройки в гостевой системе:

# ifconfig eth0 10.10.10.100 netmask 255.255.255.0

# route add default gw 10.10.10.10

10.10.10.10 — это IP-адрес хост-системы. Теперь мы сможем попинговать другие машины.

Добавим DNS-серверы в /etc/resolv.conf, и будет совсем замечательно:

nameserver 8.8.8.8

К слову, замечу, что оказалось очень удобно называть сетевые устройства, принадлежащие VDS, также, как и сами VDS — отпадает необходимость искать, кому принадлежит устройство tap0 или vnet0, или как там ещё можно их обозвать.

Если понадобится выдать виртуальной машине ещё один IP-адрес, достаточно будет просто на хост-машине прописать ещё один маршрут:

# ip route add 10.10.10.101 dev debian_guest

А в гостевой системе создать алиас для сетевого устройства:

# ifconfig eth0:1 10.10.10.101

В следующей части

В следующей статье я расскажу о том, как создать образ VDS, что вообще меняется от системы к системе, и как эти параметры можно удобно менять.

KVM vs. Xen / Блог компании Cloud4Y / Хабр

Мы в 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.

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

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

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

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

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

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

Что такое KVM?

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

KVM является частью Linux . Если у вас Linux 2.6.20 или новее, у вас есть KVM. KVM был впервые анонсирован в 2006 году, а годом позже был объединен с основной версией ядра Linux. Поскольку KVM является частью существующего кода Linux, он сразу же извлекает выгоду из каждой новой функции, исправления и усовершенствования Linux без дополнительной разработки.

Как работает KVM?

KVM превращает Linux в гипервизор типа 1 (голый металл). Всем гипервизорам необходимы некоторые компоненты уровня операционной системы, такие как диспетчер памяти, планировщик процессов, стек ввода / вывода, драйверы устройств, диспетчер безопасности, сетевой стек и многое другое — для запуска виртуальных машин. В KVM есть все эти компоненты, потому что это часть ядра Linux. Каждая виртуальная машина реализована как обычный процесс Linux, запланированный стандартным планировщиком Linux, с выделенным виртуальным оборудованием, таким как сетевая карта, графический адаптер, процессор (ы), память и диски.

Внедрение KVM

Короче говоря, вам нужно запустить версию Linux, выпущенную после 2007 года, и ее необходимо установить на оборудование X86, которое поддерживает возможности виртуализации. Если оба эти флажка отмечены, то все, что вам нужно сделать, это загрузить 2 существующих модуля (модуль ядра хоста и модуль для конкретного процессора), эмулятор и любые драйверы, которые помогут вам запустить дополнительные системы.

Но реализация KVM в поддерживаемом дистрибутиве Linux, таком как Red Hat Enterprise Linux, расширяет возможности KVM, позволяя обмениваться ресурсами между гостями, совместно использовать общие библиотеки, оптимизировать производительность системы и многое другое.

Переход на виртуальную инфраструктуру на основе KVM

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

Функции KVM

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

KVM использует комбинацию Linux с повышенной безопасностью (SELinux) и безопасной виртуализации (sVirt) для повышения безопасности и изоляции виртуальных машин. SELinux устанавливает границы безопасности вокруг виртуальных машин.sVirt расширяет возможности SELinux, позволяя применять безопасность обязательного контроля доступа (MAC) к гостевым виртуальным машинам и предотвращая ошибки ручной маркировки.

KVM может использовать любое хранилище, поддерживаемое Linux, включая некоторые локальные диски и сетевое хранилище (NAS). Многопутевый ввод-вывод может использоваться для улучшения хранения и обеспечения избыточности. KVM также поддерживает общие файловые системы, поэтому образы виртуальных машин могут совместно использоваться несколькими хостами. Образы дисков поддерживают тонкое выделение ресурсов, выделяя хранилище по требованию, а не сразу.

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

KVM наследует функции управления памятью Linux, включая неоднородный доступ к памяти и объединение одной страницы ядра. Память виртуальной машины может быть заменена местами, поддержана большими томами для повышения производительности, а также совместно использована или поддержана файлом на диске.

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

KVM наследует производительность Linux, масштабируясь в соответствии с нагрузкой по запросу, если количество гостевых машин и запросов увеличивается. KVM позволяет виртуализировать самые требовательные рабочие нагрузки приложений и является основой для многих установок виртуализации предприятия, таких как центры обработки данных и частные облака (через OpenStack ^® ).

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

Ядро Linux содержит расширения в реальном времени, которые позволяют приложениям на основе виртуальных машин работать с меньшей задержкой и лучшей расстановкой приоритетов (по сравнению с «голым железом»).Ядро также разделяет процессы, требующие длительного времени вычислений, на более мелкие компоненты, которые затем планируются и обрабатываются соответствующим образом.

Управление KVM

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

KVM и Red Hat

Мы настолько верим в KVM, что это единственный гипервизор для всех наших продуктов виртуализации, и мы постоянно улучшаем код ядра, внося свой вклад в сообщество KVM. Но поскольку KVM является частью Linux, он уже включен в Red Hat Enterprise Linux — так зачем вам Red Hat Virtualization?

Ну, у Red Hat есть 2 версии KVM. KVM, поставляемый с Red Hat Enterprise Linux, обладает всеми функциями гипервизора с базовыми возможностями управления, что позволяет клиентам запускать до 4 изолированных виртуальных машин на одном хосте.Red Hat Virtualization содержит расширенную версию KVM, которая позволяет корпоративному управлению неограниченным количеством гостевых машин. Он идеально подходит для виртуализации центров обработки данных, технических рабочих станций, частных облаков, а также при разработке или производстве.

.

Что такое KVM? — Linux Подсказка

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

Преимущества виртуализации

В прошлом однородность была способом работы в центрах обработки данных, в центрах разработки и дома. Практически все машины будут запускать одну и ту же версию одной операционной системы, будь то Linux, Windows или FreeBSD. Времена изменились.

Сегодня мы ожидаем, что разные ОС, такие как Linux и Windows, и даже разные версии ОС (например, Windows XP и 10) будут размещены в одной компьютерной среде.Без виртуальных машин необходимо развернуть и поддерживать несколько физических машин, чтобы приложения могли запускаться на нескольких операционных платформах. Виртуализация позволяет запускать несколько виртуальных машин, каждая из которых может работать с разными ОС, на одной физической машине.

Преимущества виртуальных машин над физическими:

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

2. Улучшенный I.T. отзывчивость и продуктивность.
   Подготовка нового физического оборудования влечет за собой длительный период ожидания приобретения, за которым следует длительный период установки и развертывания после его прибытия. Напротив, подготовка виртуальных машин может быть автоматизирована и сделана доступной за считанные минуты, а не дни или даже недели, как иногда требуется традиционное приобретение машин.

3. Экономия затрат.
   Большие центры обработки данных сэкономят деньги за счет более низких эксплуатационных расходов. Экономия достигается за счет уменьшения счетов за электроэнергию в результате более низких требований к охлаждению и мощности.

Представляем KVM

Виртуальная машина на основе ядра, сокращенно KVM, является бесплатным гипервизором с открытым исходным кодом. Он конкурирует в зрелой отрасли с альтернативами с открытым исходным кодом, такими как Xen, VirtualBox, а также с проприетарными продуктами, такими как VMware vSphere, Citrix XenServer, Microsoft Hyper-V.

До 2005 года все решения для гипервизоров, такие как Xen и VirtualBox, были программными. В архитектуре x86 просто не было возможности поддерживать виртуализацию. В 2005 году введение расширений набора команд Intel VT и AMD-V навсегда изменило ландшафт виртуализации. KVM выпустил свою первую версию в 2006 году и был одним из первых гипервизоров, который воспользовался преимуществами нового оборудования для оптимизации производительности виртуализации.

Вы можете установить KVM на любой 32-битный или 64-битный компьютер x86, «хост-компьютер» на жаргоне гипервизора, который поддерживает расширение Intel VT или AMD-V.Сегодня современные гипервизоры обычно поддерживают гибридную виртуализацию: с аппаратной поддержкой, когда это возможно, и с переключением на программную только для старых наборов микросхем.

KVM относится к гипервизору типа 2, что означает, что он работает в операционной системе хоста. Как следует из названия, KVM основан на ядре, а если быть более точным, это ядро ​​Linux. Поэтому неудивительно, что KVM поддерживает только Linux в качестве основной ОС. (Впоследствии KVM был портирован на FreeBSD.) Если вам нужен многоплатформенный гипервизор типа 2 с открытым исходным кодом, VirtualBox — хороший кандидат.VirtualBox изначально может работать в Windows, Linux, Mac OS X и Solaris.

Xen, напротив, представляет собой гипервизор типа 1, также известный как гипервизор «голого железа», который запускается непосредственно как встроенное ПО на хост-машине. Преимущество типа 1 перед типом 2 заключается в эффективности, достигнутой за счет того, что гипервизор работает непосредственно на базовом оборудовании. Недостатком является то, что гипервизор типа 1 может не поддерживать такой широкий диапазон хост-устройств, как хост-операционная система гипервизора типа 2.

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

• Дистрибутивы Linux, включая Debian, Ubuntu, Centos, Fedora, RedHat Enterprise Linux
• BSD, например OpenBSD, FreeBSD, NetBSD
• Solaris
• Окна

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

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

KVM состоит из двух технологических компонентов: ядра и пользовательского пространства. Компонент ядра состоит из двух загружаемых модулей ядра: kvm.ko и либо kvm-intel.ko, либо kvm-amd.ko. Модуль kvm.ko обеспечивает обработку виртуализации, независимую от архитектуры ядра. Модули kvm-intel.ko и kvm-amd.ko соответствуют модулям для процессоров Intel и AMD. Эти модули были объединены в ядро ​​Linux начиная с версии ядра 2.6.20.

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

Важно, что модули ядра не эмулируют оборудование виртуальной машины, на котором работает гостевая ОС. Эта работа принадлежит пользовательскому пространству. KVM использует QEMU, который работает в пользовательском пространстве, для создания виртуальных машин, которые взаимодействуют с гостевыми ОС.Каждая виртуальная машина — это обычный процесс Linux. Одним из больших преимуществ является то, что вы можете использовать знакомые команды Linux, такие как top и kill, для мониторинга виртуальных машин и управления ими.

Резюме и заключение

KVM — отличное решение с открытым исходным кодом для полной виртуализации на хост-платформе Linux. После более чем 10 лет активной разработки KVM стал де-факто стандартным инструментом виртуализации на уровне машины во многих дистрибутивах Linux.

.

Что такое виртуализация KVM в Linux?

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

Что такое виртуализация в Linux?

Типы виртуализации, доступные в Linux / Unix

Преимущества виртуализации

Что такое виртуализация KVM?

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

• Может напрямую взаимодействовать с ядром
• Виртуализация по умолчанию в ведущих дистрибутивах Linux
• Одно из программ Linux, разработанных агрессивно.
• Почти становится конкурентом VMware за счет внедрения таких технологий, как v2v, p2v, и многих инструментов с открытым исходным кодом для управления виртуальными машинами
• Количество программ автоматизации облачных вычислений с открытым исходным кодом, использующих KVM в качестве гипервизора по умолчанию.

Как работает виртуализация KVM?

После того, как мы установим KVM на Linux, создается аппаратный файл / dev / kvm, который будет действовать как интерпретатор между реальным оборудованием и менеджером гипервизора (Virt-manager).Когда когда-либо поступает запрос на изменение / добавление оборудования от диспетчера гипервизора, ваше программное обеспечение KVM начинает выделять эти ресурсы виртуально, взаимодействуя с реальным оборудованием. Предположим, мы хотим изменить ОЗУ на виртуальной машине, ваш менеджер гипервизора сообщает об этом KVM для выделения ресурса. Затем KVM взаимодействует с оборудованием и резервирует эту оперативную память из реальной оперативной памяти для этой конкретной виртуальной машины. То же самое происходит и с другими ресурсами. Для простоты я не объяснил концепцию надувания и другие вещи.

Архитектура виртуализации Kvm в Linux

(KVM) Терминология виртуализации

VT (технология виртуализации) включена: Если оборудование поддерживает виртуализацию напрямую без какого-либо стороннего программного обеспечения для моделирования, то это оборудование называется процессором с поддержкой VT. Это обозначается как VTx в процессорах Intel и AMD-v для процессоров AMD. Поэтому, если вы хотите установить KVM на свой компьютер, ваш процессор должен поддерживать один из них.

Гостевая ОС: Гостевая ОС — это ОС, которую вы собираетесь установить на виртуальной машине, которая будет гостевой для хоста / базовой ОС. Вы можете установить несколько гостевых операционных систем на хост-машину.

HOST OS: Это ОС, в которую вы собираетесь установить программное обеспечение гипервизора, такое как KVM, виртуальный менеджер и т. Д. Эта базовая ОС, чтобы ваш гипервизор начал работать, поскольку KVM не является ОС, он должен запускаться в ОС, чтобы получить что-то сделанный.

Hyperviser: Hyperviser — это программное обеспечение, которое поможет нам в реализации виртуализации.KVM, Vmware ESX и Xen — некоторые примеры гипервизоров.

Виртуальная машина: Виртуальная машина — это виртуальное оборудование, выделенное гипервизором для установки на нем гостевой ОС, чтобы оно могло работать как отдельная машина.

libvirt: Набор инструментов для взаимодействия с возможностями виртуализации последних версий Linux (и других ОС). Это строительный блок KVM.

virsh (Оболочка виртуализации): Virsh — это оболочка для управления гипервизорами и виртуальными машинами непосредственно из терминала ОС хоста.Мы подробно рассмотрим этот вирш в наших следующих публикациях.

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

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

v2v: Это концепция миграции виртуальной машины на другую виртуальную машину во время обслуживания и т. Д.

Hyper-threading (HT): Это запатентованная Intel реализация одновременной многопоточности (SMT), используемая для улучшения распараллеливания вычислений (выполнения нескольких задач одновременно), выполняемых на микропроцессорах ПК.

Overcommit: Это концепция выделения ресурсов, превышающих доступные ресурсы ОС HOST, такие как RAM, CPU и жесткий диск. Мы должны быть очень осторожны, когда имеем дело с чрезмерной фиксацией.

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

Просмотры сообщений:
14 260

Следующие две вкладки изменяют содержимое ниже.

Мистер Сурендра Энн из Виджаявады, Андхра-Прадеш, Индия. Он сторонник Linux / открытого исходного кода, верит в упорный труд, практичный человек, любит делиться знаниями с другими, любит собак, любит фотографию. Он работает инженером-разработчиком в Taggle systems, компании по автоматическому учету воды IOT, Сидней. Вы можете связаться с ним по адресу surendra (@) linuxnix dot com.

.

Что такое KVM

KVM — это аббревиатура от Keyboard, Video (Monitor) и Mouse, которую иногда также называют переключателем ПК или электронным переключателем. Однако KVM-переключатель сильно отличается от обычного переключателя данных. Основная функция KVM-переключателя — управление, переключение и управление множеством ПК с помощью одной клавиатуры, монитора и мыши. Когда запускается обычный ПК, операционная система автоматически пытается обнаружить сигналы клавиатуры и мыши. После подтверждения подключения на экране отобразится стартовая страница.В результате операции запуска отдельного ПК (ЦП / сервера) неразрывно связаны с запуском его клавиатуры и мыши.

Если вам необходимо управлять несколькими компьютерами, вам необходимо приобрести несколько комплектов клавиатуры, мыши и монитора. Это не самое эффективное управление, поскольку оно не только занимает много места, но и требует больших затрат. Также проблематичным может быть сохранение ряда больших ЭЛТ-мониторов с клавиатурами и мышами. Таким образом, KVM-переключатель «родился» из требований экономии места, затрат и повышения эффективности управления.

При покупке KVM выбор часто основывается на количестве ПК, которыми вам нужно управлять. KVM с несколькими портами обычно более удобны в использовании без необходимости установки дополнительного программного обеспечения. Также ими можно легко управлять с помощью горячих клавиш или клавиш переключения. Кроме того, некоторые из этих KVM, оборудованных всего несколькими портами, даже не нуждаются во внешнем источнике питания. Из-за требований к окружающей среде (пространству) высокоуровневые KVM-переключатели с несколькими портами могут быть установлены в серверной стойке, занимая всего лишь 1U или 2U.Эти KVM-переключатели также могут использовать IP-сети для управления розетками электропитания и управления запуском и выключением ПК.

Основная функция переключателя KVM — использовать только один набор клавиатуры, монитора и мыши для запуска нескольких ПК. Важно, чтобы переключатель KVM гарантировал, что имитируемые сигналы клавиатуры и мыши доходят до каждого ПК, и что во время переключения это не влияет на работу ЦП ПК. KVM-переключатель также должен обеспечивать стабильное разрешение видео, поддерживать несколько компьютерных платформ и операционных систем и иметь возможность взаимодействовать с клавиатурами и мышами разных производителей.Каждый KVM-переключатель может поддерживать только максимальное количество подключений к ПК, то есть общее количество портов. Один KVM-переключатель может обеспечить всего два порта ЦП, а установка с несколькими переключателями KVM может предложить более 4000 портов ЦП.

По мере увеличения количества подключенных компьютеров потребности в технологиях, например идентификации сигналов, возрастают, чтобы справиться с множественными входными и выходными сигналами. Соответственно, увеличивается сложность управления, а также появляются такие функции, как удаленное управление, множественная сегментация и высокий уровень безопасности.В настоящее время в решениях для удаленного управления используются KVM-переключатели с аппаратным управлением или программное обеспечение, такое как PCAnywhere, VNC, OpenSSH и Microsoft Telnet Service. Пожалуйста, обратитесь к нашей колонке «Решения для дистанционного управления» для сравнения решений KVM и программных решений для дистанционного управления.

Ранее KVM в основном использовались в серверных комнатах и ​​информационных центрах обработки данных, оборудованных несколькими серверами. Серверная комната среднего размера может содержать от 16 до 32 серверов, тогда как серверная комната большего размера может содержать более 100 серверов.Поскольку цены на ПК становятся все более низкими, средний потребитель теперь может позволить себе второй или несколько ПК. Поэтому в настоящее время потребители покупают KVM как для удобства, так и для экономии места в доме.

KVM-переключатели

постоянно развиваются для удовлетворения новых потребностей, таких как достижения в технологиях, новые спецификации, инновационные концепции и новые приложения. Некоторые примеры новейших технологий KVM включают KVM + Peripheral / KVMP¡BKVM + Fast Ethernet / KVME, Wireless KVM и KVM через сеть.Эти новые технологии KVM также становятся все более популярными на потребительском рынке, на котором появляются новые технологии для личного дома. В последнее время цифровая техника становится популярной среди потребителей. Многогранная разработка KVM-переключателей может удовлетворить и этот рынок и создать новые концепции, которые ранее были невозможны.

Некоторые основные термины для технических характеристик переключателя KVM включают:

1. Порты
Количество портов указывает на количество ПК, которые могут подключаться к KVM.Например, для 8-портового KVM-переключателя одна клавиатура, монитор и мышь могут управлять до 8 ПК. В настоящее время наиболее распространенное количество портов, оснащенных переключателем KVM, составляет 2, 4, 8, 16 или 32 порта. Когда количество ПК превышает тридцать два, для подключения к ПК используется каскадное или последовательное подключение KVM. Для более удобного управления и запуска нескольких ПК некоторые KVM имеют различные функции для помощи в управлении, такие как горячие клавиши, экранное меню (OSD) и трансляция. Некоторые инновационные компании, производящие KVM, также разработали собственные встроенные логические микросхемы ядра, чтобы повысить стабильность работы и эффективность обработки сигналов.

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

2. Консоль
Консоль — это станция ввода / вывода для компьютера, включая монитор, клавиатуру и мышь (при необходимости). Однако в терминах KVM это относится к элементу управления, который используется для управления клавиатурой, монитором и мышью ПК. Обычно консоль имеет три разных порта для клавиатуры, мыши и монитора. Технические характеристики разъема для клавиатуры и мыши — USB и PS / 2, а для монитора — DVI и HDB 15.

Примечание: Некоторые консоли KVM, поддерживающие звук, также имеют порты для микрофона и динамиков. KVM, специально разработанные для использования с компьютерами SUN и MAC, имеют разные порты.

3. CPU / KVM
Этот термин относится к подключенному компьютеру. Один порт ЦП на KVM имеет три разных сигнальных порта (клавиатура, мышь и монитор) для подключения к портам на ПК.

Чтобы сэкономить на Спецификации материалов (BOM) и повысить удобство установки, некоторые компании производят собственные проприетарные кабели, объединяющие вышеупомянутые три кабеля в один.Использование трех кабелей в одном упрощает пространство на рабочем столе за счет уменьшения загромождения нескольких кабелей. На кабельные сигналы могут легко повлиять помехи от внешних и даже внутренних источников. Поэтому рекомендуется выбрать профессиональный бренд KVM, чтобы свести к минимуму эти проблемы.

Примечание. KVM, поддерживающие звук, также имеют порты для микрофона и динамиков, доступные на порте CPU / KVM.

Категории переключателей

KVM можно разделить следующим образом:

• малый и домашний офис (SOHO)
• малый и средний бизнес (МСБ)
• большой или высококачественный глобальный KVM корпоративного уровня

Многие компании, производящие KVM, затем делят KVM высокого класса на KVM высокого класса с дистанционным управлением и KVM высокого класса с дистанционным управлением.Для получения дополнительных сведений о различных типах KVM посетите домашнюю страницу ATEN по адресу www.aten.com.

.