Виртуализация *

Представьте, что мощные и прожорливые десктопные приложения наподобие Photoshop, AutoCAD или современных игр, могли бы работать как веб-приложения — без длительного скачивания и установки, без привязки к конкретному устройству, и при этом сохраняли бы работоспособность даже при обрыве связи. Технология Сloudpaging от стартапа Numecent позволяет делать именно это. Cloudpaging объединяет три давно известных технологии (виртуализация приложений, динамическая загрузка страниц памяти и облачные сервисы) в нечто качественно новое. Любое Windows-приложение автоматически виртуализируется и разбивается на маленькие фрагменты-страницы, которые могут скачиваться с сервера в любом порядке. На стороне клиента виртуальный блок управления памятью загружает в RAM только те фрагменты кода, библиотеки и ресурсы, которые необходимы в данный момент, подгружая остальное с сервера по мере необходимости. Все полученные с сервера страницы сохраняются в кэше на диске, и при обрыве связи приложение продолжит работать до тех пор, пока ему не потребуется страница, которой в кэше нет.

Хочу поделиться опытом своей команды по миграции с древнего VMware Server 2.0 на ESXi 4.1. В ходе оптимизации расходов на обслуживание перед нами встала задача уйти с сильно подтормаживавшего VMware Server под виндой на бесплатный ESXi. Задача усложнялась территориальной распределённостью серверов (по всей России) и сжатыми сроками, в которые необходимо было это сделать.

Дано:

1. Полтора десятка серверов в удалённых локациях. Возьмём за данность, что они имеют интерфейс удалённого управления (DRAC/ILO/IP KVM). Без этого миграция сильно усложняется большим количеством командировок.
2. На серверах крутится по 3 виртуальных машины — контроллер домена, работающий также как DNS и DHCP-сервер (виртуальный диск 40 гигабайт), WSUS + хранилище дистрибутивов (150 гигабайт), и сервер, сканирующий сеть филиала на уязвимости (ещё 40 гигабайт).
3. Промежуточных серверов, на которые можно было бы временно поставить ещё один ESXi и осуществить конвертацию на него «живых» машин у нас нет, но для хранения слитой информации у нас есть файлсервера, подключённые с нашими серверами в тот же свитч — в лучшем случае гигабитный, но чаще всего 100 мегабит.
4. На все сервера у нас есть админские права через AD-группы (в большой компании это не всегда так, но в данном случае мы их получили). Паролей локального админа на эти сервера у нас нет.

Требуется:
Избавиться от связки Windows + VMware Server. Профит: высвобождаем лицензии на ОС, а также ускоряем работу виртуалок, ибо периодически хост-машина сжирала все процессорные ресурсы (причина — процесс tomcat всё того же реликтового гипервизора) — виртуалкам становилось очень неуютно.

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

Статьи, которые можно найти в этой связи в Интернет, например:
VMware Knowledge Base
Аналог, с картинками
к сожалению неполны.

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

Говорят, что современные аппаратные технологии поддержки виртуализации (VT-d у Intel, IOMMU у AMD) позволяют отдавать физическое устройство на шине PCI в непосредственное управление виртуальной машине. В том числе видеокарту.
Воображение рисует такую конфигурацию: настольный сервер с гипервизором, на нем запускается гостевая пользовательская операционная система, имеющая доступ к необходимым устройствам ввода-вывода, один-два неприхотливых сервера по мере надобности, ну и сколько надо виртуалок для бесчеловечных экспериментов. Управляем гипервизором через консоль в гостевой ОС либо удаленно, с ноутбука, скажем.
Вдохновленный этой картиной, я решил попробовать, но оказалось, что проброс (passthrough) видеоадаптера — задача не совсем тривиальная. Только месяца через три боданий с железом и чтения форумов удалось получить положительный результат. В качестве гипервизора пробовал VMware и Xen. Получилось только с Xen.

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

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

Для начала зачем это может понадобиться. Простейший пример — у вас есть сервер без надёжного аппаратного RAID контроллера. Но вы хотите рейд. Без проблем — Linux (и XenServer) содержит великолепнейшую штуку — mdadm. А нужен вам этот RAID для файлопомойки, причём файлопомойка займёт всё доступное место. Смысла городить RAID, а поверх него ещё делать XenServer StorageRepository (SR) с type=lvm, в котором создавать один-единственный диск на весь объём нет. Гораздо лучше создать RAID, и пробросить его блочное устройство непосредственно в виртуальную машину. Так и надёжней — в случае чего вы всегда сможете достать жёсткие диски из сервера и воткнуть их в любую Linux машину, которая тут же увидит все ваши данные.

