rPman

Виртуализация не позволяет объединять мощности!

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

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

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

linux переносится очень просто, средств миллион, в данном случае виртуальная машина должна восприниматься как еще один компьютер в сети а значит и вопрос значится как склонировать linux с одной машины на другую

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

Либо можно все сделать вручную без каких либо инструментов из linux, запущенного с отдельного носителя (например установочный liveusb linux), этот вариант требует большего понимания что делать но он может быть проще чем clonezilla (парадокс да) и не требует промежуточного хранилища:
* Запускаешь на обоих машинах linux (сеть должна быть настроена в виртуалке например - сетевой мост с локальной сетью, тогда ip будет выдавать роутер автоматически).
* Выбираешь одну из машин как рабочую (например целевая виртуальная), за которой будешь сидеть и ставишь там nbd-client (а на другой nbd-server), на второй (например реальная машина) прописываешь в /etc/nbd-server/config

[generic]
allowlist = true
[sda]
  exportname = /dev/sda
[sdb]
  exportname = /dev/sdb
# и так для каждого диска в машине

* перезапускаешь nbd-server и все
service nbd-server restart
* на основной

sudo modprobe nbd
sudo nbd-client -name sda ip-адрес-мащины-nbd-server /dev/nbd0
# и так для каждого диска, поменяв например sdb и /dev/nbd1

все! теперь у тебя на одной машине подключены по сети диски другой

* Если размеры дисков одинаковы то можно тупо скопировать их с помощью

dd if=/dev/nbd0 of=/dev/sda bs=1024k status=progress

эта команда скопирует с сетевого nbd0 на локальный sda (можно поменять местами как тебе требуется)
после этого ничего делать не надо будет (исключение efi загрузчик, на сколько я знаю virtualbox только недавно научился его, еще в бете 7 версия, а так смена efi на legacy mbr потребует вручную запустить grub) и все будет работать.

* Если размеры дисков и разделов разные, но свободного места хватает (например с большего на меньший диск) то можно так же с помощью clonezilla все склонировать, выбрав режим device-to-device

А можно вручную создать нужную структуру разделов, например исправив детские ошибки, допущенные при установке исходной машины (например убрать LVM тома) и вручную же скопировать раздел с помощью partclone (его использует clonezilla)

Нет, потому что программы на гипервизор запускать не нужно, доступ к нему должен быть закрыт фаерволом

Хост - однозначно linux, это на случай совсем проблем с windows (получить мертвую виртуалку гораздо безболезненее чем получить в принципе мертвый парк машин), либо готовый xen либо kvm, можно даже virtualbox (вот уж с чем справится любой будущий админ но не рекомендую), мне нравится не готовый гипервизор а полноценный linux с запущенным на нем libvirt, машины можно настраивать как с полной виртуализацией так и lxc контейнеры.

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

По отказоустойчивости, если сеть между машинами выше гигабит, можно настроить файловый кластер (любой), виртуальные машины спокойно будут мигрировать в пределах кластера по клику, но из коробки красиво обычно все это доступно только если хранилище на NAS (iscsi), иначе ручками. Баы данных (sql) при наличии возможности настройки master-slave/master репликации, лучше держать не на кластерной fs, да в этом случае восстановление после сбоя потребует больше телодвижений, но эти решения просто эффективнее и шустрее работают.

Максимально разделить задачи по виртуалкам, не смешивать домен контроллер, сервер приложений, файловое хранилище (кстати это вообще не нужно в виртуалке делать но если желеного NAS нет то некуда деваться)

Бакапы инкрементальные на nas, любыми средствами, можно как средствами хост машины так изнутри виртуалки (если сеть гетерогенная получится, то будут разные инструменты для win и для linux, но зато не будет привязки к гипервизору, что очень полезно в долгосрочной перспективе)

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

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

stream remote должен быть запущен внутри виртуальной машины
но в принципе этот способ будет давать накладные расходы виртуалки (10%-30% на cpu и вплодь до невозможности игры из-за gpu)

настоятельно рекомендую вместо запуска игры в витуалке запустить ее нативно, использовав на выбор:
1. ibik aster, никакого удаленного управления по сети, нативная работа игр и программ, десктопная версия windows (не серверная) при этом из мощного компьютера легко можно сделать с 10 рабочих мест (на самом деле без ограничений, сколько железо позволит), достаточно подключить нужное количество мониторов, клавиатур и мышек, 10-20 метров без особых затрат (дальше понадобятся удлинители, например при 100 метрах цены в 10-20 т.р. только за кабель монитора). Умеет работать с 1 gpu (когда то давно так успешно запускали какую то ммрпг на двоих)
Недостаток - одновременно одна и та же игра может не запуститься, так как к этому не готовы античиты (но советую все же попробовать, запускать игру под разными пользователями windows, установив ее в разные каталоги, да неэффективно по месту на диске, но в частных случаях это тоже можно решить)
2. ibikaster + steam remote - то же самое, только игровое место транслируется с помощью steam (мне кажется у них самый эффективный алгоритм трансляции видео в пределах локальной сети)
3. rdp - штатный протокол удаленного управления, не всякая 3d игра сможет корректно использовать видеоускоритель, если будет запущена в окне удаленного рабочего стола, но к примеру старые 2d игры вполне идут, отзывчивость в таком режиме, при наличии хорошей локальной сети (гигабит) - очень хорошая
ограничение десктопных windows на одновременное подключение снимается утилитой rdpwrap

p.s. одновременно несколько рабочих мест как ibik aster можно сделать бесплатно на linux с помощью ее штатного инструмента multiseat (на каждое рабочее место своя видеокарта) а с помощью xserver xephyr и в пределах одной видекарты (но придется поковыряться), а там возможно ваша игра уже поддерживается официально (вот к примеру только что в офф стим клиенте установил ark survival ребенку, идет даже шустрее чем на win) или не официально с помощью wine (но античит почти наверняка помешает)

Ну и штатно xserver умеет транслировать видео по сети (поковырять настройки, убрать шифрование и сжатие), я помню очень давно для теста запускал кажется quake, оно в принципе работало и даже не лагало (просто не высокий fps) отзывчивость была явно выше vnc/rdp, но там использовался ускоритель клиента, сейчас наверное это можно как то настроить