Может, не кластеризовать Proxmox, а только Ceph? Тогда используй два отдельных одноузловых Proxmox для каждой Windows VM и отдельный кластер Proxmox (с QDevice) для остальных машин. Можно использовать Proxmox Datacenter Manager, чтобы управлять тремя отдельными кластерами из одного места.

У HA есть настройка Groups: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_configuration_16. Если я правильно помню, это относится к HA, но не к ручным миграциям…? Или, возможно, это работает так, что если ВМ выключена, её можно перенести туда, но при запуске она попытается переместиться.

Может, так? Добавьте новый Storage backend только на узлы 1 и 2, а затем добавьте диск (фиктивный) на эту VM из этого Storage — миграция тогда не удастся на другие узлы, у которых нет этого Storage backend.

Можно добавить ещё один пул к тому же Ceph backend'у, может быть? Это бы решило требование "нельзя трогать нелицензионный нод".

Я сам Ceph не использую, но, скорее всего, создам новый Ceph Pool с каким-нибудь названием, допустим, vm-node-lock. Потом отредактирую /etc/pve/storage.cfg под записью vm-node-lock, добавив узлы pve1 pve2, сохраню и выйду. (Я не знаю имена ваших узлов 1 и 2, но ты понял принцип). Это должно ограничить этот Pool только этими узлами. Проверь в GUI под разными узлами. Потом добавь диск любого незначительного размера, который хранится на хранилище vm-node-lock, к этой ВМ. Должно получиться. Удачи. Напиши, если получится.

РЕДАКТИРОВАНИЕ: Выбор узлов, вероятно, можно сделать и в GUI.

Если администратор может вручную переместить его за пределы пула HA, он также может вручную "исправить" ваше аппаратное назначение. Большинство лицензионных моделей не заботятся о том, какие именно два хоста, главное — не больше двух. Например, если узел умирает или даже лицензированные компоненты заменяются по гарантии, если у вас аппаратная блокировка (это OEM-лицензия в терминологии Microsoft и не совсем легально для индивидуальной покупки), вам придется покупать "новый" экземпляр, а не просто переносить его.

Будь осторожен, хак для ограничения количества узлов кластера может оказаться недействительным для этой модели лицензирования. Именно из-за этого у некоторых провайдеров возникли проблемы: нужно лицензировать на любой системе в твоем дата-центре/кластере, где она потенциально может работать, даже если этот хост простаивает. Лимит не определяется каким-то самодельный программным "лазейкой", а определяется как физические системы, на которые твоя компания разворачивает виртуальные машины, и что Microsoft может разумно предположить, что на них может работать. Намерение состоит в том, чтобы ты мог гибко лицензировать и перепродавать лицензию, я не знаю, можно ли её использовать внутри компании, если ты её не перепродаешь.

https://blogs.vmware.com/cloud/2020/09/29/microsoft-spla-licensing-release-update/#:~:text=How will it work?,Windows licensing on and off . http://cc.cnetcontent.com/vcs/hp/in...EAAE25A089367509064BDFDAF253_source.pdf#page2 Понятно говорит о том, что это касается кластера или "host fabric", что включает в себя любую систему, участвующую в обеспечении сети и хранилища. И в зависимости от лицензирования нужно лицензировать достаточное количество для числа хостов и, возможно, ядер.

Для Azure они определяют "fabric" как "платформу, которая не только размещает распределенные приложения, но и помогает управлять их жизненным циклом независимо от хост-ВМ". Есть юридическое определение, которое довольно близко к этому описанию. Если третий узел каким-либо образом участвует в жизненном цикле (я бы предложил, что это настолько просто, как участие в кворуме для других узлов), то его нужно лицензировать.