XEN.org (не путайте с Citrix, использующего гипервизор Xen как основу для своего коммерческого продукта виртуализации ) совместно с Samsung недавно начала работы по портированию своего открытого паравиртуализационного гипервизора на архтектуру ARM v5 и v7.

Участие Samsung в этом проекте неслучайно, все же эта компания один из крупнейших производителей процессоров ARM этих семейств, и ее поддержка для XEN.org будет весьма кстати, тем более, что в компании занимаются вопросами портирования Xen еще с 2008 года.

Сложилось так что понадобился инструмент для управления своими виртуалками вне офиса и при этом не всегда под рукой была машина с ОС Linux. Раньше приходилось активно пользоваться Putty и консольной утилитой virsh, что очень напрягало даже не так управление виртуалками а как их создание. По началу писал bash скрипты для оптимизации своих действий, но не всегда это было удобно.

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

Я уже описывал в статье «Консолидация CAD-систем» решение, позволяющее обеспечить удаленную работу на профессиональной графической станции через PCoIP. Но эта технология позволяет реализовать подключение 1:1, т.е. один пользователь работает удаленно на одной физической графической станции. Такая реализация подходит под узкий круг задач и не позволяет нескольким пользователям одновременно использовать аппаратные ресурсы графической станции. Для того чтобы обеспечить многопользовательский доступ к одной аппаратной платформе необходимо прибегнуть к виртуализации.
На сегодняшний день существует несколько продуктов, позволяющих использовать в виртуальной машине ресурсы 3D-видеоадаптера. Одни из наиболее популярных решений – это Microsoft RemoteFX, Citrix HDX 3D Professional Graphics, VMware View и Parallels Workstation Extreme.
Инженеры DEPO Computers на протяжении многих месяцев проводят исследование и тестирование этих технологий, оптимизируют настройки, дорабатывают конфигурацию. Основной задачей является виртуализация с эффективным использованием физического графического процессора в виртуальной машине для работы в тяжелых CAD-приложениях. В реализации подобного решения существует две основные трудности: возможность виртуальной машины использовать максимум функционала 3D-видеокарты, и способность протокола передачи данных обеспечить максимум качества и производительности. Технологиям RemoteFX и HDX 3D Pro я планирую посвятить отдельные статьи.
Решение Parallels Workstation Extreme, в отличие от остальных примеров, с помощью PCoIP-карты поддерживает аппаратное сжатие передаваемого по сети потока. В связи с этим оно способно обеспечить наилучший результат по производительности.

На хабрахабре уже неоднократно обсуждались технологии работы с памятью используемые в различных гипервизорах. Эти технологии зачастую принято объединять под общим названием — Memory Overcommitment.
Цели которые обычно стремятся достигнуть применяя memory overcommitment две:

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

В этом небольшом топике я хочу предложить вам вскользь вспомнить технологии, которые уже были описаны в значительно большем объеме другими хабра-пользователями, и остановится чуть подробнее на относительно новых, реализованных в гипервизоре vSphere 5.0.

Доброго времени суток, Хабровчане.

Преамбула

XenApp (читается «ЗенАп») придуман компанией Citrix для виртуализации и доставки приложений через тонкий клиент, посредством своего собственного протокола CIA. Надо сказать, что идея сама по себе хороша, потому что в теории избавляет от многих головняков, типа покупки лицензионного софта от Империи Зла и других, чуть менее жадных вендоров. Конечно, это интересно, только если брать приложения в аренду, потому что лицензии на XenApp стоят достаточно дорого. Хочется отметить, что XenApp работает только под Windows.
Не знаю, к сожалению или к счастью, но все крупнейшие производители самого потребляемого софта сейчас имеют свои полнофункциональные продукты, доступные либо через web-интерфейс, либо через тонкий клиент, поэтому мне кажется, что XenApp, как отдельный продукт, очень скоро станет неинтересен конечному потребителю, и останется в поле зрения у компаний, которые сами занимаются арендой приложений. Как раз на аренду приложений сделала ставку моя компания.
И после того, как я был озадачен этой интересной затеей, я понял, что гугль ничего внятного на русском языке про XenApp не выдаёт, а всё, что можно покурить — это обширный мануал на сайте Citrix.com на английском языке. Но разве для нас это проблема?
Руководствуясь чувством «помочь ближнему своему» я решил описать процесс установки и настройки XenApp, который мне пришлось расковыривать самостоятельно, используя англоязычный мануал и плохо знакомого человека, который лицензированный специалист Citrix.

