При администрировании Hyper-V иногда возникают нетипичные задачи, например, возникает необходимость получить возможность работать с COM-портами в виртуальных машинах Hyper-V Gen2. Хотя многие администраторы, работающие с такими графическими инструментами управления как Hyper-V Manager, Failover Cluster Manager, Virtual Machine Manager знают, что настройки COM-портов есть только свойствах виртуальных машин первого поколения.
-
Как добавить COM-порт в виртуальную машину Hyper-V Gen2
-
Развёртывание и настройка oVirt 4.0. Часть 12. Резервное копирование виртуальных машин
Продолжая тему резервного копирования, в этой части мы рассмотрим практический пример автоматизации регулярного резервного копирования виртуальных машин в кластере oVirt 4.0.4, а также посмотрим на процедуру восстановления виртуальной машины из резервной копии. Читать далее...
-
Развёртывание и настройка oVirt 4.0. Часть 5. Watchdog как средство повышения доступности гостевых систем виртуальных машин
Продолжая тему возможностей обеспечения высокой доступности (High Availability) в oVirt 4.0 нельзя упустить из виду такой функционал, как поддержка виртуальных устройств Watchdog. В этой заметке мы рассмотрим практический пример настройки Watchdog-устройства в виртуальной машине с гостевой ОС Ubuntu Linux 16.04 LTS.
-
Развёртывание и настройка oVirt 4.0. Часть 4. Fencing как средство повышения доступности хостов и виртуальных машин
В это части мы рассмотрим механизмы Fencing, с помощью которых повышается уровень доступности как самих хостов виртуализации, так и выполняемых на этих хостах виртуальных машин в oVirt 4.0. Подробно о принципах и последовательности работы механизмов Fencing в oVirt можно почитать в документе Automatic Fencing. Здесь же мы поговорим об этих механизмах обзорно и рассмотрим несколько практических примеров.
-
Развёртывание и настройка oVirt 4.0. Часть 3. Базовые операции в oVirt
В этой заметке мы рассмотрим некоторые базовые приёмы работы с oVirt 4.0 в конфигурации Hosted Engine, то есть основные действия, которые может потребоваться выполнить администратору после развёртывания oVirt. Чтобы начать работу с oVirt, нужно хотя бы на базовом уровне понимать значение компонент инфраструктуры этого продукта. Довольно простым и доступным языком описал основные компоненты oVirt Александр Руденко в своём блоге: oVirt часть 4. Настройка инфраструктуры. Рекомендую к предварительному прочтению.
-
Повышаем доступность прокси-сервера Squid с помощью UCARP с балансировкой нагрузки между двумя виртуальными серверами на базе Ubuntu Server 14.04.2
Несмотря на довольно стабильную работу прокси-сервера Squid в средах с большим количеством пользователей, может возникнуть желание повышения уровня доступности такого важного на сегодняшний день информационного ресурса, как доступ в Интернет для конечных пользователей. В этой заметке будет рассмотрен пример настройки двух прокси-серверов Squid для повышения доступности с параллельным распределением нагрузки между этими серверами.
-
System Center 2012 R2 DPM - Невозможность защиты виртуальных машин на одном из узлов кластера Hyper-V - Ошибки ID 53 : Not implemented (0x80000001) и ID 104 : Access is denied (0x80070005)
Добавляем дополнительный хост виртуализации в действующий кластер Hyper-V на базе Windows Server 2012 R2 с использованием общих томов Cluster Shared Volume (CSV). Устанавливаем на новый узел кластера агента System Center 2012 R2 DPM CU5 и пытаемся выполнить резервное копирование виртуальных машин из кластера. При этом возникает интересная проблема – резервное копирование виртуальных машин успешно выполняется только в том случае, если они расположены на уже существующих ранее в DPM узлах кластера, а если переместить любую виртуальную машину на новый узел кластера, то в процессе создания резервной копии сначала возникает ошибка…
-
После миграции между хостами в кластере Hyper-V на виртуальной машине HP 3PAR Virtual Service Processor 4.3.0 перестала работать сеть.
После одной из миграций (методом Live Migration) виртуальной машины HP 3PAR Virtual Service Processor (VSP) 4.3.0 между хостами кластера Hyper-V получил от SCOM оповещение о сетевой недоступности ОС внутри ВМ. После перезагрузки виртуальной машины, зайдя на консоль, обнаружил внимание на то, что интерфейсы поменяли своё название и настройки IP в системе не выполнены…
Оказалось что, в системе произошло переименование интерфейсов: интерфейс eth0 стал eth3 (интерфейс без подключения к сети на уровне настроек виртуальной машины), а интерфейс eth1 стал eth2 (основной интерфейс подключения к локальной сети).