Tuesday, August 29, 2017

Сменить динамический ip-адрес на статический в SCVMM на работающей VM


Задать тип IP адреса (динамика или статика) можно при создании VM. Но если потребовалось изменить этот тип уже после создания, то можно сделать это через powershell. Здесь мы меняем тип для первого сетевого интерфейса. (Google помог по запросу scvmm change to static ip powershell )

$vm = Get-ScvirtualMachine -Name "имя нашей VM"
$staticIPPool = Get-SCStaticIPAddressPool -Name "имя нашего пула статических адресов"

Grant-SCIPAddress -GrantToObjectType "VirtualNetworkAdapter" -GrantToObjectID $vm.VirtualNetworkAdapters[0].ID -StaticIPAddressPool $staticIPPool

Set-SCVirtualNetworkAdapter -VirtualNetworkAdapter $vm.VirtualNetworkAdapters[0] -IPv4AddressType static

Испробовал - работает. Если машина включена и управляется агентом, то и адрес меняет в VM. Пробовал на Win, на Lin VM так делал, но IP внутри VM менял руками. 

Tuesday, August 1, 2017

Уcтановка сервера терминалов совместно с контроллером домена 2008 R2

Конфигурация в которой Domain Controller установлен совместно с Terminal Server является официально не поддерживаемой и не рекомендуемой. В 2008 R2 выводится лишь предупреждение об этом, а начиная с 2012 wizard просто откажется совмещать роли.
В большинстве случаев сейчас можно использовать виртуализацию для разнесения ролей по разным ОС если не хватает физических серверов. Возникает правда вопрос - "яйцо или курица?". То есть что сделать хостом, а что виртуалкой, но в целом проблема решается. При условии что лицензия Windows Server Standard уже давно дает возможность запуска двух виртуалок, это решение логично.
Но иногда, если нельзя, но очень хочется, то можно. Например в одной организации физический сервер стар и дохл, и явно не потянет две ОС.

Одна из проблем возникающих при совмещении ролей AD DC и TS это проблема с печатью при помощи easy print.

Принтеры пробрасываются с помощью easy print, видны как перенаправленные, но не печатают. Точнее задания на печать уходят в никуда. Можно всем пользователям раздать права администраторов домена ), но это плохой вариант. Куда лучше прописать права командами.

Запускаем командную строку с правами администратора, переходим в папку Windows\System32\Spool и запускаем:

Cacls.exe PRINTERS /e /g users:C
либо
Cacls.exe PRINTERS /e /g пользователи:C

решение было найдено здесь - http://searchvirtualdesktop.techtarget.com/tip/Five-reasons-printer-redirection-causes-Windows-printing-problems-in-RDS

Saturday, December 3, 2016

Типовые проблемы при разворачивании службы удаленных рабочих столов на 2012 R2


При разворачивании минимальной конфигурации RDS на скорую руку, в очередной раз сталкиваюсь с проблемами и в очередной раз забываю как их решать. Первое что нужно сделать перед развертыванием это конечно прочитать best practices, а потом составить план. Выписать все что необходимо заранее, подготовить, запросить. 

