Looking Glass на домашнем компьютере разработчика

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

Разработчик по имени Джеффри МакРэй (gnif) не готов с этим мириться — и поэтому вместе с несколькими единомышленниками несколько лет назад создал приложение Looking Glass для запуска Windows VM под Linux в окне с нативной производительностью. 17 июля 2021 года вышла четвёртая стабильная версия хоста (B4). Если вкратце, Looking Glass позволяет использовать KVM (Kernel-based Virtual Machine), настроенный на сквозной проход сигнала VGA PCI (GPU passthrough) без подключённого физического монитора, клавиатуры или мыши.

По мотивам Роутим IPv4 и IPv6 в KVM на примере Hetzner решил описать свой howto по созданию и организации виртуальных машин.

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

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

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

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

Приветствую вас, Хабражители!

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

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



Помните 7 шагов?

Данная статья — это обобщение информации, накопленной за время использования гипервизора Qemu-KVM. Я хочу поделиться теми знаниями опытом, которыми обладаю на данный момент. Надеюсь, что моя статья пойдет на пользу тем, кто только собирается использовать гипервизор Qemu-KVM или уже использует. И еще: статья не для новичков linux (элементарные вещи здесь рассматриваться не будут).

Про данную систему виртуализации в сети написано много. Но когда действительно начинаешь с ней работать — сталкиваешься с нехваткой информации и практических примеров применения. Итак приступим.

Входящая задача. Был выделен компьютер как тестовая станция – для проверки работоспособности резервных копий баз данных, устанавливаемого программного обеспечения, сборки msi пакетов и прочих весьма разнообразных задач. Конфигурация компьютера:

• процессор Atlon X2 245
• оперативная память 4 гигабайта
• жесткий диск 500 гигабайт
• материнская плата ASUS M4N68T-M LE.

В данной статье рассматривается идея и практическое руководство по создания многопользовательской рабочей станции (multiseat) с использованием виртуализации KVM, с возможностью удаленного управления через libvirt. С помощью этого руководства возможно создать два и более рабочих мест как в офисе, так и дома, которым может потребоваться возможность полного использования графической подсистемы компьютера. Причем можно на одном системном блоке реализовать одновременно работу различных операционных систем Windows, Linux, Mac OS X, остальное по вкусу.

На работе мы активно используем виртуализацию на базе qemu/kvm через libvirt. Сам я давно пересел на linux и также использую qemu/kvm на своей локальной машине, при этом, часто применяю графический virt-manager для настройки различных параметров ВМ. Хотелось использовать его и для управления гипервизорами на удаленных серверах. О том как это сделать и будет статья в виде пошаговой инструкции(по факту это перевод и «сведение в едино» официальной документации).

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

• При монтировании диска нужно помнить, что монтируется не само блочное устройство, а раздел на нем. Проблема усугубляется если используется lvm-диск — ядро не видит разделы на нем без применения средств убеждения в виде kpartx.
• Для восстановления раздела требуется не только резервная копия файловой системы, но и бубен/копия первого трека.
• Изменение размера такого диска требует еще одного бубна лишней операции по изменению размера раздела на диске

Избавиться от таблицы разделов можно прямой загрузкой ядра, но этот метод не безгрешен. Гипервизор должен иметь на своей стороне образы ядер виртуальных машин, которые нужно поддерживать актуальными при обновлениях гостевых ОС.
Хочу рассказать вам об альтернативном варианте загрузки с диска без разделов с помощью EFI и GRUB2.

В данной статье для виртуализации используется KVM/libvirt, но сразу отмечу, статья не столько о KVM, сколько именно об особенностях преимуществах использования Open vSwitch для объединения виртуальных и физических сетевых устройств посредством технологии VLAN (802.1q). В былинные времена для проброса тегированного трафика в гипервизор использовались всевозможные костыли и подпорки различной степени неожиданности (tuntap, brctl, vconfig, ebtables и прочее), что приводило к захламлению операционной системы, хостящей гипервизор, большим количеством ненужных виртуальных сетевых интерфейсов, мозолящих глаза в выводе ifconfig и вообще огорчало администраторов необходимостью строить стандартное сетевое устройство (коммутатор) из отдельных частей как какой-то велосипед. Помимо поддержки 802.1q от коммутатора на самом деле сегодня требуется еще много функций. Так необходимость в виртуальном устройстве максимально соответствующем по функционалу стандартному современному управляемому коммутатору привела к появлению проекта Open vSwitch (далее — OVS).

Рисунок 1: Проект песочницы

Конфигурация.

Сервер виртуальных машин на GNU/Linux. Виртуальные машины Windows. Гипервизор QEMU-KVM.
Виртуальные машины запускаются автоматически.

Описание проблемы.

Для двух программ есть два электронных (лицензионных) ключа Guardant одной модели (у них одинаковые Vendor ID и Product ID). Чтобы не возникал конфликт, в libvirt в описании виртуальной машины такие ключи добавляются с указанием аппаратного адреса (bus, device). После перезагрузки может оказаться так, что номера устройств будут другие. А если переключить их в другой порт, то и номер шины может стать другим.

В этом howto мы с вами просто и быстро, шаг за шагом, запустим гипервизор Qemu-KVM в debian 8.



