Базовая процедура миграции виртуальной машины из среды виртуализации 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. Читать далее...
-
Миграция виртуальной машины c Linux Debian 8 из среды oVirt в Hyper-V Gen2 с конвертацией диска из формата загрузчика Legacy BIOS (таблица разделов MBR) в формат UEFI (таблица разделов GPT)
-
Ошибка "Windows could not complete the installation. To install Windows on this computer restart the installation" при запуске клонированной виртуальной машины Hyper-V с Windows Server 2012 R2
Это первая часть очередной истории о том, как можно наступить на грабли, там, где обычно этого не ожидаешь. Началось всё с того, что для очередного развёртывания нескольких однотипных виртуальных машин Hyper-V с гостевой ОС Windows Server 2012 R2 был подготовлен эталонный образ виртуального диска с установленной ОС. В эталонный образ были включены все актуальные обновления, после чего для уменьшения размера диска был применён метод очистки хранилища компонент Windows в каталоге WinSxS, а логический том системного диска по своему объему был усечён таким образом, что на нём оставалось около 5GB свободного пространства. Перед отключением ВМ в эталонной гостевой ОС по законам жанра была выполнена утилита sysprep. В дальнейшем с этого образа было успешно развёрнуто несколько ВМ, имеющих конфигурацию ВМ, сопоставимую с эталонной ВМ. Спустя некоторое время после всей этой истории с пониманием того, что ранее несколько развёртываний с образа прошли успешно, была предпринята попытка развернуть ещё пару ВМ с этого же образа. -
Миграция виртуальной машины Hyper-V на oVirt 4.2.6 (конвертация VHDX в RAW)
В одной из прошлых статьей мы рассматривали процедуру миграции виртуальной машины 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. Читать далее...
-
Обновления от Vembu : BDR Suite v3.9.1 Update 1 & BDR Essentials
Наш партнёр, компания Vembu Technologies, недавно представила новое решение по защите данных для сегмента малого бизнеса - Vembu BDR Essentials. Данный продукт является привлекательным с финансовой точки зрения решением в области Backup & Disaster Recovery, представляя ощутимую экономию, - до 50% по сравнению со стоимостью лицензирования своего "большого брата" - Vembu BDR Suite, некоторые особенности которого мы рассмотрели в прошлой заметке. Решение может быть интересно организациям с небольшой ИТ-инфраструктурой, где требуется защита сред виртуализации VMware и Hyper-V, имеющих до 6 процессорных сокетов или 50 виртуальных машин. Подробнее о решении можно узнать в официальном анонсе: Introducing Vembu BDR Essentials for Small Businesses.Загрузить бесплатную полнофункциональную версию с ограниченным ознакомительным периодом работы можно по ссылке: Vembu BDR Essentials
Также компания Vembu напоминает о том, что в недавнем времени было выпущено обновление Vembu BDR Suite v3.9.1 Update 1, которое расширяет возможности защиты сред виртуализации VMware, представляя поддержку vSphere 6.7: Know how Vembu offers support for vSphere 6.7 with Enterprise-level features
-
Vembu BDR Suite Free Edition для резервного копирования виртуальных машин Hyper-V
В этой статье мы рассмотрим базовое развёртывание и некоторые нюансы использования продукта для резервного копирования виртуальных машин VMware и Hyper-V - Vembu BDR Suite. Данное ПО поставляется в трёх редакциях - Free, Standard и Enterprise. Сравнение возможностей этих редакций можно найти в документе Vembu BDR Suite Edition Comparison. В рамках данной статьи мы воспользуемся Free редакцией продукта для настройки резервного копирования пары виртуальных машин на выделенном хосте виртуализации Hyper-V на базе ОС Windows Server 2012 R2. -
Ошибка "There is not enough space available on the disk(s) to complete this operation" при попытке выполнить сжатие дискового тома NTFS на хосте виртуализации Hyper-V с Windows Server 2012 R2
Работа с операционной системой Windows Server не бывает скучной, так как, порой, можно получить сюрприз с загадкой в самом неожиданном месте. Казалось бы, что можно ожидать от привычной функции, которую уже приходилось использовать десятки раз. С таким, абсолютно невозмутимым настроем, на одном из хостов виртуализации Hyper-V на базе Windows Server 2012 R2 я решил выполнить сжатие дискового тома NTFS (Shrink Volume) с ОС, чтобы освободить немного места на конце диска. -
Миграция виртуальной машины oVirt 4.2 на Hyper-V (конвертация в VHDX)
Последний опыт общения с технической поддержкой HPE относительно проблемы работоспособности виртуальной машины c ПО 3PAR Virtual Service Processor (VSP) выявил интересный факт. В один прекрасный момент наш виртуальный сервер VSP перестал отправлять информацию о состоянии СХД 3PAR на серверы сбора логов на стороне HPE. При этом тесты на проверку подключения к серверам HPE из веб-интерфейса VSP (SPOCC) проходили успешно. Диагностика проблемы инженером поддержки 3PAR показала, что отсылка файлов ломается на этапе проверки информации о платформе виртуализации VSP. Наша виртуальная машина была развёрнута на oVirt, и, как я понял, сервер сбора HPE с какого-то момента времени стал считать это криминалом. -
Ошибка проверки подлинности при подключении к удалённому рабочему столу Windows RDS …"Причиной ошибки может быть исправление шифрования CredSSP"
Информация об уязвимости в провайдере безопасности CredSSP ОС Windows была опубликована 13.03.2018 в документе CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability. В этом документе можно найти ссылки на обновления безопасности, которые были выпущены для закрытия этой уязвимости. Выпущенные обновления относятся к механизмам CredSSP, как в клиентских, так и в серверных ОС Windows. При этом неправильная последовательность развёртывания обновлений, касающихся CredSSP, может привести к неожиданным последствиям. -
ИТ Вестник №15.2018
Представляем вашему вниманию очередной небольшой обзорный материал об интересных, на наш взгляд, информационных обновлениях в ИТ-сфере за прошедший месяц, а также информацию об обновлениях нашего Вики-сайта. За помощь в подготовке выпуска благодарю Алексея Максимова. Также будем рады видеть Вас участниками групп https://vk.com/blogitkb и https://www.fb.com/blog.it.kb.Будьте в курсе актуальных новостей в мире ИТ: https://t.me/ITKBnews
-
Использование сервера с FC HBA QLogic на базе Debian GNU/Linux 9.3 и SCST в качестве СХД для томов CSV в кластере высоко-доступных виртуальных машин Hyper-V
Имеем удалённую площадку с одним хостом виртуализации на базе гипервизора Hyper-V (Windows Server 2012 R2) и пачкой виртуальных машин, запущенных на этом хосте. Всё работает, но есть желание хоть как-то повысить доступность виртуальных машин, так как в периоды обслуживания хоста возникает необходимость выключения всех ВМ, что в некоторых ситуациях приводит к нежелательным последствиям. Логичным решением здесь выступает построение, как минимум, двух-узлового кластера высоко-доступных виртуальных машин Hyper-V на базе Windows Failover Cluster. В таком кластере виртуальные машины должны размещаться на общем дисковом томе Cluster Shared Volumes (CSV), который должен быть доступен обоим хостам виртуализации. То есть, предполагается, что для построения кластера нам потребуется какое-то внешнее дисковое хранилище (СХД), к которому могут быть подключены хосты виртуализации. Однако в нашем случае СХД на удалённой площадке нет, но есть свободные серверы. В этой заметке мы рассмотрим пример того, как с помощью Debian GNU/Linux 9.3 и свободно-распространяемого ПО Generic SCSI Target Subsystem for Linux (SCST) из обычного сервера сделать СХД. В результате у нас появится возможность создать двух-узловой кластер высоко-доступных виртуальных машин Hyper-V с подключением к третьему серверу, который будет использоваться в качестве СХД для организации общего тома CSV.
Последние комментарии