Например сертификат SSL и доменное имя типа remote.mycompany.ru (DNS запись A).  Даже развертывая очень маленький терминальный сервер для очень маленькой компании имеет смысл прикупить SSL если планируется доступ из сети интернет. Сегодня удаленный доступ нужен только с одного ноутбука, а завтра потребуется еще на десятке смартфонов. Замучаешься устанавливать везде свой локальный сертификат в корневые. Тем более что SSL сертификат сейчас стоит копейки. Я последнее время беру на https://www.ssls.com/ , с кодом 3.88DEAL  вообще копейки. И оплатить можно даже биткойнами. Проще всего запрос сертификата сделать установив на сервер роль IIS, тем более что он все равно потребуется для развертывания шлюза. В IIS есть раздел SSL, там визарды для создания запроса сертификата и для его установки (есть смысл запрашивать сертификат минимум 2048 bit ).
Часто сервер физически один, а службы удаленного доступа хотят иметь в своем составе шлюз, сервер лицензирования, сам терминальный сервер. Да и домен в ряде случаев не поднят. Технически возможна установка RDS на сервер в рабочей группе, но если есть возможность, можно сразу поднять контроллер домена. Если был куплен Windows Server Standard и выше, то его можно установить в двух экземплярах в виде виртуалок на одном физическом хосте. Если есть возможность - почему не использовать? Например DC аппаратный хост, а RDS на нем в Hyper-v. Или наоборот. Да DC в одном экземпляре, да еще и виртуальном, но ведь у нас нет 100500 ПК в этом домене. Всего один сервер и нужно просто иметь логины и пароли локальных админов.
В случае развертывания RDS в малом бизнесе очень часто IP адрес внешний один и нет возможности или желания докупать еще. В итоге создается конкуренция между внутренними сервисами за порты на этом IP. HTTP и HTTPS часто заняты другими ресурсами, и это создает массу проблем при развертывании RDS Gateway. Приходится переносить на другие порты, ручками местами прописывать потом эти порты.
Например, вместо 80 ставим 81, а вместо 443 - 442. Теряется красота ссылок на ресурсы, вместо https://remote.mycompany.ru/rdweb получаем https://remote.mycompany.ru:442/rdweb . Кроме того, наживаем кучу проблем с прописыванием этих самых 442 в разных местах. Есть пара решений, нашел на Windowsitpro.com. В оснастке диспетчера служб удаленных рабочих столов можно указать порты. Кроме того, для RemoteApp нужно тоже прописать порт, иначе приложения будут ссылаться на стандартный 443. Можно отредактировать реестр, указав порт:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<farm>\DeploymentSettings, в нем ищем DeploymentRDPSettings и добавляем к gatewayhostname:s:remote.mycompany.ru:442 номер порта. Сделать это нужно до того как опубликовали приложения RemoteApp, в противном случае приложения придется распубликовать и опубликовать повторно. Можно не реестром, а через PowerShell:
Set-RDSessionCollectionConfiguration –CollectionName "Your Collection" -CustomRdpProperty "gatewayhostname:s:<GATEWAY.FQDN>:<442>" -ConnectionBroker <Your Connection Broker> 
Но у меня на эти часть команд PS ругался, считал что RDS не установлены на сервере.Часто возникает проблема с SSL и hostname. SSL мы получили вида remote.mycompany.ru, а сервер у нас что-то вроде rdsserver.mycompany.local . Поэтому при первых же подключениях можно получить как минимум предупреждение "Имя сервера отличается от имени указанного в сертификате". Это если мы конечно прописали сертификат везде где надо:

  • Привязки в IIS к порту 442 (можно и к 443)
  • В диспетчере серверов (Настройка развертывания служб удаленных рабочих столов)
  • В диспетчере шлюза удаленных рабочих столов ( у меня не прописался сам, пришлось ручками).



В некоторых случаях предупреждение можно просто игнорировать. На некоторых платформах игнорировать нельзя. 

