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

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

Виртуализация на основе технологии KVM (Kernel-based Virtual Machine) в значительной степени заменила Xen-виртуализацию в качестве используемого по умолчанию механизма с открытым исходным кодом для создания и поддержки виртуальных машин на большинстве Linux-систем. Хотя мотивация для этого изменения исходит преимущественно из сферы сборки и поддержки, а не из технической сферы, реальность состоит в том, что многим корпоративным ИТ-подразделениям, занимающимся виртуализацией, придется изучить административные инструменты контроля и управления, которые используются при работе с KVM. Кроме того, ИТ-подразделения с предшествующими инвестициями в виртуализацию на основе Xen, переходящие на технологию KVM, с большой вероятностью предпочтут - везде, где это возможно – преобразовать существующие виртуальные машины в форматы, поддерживающие KVM, вместо того, чтобы создавать эти машины заново.

Вильям фон Хаген, системный администратор, писатель, WordSmiths

Вильям (Билл) фон Хаген является писателем и администратором UNIX-систем на протяжении 20 лет, а с 1993 года стал активным сторонником Linux. Билл является автором и соавтором книг по таким темам, как Ubuntu Linux, виртуализация с помощью Xen, коллекция компиляторов GNU (gcc), SUSE Linux, Mac OS X, файловые системы Linux и SGML. Он также написал множество статей об издательских технологиях и создании Web-сайтов в Linux и Mac OS X. С Биллом можно связаться по адресу wvh@vonhagen.org.



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-виртуализации.


Типовые средства администрирования для KVM и Xen

Поскольку 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 для получения дополнительной информации о поддерживаемых форматах образов.
  • In the Блоги по виртуализации на сайте developerWorks — знакомьтесь с актуальными комментариями и новейшими сведениями о технологиях виртуализации, включая KVM.
  • Материалы IBM по виртуализации в Твиттере (@IBMvirt).
  • Раздел Open Source на сайте developerWorks содержит огромный массив информации по инструментам с открытым кодом и по использованию технологий с открытым кодом.
  • Дополнительная техническая литература по этой и другим техническим темам.
  • Читайте developerWorks в Твиттере.
  • Смотрите демонстрации "по запросу" на веб-сайте developerWorks, охватывающие диапазон от демонстраций для новичков по установке и настройке продуктов до демонстраций по углубленным функциональным возможностям для опытных разработчиков.

Получить продукты и технологии

  • Веб-сайт libvirt Virtualization API содержит подробную информацию об этом API-интерфейсе, об абстракциях виртуализации, которые он поддерживает, и о формате XML, который он использует.
  • Начальная страница веб-сайта KVMсодержит подробную информацию о KVM, а также ссылки на огромный массив разнообразных источников информации и релевантных сайтов.
  • Начальная страница веб-сайта Xen Project предоставляет информацию общего характера о гипервизоре Xen и о релевантных технологиях.
  • Начальная страница веб-сайта VirtualBox содержит ссылки на документы и на загрузку последних версий программного обеспечения VirtualBox для виртуализации на уровне домашнего офиса и малого предприятия.
  • Оцените продукты IBM наиболее удобным для вас способом. Загрузите ознакомительные версии программных продуктов, воспользуйтесь их онлайновыми пробными версиями, примените продукты в облачной среде или обратитесь к ресурсу SOA Sandbox для изучения эффективной реализации решений на основе сервис-ориентированной архитектуры.

Обсудить

  • Присоединяйтесь к сообществу My developerWorks community. Связывайтесь с другими пользователями developerWorks и знакомьтесь с ориентированными на разработчиков форумами, блогами, группами и вики-ресурсами.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux
ArticleID=979605
ArticleTitle=Использование виртуализации на основе KVM
publish-date=08042014