Собрание заметок об информационных технологиях
В прошлый раз мы пошагово рассмотрели пример миграции виртуальной машины с гостевой ОС Linux Debian 8 c платформы виртуализации oVirt на платформу Hyper-V. При этом мы провели MBR –> GPT конвертацию диска ВМ для возможности запуска в формате Hyper-V Gen2 с загрузчиком UEFI. В этой заметке мы в более сжатом виде рассмотрим пример аналогичной миграции, но уже для виртуальной машины с ПО Avaya IP Office Server на базе CentOS 6 с учётом нюансов, относящихся к данной ОС.
Когда-то мы уже рассматривали вариант организации дедуплицированного хранилища резервных копий виртуальных машин oVirt с помощью ПО QUADStor Storage Virtualization на CentOS Linux 7.2. Со временем описанная в той заметке конфигурация была переведена на ОС Debian GNU/Linux 9 и так работала до тех пор, пока нас не стало напрягать время остановки и запуска службы QUADStor тогда, когда требовалась перезагрузка хоста. Было решено попробовать возможности дедупликации Virtual Data Optimizer (VDO) в составе CentOS Linux 7 в качестве альтернативы дедупликации от QUADStor. В этой заметке мы и рассмотрим базовые теоретические моменты использования VDO с практическим примером применительно к нашей задаче резервного копирования виртуальных машин.
Базовая процедура миграции виртуальной машины из среды виртуализации oVirt в среду Hyper-V была рассмотрена ранее в статье Миграция виртуальной машины oVirt 4.2 на Hyper-V (конвертация в VHDX). То есть сначала виртуальная машина экспортируется из oVirt в качестве контейнера OVA, затем файл *.ova распаковывается и вложенный в него RAW-диск с помощью утилиты qemu-img конвертируется в формат VHDX. Запуск виртуальной машины Hyper-V с полученным в результате миграции VHDX-диском не представляет сложностей в том случае, если ВМ была создана в формате Hyper-V Gen1. Проблема может возникнуть, если мы захотим без предварительных манипуляций создать на основе полученного диска виртуальную машину Hyper-V Gen2. Далее мы рассмотрим такую ситуацию с вариантом решения поставленной задачи, опирающимся на статью Jens Getreu - Switch Debian from legacy to UEFI boot mode. Читать далее...
В одной из прошлых статьей мы рассматривали процедуру миграции виртуальной машины oVirt в среду Hyper-V. Теперь подвернулся случай описать процесс обратной миграции, то есть когда виртуальную машину Hyper-V необходимо перенести в среду виртуализации oVirt.
На самом деле исходная ситуация в нашем случае заключалась в том, что нужно было развернуть новый виртуальный сервер именно в среде Hyper-V, так как поставляемый под эту задачу сконфигурированный компанией Avaya образ виртуальной машины (Virtual Appliance для управления IP АТС) поставлялся в виде образа диска VHDX. Однако немного "покрутив" этот образ, стало понятно, что здесь есть несколько проблем. Во-первых, оказалось, что внутри виртуального диска была "поселена" гостевая ОС Linux на базе CentOS 6 с древним ядром Linux версии 2.6. При этом в гостевой ОС не было никакого намёка на компоненты интеграции Hyper-V, которые, как минимум, позволили бы вменяемо управлять отключением ВМ с хоста и использовать "горячее" резервное копирование ВМ такими средствами, как System Center DPM, без опасения за то, что очередная "заморозка" системы может привести к проблемам с ПО в гостевой ОС. Во-вторых, учитывая "престарелость" гостевой ОС стало очевидно, что нет никаких шансов запустить виртуальный диск на ВМ второго поколения (Hyper-V Gen2), и придётся "прозябать" на старом тормозном виртуальном IDE контроллере "со всеми вытекающими". Такое положение вещей мне, мягко говоря, не понравилось, и было решено завести эту виртуальную машину на более дружелюбный для её гостевой ОС системе управления виртуализацией - oVirt. Соответственно встал вопрос миграции имеющегося VHDX диска в форматы, совместимые с oVirt. Читать далее...
Случилось так, что в кластере oVirt 4.2.5 сломалась возможность передачи роли Storage Pool Manager (SPM) с одного хоста на другой. Как позже выяснилось, истинная причина этой проблемы заключалась в том, что на хранилище виртуальных машин Data Domain возникла проблема с неудалённым "осиротевшим" диском в LVM-группе, с которой работает oVirt. Однако данная ключевая проблема привела к другой сложности - невозможности передачи роли SPM между хостами.
Последний опыт общения с технической поддержкой HPE относительно проблемы работоспособности виртуальной машины c ПО 3PAR Virtual Service Processor (VSP) выявил интересный факт. В один прекрасный момент наш виртуальный сервер VSP перестал отправлять информацию о состоянии СХД 3PAR на серверы сбора логов на стороне HPE. При этом тесты на проверку подключения к серверам HPE из веб-интерфейса VSP (SPOCC) проходили успешно. Диагностика проблемы инженером поддержки 3PAR показала, что отсылка файлов ломается на этапе проверки информации о платформе виртуализации VSP. Наша виртуальная машина была развёрнута на oVirt, и, как я понял, сервер сбора HPE с какого-то момента времени стал считать это криминалом.
Обновление нашей инфраструктуры oVirt до последней версии 4.2.0 в целом прошло гладко по ранее описанному сценарию. После обновления сервера управления oVirt Hosted Engine, обновления всех хостов виртуализации и повышения уровня кластера до новой версии, настала очередь обновления пакета интеграции oVirt Guest Agent в гостевых ОС виртуальных машин. Об этом нам ненавязчиво сообщила уже обновлённая и "приятная на ощупь" консоль Administration Portal, показав неприятный восклицательный знак возле каждой необновлённой ВМ.
Ранее мы уже рассматривали пример обновления oVirt Hosted Engine между релизами в рамках версии 4.0, который в своей основе применим и к данному обновлению. Однако в случае обновления версии oVirt 4.0.6 на 4.1.0 имеются некоторые свои особенности, которые я постараюсь описать на практическом примере с имеющейся у меня инфраструктурой oVirt.
Рассмотрим пример организации выделенной сети тонких клиентов, подключающихся по протоколу RDP к центральному серверу служб удалённых рабочих столов Microsoft Windows Server (Remote Desktop Services). В качестве ОС тонкого клиента будем использовать свободно распространяемую среду Thinstation из проекта Thinstation by Donald A. Cupp Jr., в составе которой присутствует RDP-клиент FreeRDP. Читать далее...
В Марте этого года было объявлено о доступности Zen Load Balancer Community Edition 3.10, где была добавлена поддержка Debian Jessie, удалена поддержка профилей GSLB и TCP (вместо этого предлагается использовать L4xNAT), исправлены некоторые ошибки. Полный список изменений можно посмотреть в Changelog. Однако не узрев для себя существенных изменений, мы решили не связываться с обновлением ранее описанного форка ZenLB, адаптированного под 64-битную OC Ubuntu Server 14.04. Читать далее...
Спасибо, помогло!
Всё так и есть. На гитхабе пакеты для новых версий 3.0.18 и 3.0.19 выложены, но в репозиторий "https://repo.openbytes.ie/patchman/debian bookworm main"…
RSS - Записи
Последние комментарии