Решить проблему можно либо командой:
Set-RDSessionCollectionConfiguration –CollectionName QuickSessionCollection -CustomRdpProperty “use redirection server name:i:1 `n alternate full address:s:remote.mycompany.ru”либо скриптом.
.\Set-RDPublishedName.ps1 "remote.mycompany.ru:442"
Скрипт у меня сразу не запустился, нашел ряд решений, например -
powershell.exe -noprofile -executionpolicy bypass -file .\Set-RDPublishedName.ps1
Я зачем-то еще настроил на DC DNS зону mycompany.ru, и в ней создал DNS запись A "remote.mycompany.ru", указывающую на внутренний адрес RDS сервера, но это скорее по привычке.
Все бы ничего, но как только мы решили проблему с несоответствием имени указанном в SSL сертификате и имени сервера к которому подключаемся, появляется другая проблема.
event 301:
Пользователь "mycompany\user" на клиентском компьютере "8.8.8.8" не соответствует требованиям политики авторизации ресурсов и не авторизован для подключения к ресурсу "remote.mycompany.ru". Произошла следующая ошибка: "23002".
Дело в том что по умолчанию создаются политики удаленного доступа для штатной ситуации. А мы уже подправили скриптом, реестром, имя сервера к которому ведется подключение. И в политиках ничего не написано про remote.mycompany.ru. Открываем диспетчер шлюза удаленных рабочих столов и правим политику - добавляем туда наш адрес remote.mycompany.ru.




Tuesday, September 6, 2016

CPU mining with CPUMiner-Multi on CentOS 7

All necessary steps for CPU mining with CPUMiner-Multi by Wolf and Lucas Jones miner on CentOS 7

It is really easy to do cryptonight (Bytecoin [BCN], Monero) after CentOS installed and has network access to internet.

SSH to your CentOS and run following commands:

yum install git automake gcc make curl-devel
cd ..
cd srv
git clone https://github.com/wolf9466/cpuminer-multi
cd cpuminer-multi
./autogen.sh
CFLAGS="-march=native" ./configure
make

Now you can start miner with:

./minerd -a cryptonight -o <stratum url> -u <username> -p <pasword>

Monday, March 14, 2016

python-telegram-bot и Google App Engine


Захотелось поднять бота Telegram, но сразу в среде не требующей много внимания и не на рабочих серверах. Поднимать для него отдельные виртуальные машины, или искать дополнительный хостинг тоже не очень хотелось. Решил остановиться на облачных ресурсах Heroku, Google App Engine, Amazon и т.д. Программист из меня никакой, поэтому настройка окружения заняла много времени. Остановился на GAE, поскольку на нем хоть что то запустилось сразу. 

В GAE сразу запустился простой бот - спасибо Yukuku за подробную инструкцию. Но сразу же захотелось использовать клавиатурные подсказки, еще какие то фичи, наиболее логичным было использовать https://github.com/python-telegram-bot/python-telegram-bot для разработки бота. И вот тут начались проблемы, поскольку для этого решения требуется множество различных библиотек, которые цепочкой завязаны друг на друга. Мне не помогло решение от S. Hwang - либо описание несколько устарело (там ссылка на видео инструкцию) либо у меня руки не оттуда растут. Собственно у меня получилось запустить простого эхо-бота скопировав все недостающие библиотеки в корень проекта.

Поскольку потратил много времени на решение задачи, опишу здесь примерно процедуру, вдруг еще какому нубу потребуется. Я решил эту задачу неграмотно, но это единственный способ как я смог это сделать.
1. Создание бота
2. Создание и настройка тестового проекта
3. Установка (копирование) всех недостающих библиотек
3.1. Вариант для ленивых
3.2. Полный вариант

1. Создание бота

Процесс создания бота неоднократно описан. Можно пройти до 17-го шага в этом описании или по моему переводу:
  • Обратитесь к боту @botfather https://telegram.me/botfather  с командой /newbot Убедитесь что говорите именно с нужным botfather, а не с пользователем с похожим ником.
  • @botfather ответит Alright, a new bot. How are we going to call it? Please choose a name for your bot.
  • Введите имя которое придумали (yournamebot)
  • @botfather ответит Good. Now let's choose a username for your bot. It must end in `bot`. Like this, for example: TetrisBot or tetris_bot.
  • Введите любое уникальное имя бота. В конце должно присутствовать "bot". (YourNameBot)
  • Done! Congratulations on your new bot. You will find it at telegram.me/YourNameBot. You can now add a description, about section and profile picture for your bot, see /help for a list of commands.  Use this token to access the HTTP API: 201682768:AAE9p_yr7I7Hx_alotofsybols  For a description of the Bot API, see this page: https://core.telegram.org/bots/api
  • Выпишите себе тот API key что получили.

2. Создание и настройка тестового проекта 

  • Желательно чтобы project name и project id совпадали (меньше путаницы)
  • Сразу можно скачать и установить Google App Engine SDK , а можно и не скачивать. Можно скачать PyCharm версию про (для начала триальную).  Одно другому не мешает. Для простоты поднятия тестового бота Вы можете просто скачать все библиотеки в этом архиве

3.1.  Установка из моего архива.

Если Вы решили просто скопировать файлы из архива (предупреждаю - библиотеки часто обновляются, версии в архиве скорее всего устарели, ну и там много лишнего):
  • распакуйте архив.
  • Измените файл app.yaml - application: yourbotname - укажите имя своего проекта в GAE.
  • Измените файл main.py - PasteYourTokenHere и PasteYourGAEProjectNameHere, укажите token полученный от  @botfather и имя проекта в GAE.
  • Запустите Google App Engine SDK
  • Add Existing Application
  • Проект появится в списке проектов
  • Запустите Deploy
  • потребуется авторизация на GAE, и проект должен будет запуститься
  • Заходим по ссылке https://PasteYourGAEProjectNameHere.appspot.com/set_webhook
  • должны получить webhook setup ok.
Можно посмотреть логи чтобы понять что не так (если что то не так) 

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

3.2. Самостоятельная установка.

Вариант которым пришлось воспользоваться мне - чуть более длинный. По идее должен был заработать virtualenv из видеоинструкции, но у меня не заработал.
  • Запускаем Google App Engine SDK
  • Создаем в нем новый проект  New Application с наименованием нашего проекта в GAE. 
В app.yaml нужно дописать в конец:
- name: ssl
  version: "2.7"
Или другую актуальную версию библиотеки с https://cloud.google.com/appengine/docs/python/tools/libraries27

В main.py записать основной код, например:
#!/usr/bin/env python
import sys
import os
sys.path.append(os.path.join(os.path.abspath('.'), 'venv/Lib/site-packages'))
import telegram
from flask import Flask, request
app = Flask(__name__)
global bot
bot = telegram.Bot(token='PasteYourTokenHere')
@app.route('/HOOK', methods=['POST'])
def webhook_handler():
    if request.method == "POST":
        # retrieve the message in JSON and then transform it to Telegram object
        update = telegram.Update.de_json(request.get_json(force=True))
        chat_id = update.message.chat.id
        # Telegram understands UTF-8, so encode text for unicode compatibility
        text = update.message.text.encode('utf-8')
        # repeat the same message back (echo)
        bot.sendMessage(chat_id=chat_id, text=text)
    return 'ok'
@app.route('/set_webhook', methods=['GET', 'POST'])
def set_webhook():
    s = bot.setWebhook('https://PasteYourGAEProjectNameHere.appspot.com/HOOK')
    if s:
        return "webhook setup ok"
    else:
        return "webhook setup failed"
@app.route('/')
def index():
    return '.'

Подправив PasteYourGAEProjectNameHere и PasteYourTokenHere
создать текстовый файл requirements.txt   со следующим содержимым:
Flask>=0.10.1
python-telegram-bot>=2.5
Дальше в терминале перейти в папку с проектом, и установить библиотеки командой
pip install -t lib -r requirements.txt
Вот тут я уверен что я не прав, но ничего поделать не могу. Команда создаст папку lib и установит туда кучу библиотек. 
Если сейчас сделать Deploy в Google App Engine SDK, то в логах запущенного instance мы увидим ImportError: No module named telegram
Я смог с этим справиться только копируя все необходимые библиотеки в корень папки проекта (
А именно папки:
  • werkzeug
  • telegram
  • markupsafe
  • jinja2
  • future
  • flask
  • и файл itsdangerous.py
Теперь после Deploy можно зайти на https://PasteYourGAEProjectNameHere.appspot.com/set_webhook и мы должны увидеть webhook setup ok

Бот должен заработать.


Monday, October 26, 2015

Варианты для гиперконвергентного решения SMB.


С свете гиперконвергентности и прочих маркетинговых штук нужно многое протестировать, прочитать. Вендоров много, решений еще больше.
Я присмотрел несколько вариантов на будущее:

HP StoreVirtual VSA - интересное решение со знакомым логотипом, хорошо документировано. Есть бесплатная лицензия на 1 тб для коммерческого использования. Возможно vmWare, Hyper-V. Ставится не только на сервера HP. Цены более или менее открыты (3500$ за ноду в 10 тб или 3500$ за 3 ноды по 4tb, это я грубо), их можно найти в сети. Уже пробовал - работает. Для малого бизнеса очень хорошо подходит. Бесплатный StoreOnce VSA + бесплатный кластер на Hyper-v, и вот тебе датацентр. Можно добавить бесплатный HP StoreOnce VSA и бесплатный же Veeam. Короче остается оплатить железо и лицензии ОС которые будем крутить внутри. Хотя про Veeam это я зря наверное.




Nutanix - позиционируют себя как решение на котором работает Google (или работал, тут темная история). Активно пиарят себя на Habrahabr, хотя я раньше не понимал о чем они вообще. Для SMB может и не интересно, т.к. для датацентров рассчитано. поддержка Hyper-v, VmWare, KVM. Сейчас есть и как софт в продаже и целиком софт + сервера. Цены неизвестны. Зато есть бесплатный Nutanix CE! Обязательно попробую. Его можно, хоть и не рекомендуется использовать в production. Но что для нас - не рекомендовано если бюджет равен 0? Ограничения в бесплатной версии есть и главное из них - использование только их гипервизора на базе KVM. Я не рискнул пока, т.к. с этой штукой мало знаком. Но пробовать надо. Обещают очень много плюшек в своем решении. Поддержка SSD tiering не просто есть, без SSD просто не взлетит. Сложности с ценообразованием наверное решаются запросами к sales. Поскольку история темная, может и продадут по ценам сравнимым с HP (если только софт).

StarWind -  прямой конкурент HP StoreVirtual VSA. Только менее раскручен. Могут построить решение от 2х нод (для HP нужна третья - любая). Могут использовать сетевые интерфейсы более экономично чем VSA, по крайней мере обещают. Могут интегрироваться с гипервизором. То есть работают не как виртуальная машина полностью абстрагированная от железки (VSA), а встраивают что то там в ОС гипервизора. Это и плюс и минус. Free версия ограничена двумя нодами, но не ограничена по дисковому пространству. Можно использовать в production.

VMWare Virtual SAN - от одного вендора можно получить полный спектр. И обращаться потом в одно окно. Но дороговато, насколько я знаю, как все у VMWare. Точнее как - считать надо. Аппаратные требования нужно хорошо представлять. Есть опасность Vendor Lock. Т.к. отдать по iscsi полученное пространство вроде невозможно никому кроме vmware. Я с VMWare не сильно дружу, так что сказать не могу ничего. 





Microsoft предлагает сразу ряд решений.  Получается тоже почти одно окно для обращений (железо отдельно). Storage Spaces Direct, насколько я понимаю нужно щупать Server 2016. Для предоставления пространства напрямую гостям или приложениям  нужны лицензии Windows Server. Есть еще Storage Replica, но он для других целей. Нужно JBOD оборудование, есть какие то ограничения, но в целом круто.

Microsoft Clustered Storage Spaces - тоже неплохо. Не пробовал, но обещают много всего. Для работы требуется таки рекомендуемое оборудование. Всякие JBOD поддерживающие штуки (контроллеры, полки).  С лицензированием пока не понял - можно ли Hyper-v бесплатный использовать? Думаю если только для виртуализации то да, а если захочется получить доступ из приложения к пространству, то нужна лицензия. 

Microsoft ScaleOut file servers. Тоже не щупал. По идее нужны опять таки лицензии Windows server, CALs, совместимое железо. В свете Storage Spaces Direct меркнет - другие задачи. Но использование возможно. Радует что у Microsoft столько решений, на разные вкусы.

Есть еще несколько (недавно узнал про Parallels Virtuozzo, Datacore, Maxta) игроков. Но на мой взгляд они для серьезных датацентров, а не для решений SMB.

Sunday, October 25, 2015

Смена технологий в СХД


Типичное инфраструктурное решение для SMB сейчас это несколько хостов с установленными гипервизорами и некий вариант Shared Storage для возможности кластеризации. И чаще всего эта схема выглядит как пара, тройка хостов подключенных к NAS по iSCSI. Hyper-v сейчас работает по SMB 3.0, и что то там можно накрутить с Clustered Shared Storage в среде Microsoft, что должно по идее дать много плюшек вместе с Storage Spaces. Но сейчас не об этом, я пока не игрался :). Традиционно люди закупают NAS'ы для этих целей или полки с подключением по SAS.


В очередном проекте возникла задача построения кластеров на имеющемся оборудовании, и при этом никаких СХД не было в наличии. Первым решением было поднять на одном из серверов хранилище и завязаться на него. Поскольку сервера были HP, в ходе обновлений прошивок наткнулся на интересное решение - HP StoreOnce VSA.
Уже потом выяснил что для пользователей VMWare даже есть родные решения такого же плана vSAN и еще что то. И что на рынке сейчас много подобных решений StarWind, Nutanix. Технологии имеют маркетинговый шильдик "Гиперконвергентность". Касательно HP StoreOnce  все работает - проверено. Оно до 1ТБ еще и бесплатное теперь, при этом работает не только на серверах HP! А в SMB шансов уместить в 1-1,5 ТБ важные виртуальные машины как раз много.
Суть в том что сервера сами себе СХД, причем распределенное, отказоустойчивое СХД. Берем дисковое пространство, отдаем его в некий общий пул, а потом подключаемся к этому же общему пулу и получаем из него нужное нам пространство.

Решение HP VSA StoreVirtual предоставляемое компанией HP совместно с Intel сроком на 3 года, ограниченное 3мя нодами хранилища и 1 террабайтом дискового пространства на каждой из нод. В результате внедрения получаем общее дисковое пространство до 1,5 Tb (доступное для использования), подключаемое по iSCSI к хостам гипервизоров, используемое для целей создания отказоустойчивого кластера Hyper-V.

На аппаратном хосте создается дисковый аппаратный RAID уровня 10. На нем располагается диск VHDX, который предоставляется виртуальной машине HP VSA. Несколько таких виртуальных машин в свою очередь формируют виртуальную SAN. Сформированные в виртуальной SAN диски предоставляются тем же аппаратным хостам (или любым другим) по iSCSI. На подключенных таким образом дисках гипервизоры могут создавать отказоустойчивые решения (кластеры), как в рамках целей виртуализации, так и в рамках кластерных решений БД, приложений и пр. Чуть позднее вычитал где то что лучше отдавать не готовый VHDX, а выделенный логический диск  сформированный Raid контроллером (ну или LUN). Мы же мигрировать виртуальную машину с хранилищем не будем.



Синим выделены виртуальные машины HP VSA; черным – аппаратные хосты гипервизор; оранжевым – виртуальные машины. 

Решение не требует дополнительных расходов на лицензирование и задействует имеющееся аппаратное обеспечение. Масштабируется путем лицензирования дополнительных опций, дискового пространства. Либо путем добавления аналогичных решений (копирования решения). Возможно использование аналогичного решения в географически распределенных системах (MultiSite), обеспечивающих работоспособность сервисов при выходе из строя одной из серверных комнат. Но тут не пробовал, при бесплатных 3х нодах как построить такое - не знаю.
Можно построить на двух, но тогда нужен некий третий сервер, который будет определять - кто из серверов VSA живой, а кто нет в случае конфликта. Третий требует минимальных ресурсов, почти ничего.
Возможно масштабирование увеличением количества нод, но это уже лицензии нужны.
Много вопросов возникло при планировании решения, при тестировании. Как что лучше настроить, подключить. В качестве примера - схема подключения.

В самой СХД участвуют только первые три сервера, четвертый в данном случае не содержит общего пространства. Но подключен к iscsi vlan и может использовать общее хранилище. Суть в том что для подсистемы хранения (виртуальных машин StoreOnce VSA) выделяем отдельные сетевые интерфейсы. Два, поскольку хотим иметь агрегацию и отказоустойчивость.  Подключаем к двум коммутаторам. А коммутаторы связываем между собой агрегацией. Можно все в один коммутатор, тогда коммутаторы практически не нужно настраивать. Вся настройка будет заключаться в выделении для СХД подсети отдельного Vlan. Пакеты дальше этих коммутаторов лучше не гонять, ибо латентность.
Дьявол в деталях, так что на самом деле эта схема ошибочна. 
Тиминги интерфейсов VSA делать не умеет!!! Так что тиминг нужно делать силами гипервизора (vSwitch)
На серверах в данном случае всего 4 интерфейса сетевых, а нужно 6! Потому что лучше отдать VSA пару интерфейсов для своих нужд (и сделать тиминг на уровне Hyper-v), дать самим Hyper-v пару интерфейсов для подключения к хранилищу по iSCSI (уже без тиминга, т.к. здесь уместнее MPIO), и для виртуальных машин тоже нужно что то выделить. С трудом можно совместить траффик VSA и iSCSI на одних и тех же интерфейсах, но в этом случае либо не будет Teaming для VSA, и VSA будет использовать только 1 интерфейс, либо MPIO не использовать. В общем - лучше 6.

Управление VSA осуществляется при помощи ПО HP StoreVirtual Centralized Management Console. Консоль можно установить на созданном для этого виртуальном сервере. Возможна установка консоли на другие сервера, для управления достаточно доступа с этих серверов к сети VSA. Сервер можно свободно перемещать между хостами гипервизоров, не рекомендуется его хранить на самом СХД, а для работы ему требуется доступ к сети VSA.
Гиперконвергентные решения в SMB скорее всего будут обходить по соотношению цена/производительность и цена/емкость и всем кому грозит апгрейд СХД или просто планируется покупка - стоит посмотреть в эту сторону. Конкуренция на этом рынке сейчас есть, есть из чего выбрать.