Александр Кулишов

Дело в DPMS (Display Power Management Signaling), который отрубает монитор в целях энергосбережения.
Проверить его работу можно с помощью xset -q, вывод будет примерно такой:
DPMS (Energy Star):
Standby: 0 Suspend: 0 Off: 0
DPMS is Enabled
Monitor is On
Отключить ее можно с помощью:
xset -dpms;xset s off
(собственно, отключить dpms и режим энергосбережения экрана)

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

Кластер из двух серверов не получится. Нужно минимум три -- один из серверов будет общим хранилищем для двух остальных. Это независимо от платформы виртуализации.

Что касается лицензий -- у VMware есть пакеты типа vSphere Essential, они стоят не так дорого, как если брать просто vSphere. Essential Plus покрывает три сервера и один vCenter, стоит около 250-300 тысяч рублей.

Но один сервер под общим хранилищем -- этого мало, так как он становится единой точка отказа (сдохнет -- и полягут ВСЕ виртуалки). Поэтому самым правильным вариантом решения будет конвергентная инфраструктура -- когда сервера виртуализации также презентуют свои локальные диски в какой-то из вариантов software defined storage. Среди вариантов: Ceph (бесплатный, но капризен, и для поддержки нужны нефиговые такие скиллы), VMware vSAN (стоит нефигово) или ScaleIO (тоже стоит порядком, но до 12 Тб сырого места можно юзать совсем бесплатно. В варианте из трёх узлов в кластере ScaleIO 12 Тб сырого места -- это 4 Тб полезного места. При росте числа узлов оверхед будет снижаться. Например, 12 Тб сырого места на 5 серверах уже обеспечит 5 Тб полезного места).

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

Ну и, собственно, игроков на рынке виртуализации не так уж чтобы до фига. Microsoft Hyper-V, VMware ESXi, KVM. Proxmox -- это не вполне система виртуализации, это оркестратор для управления виртуальной инфраструктурой. Непосредственно виртуализацией занимается всё равно KVM (или LXC, но это вам не нужно).

начнем с того, что изначально не советуется запускать что-либо под рутом. если нужно запустить - используем судо дабы все логировалось и контроллировалось. просто примите это на веру т.к. этот постулат выплакан кровавыми слезами не одной тысячи сисадминов

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

у меня сложилось впечатление, что контейнеризация сервисов для Вас является серебряной пулей безопасности. к примеру, есть хостинг и на нем есть дырявые сайты, которые чуть ли не каждый день хакают и через них сливают данные с других сайтов т.к. не проставлен open_basedir и все работает под апачем без разделения через SuID или без mpm-itk. и тут Вы познакомились з контейнеризацией и теперь запустили каждый сайт в своем личном окружении и все чики-пики с безопасностью. пример надуманый мною и не факт, что оно так у Вас на самом деле, но суть не в том

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

вот с чем я сталкивался лично и что мне просто не давало жить. представим, что Вы создали сервис, который дополнительно еще генерирует какие-то файлы. файлы хранится в некоторой папочке в `/foo/bar/beez_service`, но Вы в эту папку монтируете другую папку хост-машины. Ваш сервис запущен от рута. Ваш сервис пишет лог и все эти файлы генерируются с правами рута и с неким chmod-ом, который был указана через umask или еще как-то. обычно над этим не заморачиваются и файлы имеют chmod 0664 - обычным пользователем удалить его невозможно. это как минимум неудобно. я понимаю, Вы можете ответить, что монтировать папки не всегда нужно, что можно использовать `sudo` на хост-машине, что не особо нужно удалять файлы через хост-машину и так далее

эту проблему сможет решить два микротика с обеих сторон.

У меня есть мысль адаптировать курс MTCNA под самостоятельное обучение и на бесплатной основе, только есть вопросы в какой манере его подать и какие темы затронуть. или вообще сделать в виде видео

Понемногу накапливается мануал на Debian.pro - то, что уже есть, написано очень живо и по делу.

NUT - www.networkupstools.org
Apcupsd - www.apcupsd.org

Оба есть под винду, статус можно получить через консольную утилиту и его распарсить.
Едиственное но - у совсем новых APC другой закрытый протокол, они не поддерживаются.
У NUT для вашего упса драйвер называется usbhid-ups.

У тебя, скорее всего, разные пакеты wireles. Ну и обновить до последней версии ОС не мешало бы.