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

Как вы уже догадались с темы поста речь сегодня пойдет о установке 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.

Сегодня продолжу описывать испытания, на уже знакомом нам по предыдущему посту серверу Sun Fire T2000. Необходимо попробовать насколько безболезненно пройдет установка на такую машинку свеженького Oracle VM (бывший Ldom) и запуск в ней Solaris. Так сказать тренировочный забег перед официальной работой. Кому-нибудь да пригодится подробный мануал.

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

Аллилуйя! Огромнейший поток жалоб на новую модель лицензирования был услышан в компании VMware. Хотя стоит поправиться — клиенты VMware были возмущены не столько самой новой моделью лицензирования, сколько теми низкими объемами разрешенного vRAM на одну лицензию. В принципе подобное подозрение возникло почти сразу после релиза vSphere 5. Я знаю, что буквально через пару дней после того как в VMware поняли, что просчитались, они начали масштабный опрос клиентов по соотношению физической памяти на хостах, количества виртуальных машин и назначенной им vRAM. На сегодня это как бы слухи, но уже подтвержденные из авторитетных источников и я им лично доверяю. Итак, что у нас уже известно:

Сегодня мне хотелось бы немного отвлечься от vSphere 5 лихорадки и вспомнить основы стандартного vSwitch-а, а в частности каким образом он обходится без Spanning Tree Protocol.

Я предполагаю, что вы уже обладаете простейшими знаниями коммутации и знаете что такое vlan, switching loop, spanning tree протокол и некоторые виды link aggregation протоколов. Я постараюсь кратко пробежаться по основным возможностям стандартного vSwitch-а, делая акцент на фактах, которые показались мне интересными или же которые были не очень очевидны в официальной документации, по крайней мере для меня. Отсюда же вытекает и некоторая сумбурность нижеизложенного.

Основная цель стандартного vSwitch-а (или же vNetworking Standard Switch aka vSS) — это обеспечение связи между виртуальными машинами и физической сетевой инфраструктурой. В дополнение, он обеспечивает логическое разделение виртуальных машин используя Port Groups, предлагает различные алгоритмы балансирования в случае если у вас есть более чем один аплинк на одном ESXi хосте, обеспечивает шейпинг исходящего трафика от виртуальных машин к vSS, ну и наконец, позволяет обнаруживать сбой аплинка и автоматическое переключать трафик на оставшиеся аплинки.

В одном из комментариев к моему посту о новом функционале vSphere 5 коллега Omnimod скептически высказался о Virtual Storage Appliance (VSA). Мне, честно говоря, самому был очень интересен этот новый функционал и поэтому я решил убедиться насколько оправдан скептицизм более опытного товарища.

Итак, давайте коротко пройдемся по VSA.

Основной целью VSA является предоставление SMB компаниям полноценного функционала общедоступного NFS хранилища, используя локальные диски ESXi хостов. То есть используя VSA в удаленном офисе, при 2 -3 ESXi хостах вам не нужно будет покупать NAS или SAN.

Вот так выглядит VSA при установке на 3 хоста.

Недавно и я стал обладателем сервера HP ProLiant MicroServer N36L. То, что на нем будет стоять Citrix XenServer, было решено заранее, тем более положительный опыт установки на этот сервер имеет место быть. Задачу установки немного усложняло то, что я был в отпуске. Дома, кроме буков и пары мышек, больше компьютерной техники нет. А для установки хотелось бы иметь клавиатуру, которую можно было принести с работы, и монитор. Проблема с монитором решилась просто, на телевизоре оказался VGA-разъем, дома нашелся кабель для него. Решил попробовать установить XenServer в автоматическом режиме, наблюдая за установкой по телевизору. Так как на сервере отсутствует оптический привод, устанавливать будем с флэшки.

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

• На сегодняшний день 40% серверной нагрузки приходится на виртуальные сервера. В среднем в год наблюдается 10% рост виртуализации
• Основной темой первой части презентации было движение к облачной модели. Не важно будете ли вы строить частное облако только для нужд вашей компании, или же вы будете предоставлять облако внешним клиентм — вы все это можете легко сделать с помощью новых продуктов VMware. Клиенты должны легко и удобно выбирать виртуальные машины под свои нужды в точности так же, как люди покупают компьютер в онлайн магазине, имея возможность настроить покупку под свои требования. Вобщем, классическая модель IT as a Service.

Эта статья по логике должна была появиться первой, перед статьей про Transparent Page Sharing, так как это база, с которой должно начинаться погружение в управление ресурсами памяти в vSphere 4.1.

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

Начнем мы с самого основного элемента, который называется Memory Page. Ему дается следующее определение — непрерывный блок данных фиксированного размера, используемый для распределения памяти. Как правило размер страницы может быть 4 Кбайта (Small Page) или 2 Мбайта (Large Page). Каждому приложению ОС выделяет 2 Гбайта виртуальной памяти, которая принадлежит только этому приложению. Чтобы ОС могла знать какой странице физической памяти (Physical Address — PA) соответствует определенная страница виртуальной памяти (Virtual Address — VA) ОС ведет учет всех страниц памяти с помощью Page Table. Именно там хранятся все соответствия между VA и PA.

Я думаю, многие уже успели заглянуть и прочитать эту статью на английском в моем блоге, но для тех кому все таки комфортней читать на родном языке, нежели иностранном (как сказали бы на dirty.ru – на анти-монгольском), я перевожу очередную свою статью.

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

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