Как вы уже догадались с темы поста речь сегодня пойдет о установке VMware View Client (не VMware View Open Client) с поддержкой PCoIP и поддержкой проброса USB на Linux. Сразу хотел бы предупредить, что данное решение не является официальным, мало того, мне неизвестно насколько оно легально, т.к. в нем используются бинарные пакеты от HP которые официально предназначены для тонких клиентов HP ThinPro. И так, всех, кого не смущает мое предупреждение, прошу под кат.

Появилось желание расширить функционал централизованного хранилища, а счета за электричество натолкнули на мысль о смене железа с Intel Celeron на Atom. Одним из преимуществ можно считать то, что Atom работоспособен даже без активного охлаждения. Таким образом, подверженными механическим поломкам остаются только жесткие диски. В случае, если бы оправдались заявления о проблемах с производительностью, он по-прежнему бы сгодился на FreeNAS хранилище. Итак, тесты:

Данный пост является продолжением Ещё одной архитектуры виртуальной машины (части первой).

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

Данный пост является продолжением Ещё одной архитектуры операционной системы.

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

Нативный API (С/С++) не подходил по нескольким причинам. Во-первых, он требует разделённые адресные пространства, что влечёт за собой приличные накладные расходы на IPC и взаимодействие с ядром. Вдохновлённый современными веяниями, я хотел ОС одного адресного пространства. Во-вторых, нативный API не обеспечит бинарной совместимости кода между разными архитектурами. И, наконец, такой API будет препятствовать прозрачности удалённых вызовов. Итак, требовалась виртуальная машина. С неё я и решил начать.

Решил взять небольшую паузу в ежедневном хобби-кодировании, и поделиться с вами описанием того, что я, собственно, делаю. Итак, я пытаюсь разработать и реализовать виртуальную машину для несуществующей операционной системы, которую я, быть может, тоже когда-нибудь начну воплощать в жизнь. Не буду спорить с пеною у рта, доказывая, зачем нужна ещё одна ОС, отвечу кратко: главным образом затем, что мне это интересно.

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

Речь пойдет про использование контейнеров LXC, причем внутри другой виртуальной машины.

Специя или SPICE (сокр. от англ. «Simple Protocol for Independent Computing Environments», то есть «Простой протокол для независимой вычислительной среды») — открытый протокол удаленного доступа к компьютеру или виртуальной машине.

Использование SPICE позволяет не только получить доступ к экрану, а также к буферу обмена и звуковой карте. В настоящее время протокол SPICE находится в стадии интенсивной разработки, несмотря на это его уже сегодня можно попробовать использовать в виртуальной машине под управлением модифицированного гипервизора KVM вместо базового открытого протокола VNC (Virtual Network Computing), используемого по-умолчанию.

Коллеги, у меня для вас сегодня очень хорошая новость. Вышла публичная бета второй версии великолепной свободной платформы виртуализации Proxmox VE. Если ранее Proxmox (версии 1.x) мог конкурировать с VMware при использовании в небольших компаниях, то сегодня он замахнулся как минимум на средние.

Что же такое Proxmox?

— Это свободная платформа виртуализации (Open Source, GNU AGPL v3)
— Это принцип KISS (Proxmox состоит из небольшого числа прозрачно взаимодействующих компонентов: Debian как основа, пропатченное ядро Linux, KVM и окружение Proxmox, которое включает в себя web-интерфейс, демон синхронизации и консольные утилиты управления)
— Это простая установка
— Это удобный и функциональный Web-интерфейс (без необходимости устанавливать клиент)
— Это надёжность
— Это возможность использования уже имеющихся навыков администрирования Linux, без необходимости переобучения
— Это возможность использования преимуществ Linux, которые могут быть и не предусмотрены Web-интерфейсом Proxmox VE (например DRBD)

Когда начинается разговор об IAAS (упрощенно — виртуализации серверов), то сразу же звучат мантры "VMware, Hyper-V, XEN, OpenVZ/Virtuozzo, KVM, Jail".
Каждая из этих технологий имеет своих апологетов, имеет свои положительные и, разумеется, отрицательные стороны. Принципиально, все решения можно разделить на 2 группы по потребительским свойствам:

• контейнерная виртуализация (на уровне операционной системы) — какая операционная система используется в физическом сервере — такие виртуальные машины можно в ней и создавать (Linux-Linux, Windows-Windows, xBSD-xBSD) — гомогенная виртуализация
• аппаратная виртуализация и паравиртуализация — на физическом сервере с одной операционной системой можно создавать виртуальные машины с иными ОС (Linux-Linux, Linux-Windows, Linux-xBSD, Windows-Linux, Windows-Windows ...) — гетерогенная виртуализация

Однако, в нашей отрасли, редко кто вспоминает о существовании очень интересного решения — Parallels Server Bare Metall.