Будем запускать виртуальную машину в qemu-kvm от пользователя username, используя spice, qxl и virtio.
Предполагается, что установлен Debian 8 amd64, с выбранными в tasksel стандартными утилитами и SSH сервером. Доустановим.

aptitude install -y firmware-linux bridge-utils etckeeper

Продолжая тему, описанную здесь habrahabr.ru/post/252973, опять пишу про увеличение дисков виртуальных машин.
Конфигурация следующая:
Гипервизор сервер Supermicro с KVM и libvirt на Ubuntu.
Гости — Ubuntu с LVM2.
Задача:
Увеличить размер системного дисков без выключения/перезагрузки гостевой ОС.

В комментариях к предыдущей статье habrahabr.ru/post/252973/#comment_8330673 farcaller написал:

Системный тоже можно на лету отресайзить. Для этого в libvirt есть команда:
virsh qemu-monitor-command resized-virtual-machine --hmp «block_resize $DRIVENAME $NEWSIZE»

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

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

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

• Ubuntu
• Debian
• CentOS 6/7 + atomic
• Fedora + atomic
• CoreOS

Частично:

• FreeBSD (требуется ручная настройка сети и ssh ключей)
• openSUSE (требуется ручная настройка сети и ssh ключей)
• Windows (в консоль не попадёшь, но при помощи virt-manager можно пользоваться графическим интерфейсом)

Публикации поспособствовал коллега, который случайно увидел, как я тестирую код. А теперь о преимуществах перед Vagrant. Первое преимущество — время. Например, три виртуальные машины создаются всего за 20-30 секунд.

Как обычно — обстоятельства диктуют правила. На этот раз мы ставим Proxmox и Libvirt на один тот же сервер.


Столкнулись с очередной задачей — заказчик поставил условие развернуть стенд на уже имеющейся, конфликтующей инфраструктуре. У него кластер Proxmox, у нас Libvirt

Решение в лоб — не помогло, попытка установить libvirtd потребовала удаления proxmox. Не долго думая решили скреативить. Смотрите под катом элегантное решение как и на ёлку залезть и ничего не ободрать.

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

В целом, в связи с более широкими требованиями к систем визуального анализа информации и потребностями в части интеграции с источниками данных стали распространяться специализированные решения для ad-hoc анализа данных, такие как Kibana, Grafana и иные. Данные системы могут интегрироваться со специализированными хранилищами временных рядов данных, одним из которых является InfluxDB. Статья расскажет о готовом решении, распространяемом в виде образа Docker, использующем LibVirt API, Grafana и InfluxDB, предназначенном для сбора и анализа параметров исполняющихся VM для гипервизора KVM.

Привет, Хабр! Меня зовут Дмитрий, я разработчик в ISPsystem. Недавно мы выпустили в бета-тестирование новую версию панели управления виртуальными машинами. Сегодня я расскажу, как мы решали, что взять из старого продукта, а от чего лучше отказаться. Пройдусь по самым важным для нас вопросам: библиотека для работы с libvirt, поддержка различных ОС при установке продукта, переход от монолита к микросервисам, развёртывание виртуальных машин.

В статье речь идёт о VMmanager. Это система управления, развёртывания и мониторинга виртуальных машин на основе виртуализации KVM и OVZ. Пятое поколение вышло в 2012 году. С тех пор интерфейс сильно устарел, а централизованная архитектура мешала развивать продукт. Пришло время делать новую версию.

8 октября вышла коробочная версия VMmanager 6 — новой панели управления виртуализацией. Теперь её можно установить на сервер и использовать для продажи виртуальных машин или управления собственной инфраструктурой. В этой статье сравним новое поколение с предыдущим — VMmanager 5 и VMmanager 6.

Обе панели поддерживают виртуализацию KVM и управляют физическим сервером средствами libvirt.

VMmanager 5 вышел в 2013 году, VMmanager 6 — в 2019-м. Новое поколение удобнее и устойчивее к нагрузкам. Поддерживает создание образов, управление задачами и мониторинг.

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

Эта статья посвящена автоматизации системного (end-to-end) тестирования с использованием виртуальных машин. В статье рассматриваются такие вопросы, как автоматизация развертывания и настройки виртуальных стендов, а также автоматизация запуска процессов внутри виртуальных машин с последующим контролем полученных результатов. В конце статьи мы получим пусть неидеальный (к этому мы ещё вернемся), но простой и понятный скрипт, с помощью которого вы сможете запускать системные тесты одной кнопкой, даже не имея у себя на компьютере ни одной виртуальной машины.

Статья предполагает наличие следующих навыков у читателя:

• Уверенное пользование ОС семейства Linux;
• Базовое понимание принципов виртуализации;
• Знакомство с гипервизором QEMU и графическим клиентом virt-manager

Статья разбита на две части: в первой части мы познакомимся с основными инструментами, которые позволят нам создавать, развертывать и управлять виртуальными машинами используя исключительно командную строку. Эти знания нам пригодятся для второй части статьи (которую можно найти здесь: https://habr.com/ru/post/520648/), где мы соединим эти инструменты вместе и попробуем автоматизировать тесты конкретного сетевого приложения.

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

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