Как перенести лицензию 1С на ВМ между разными аппаратными хостами?

[Odineski]

как решать проблему переноса лицензии, когда виртуальная машина переезжает между аппаратно разными хостами

[Odin — Одинэсник]

При переносе виртуальной машины между аппаратно разными хостами нужно разделять две разные проблемы:

1. Лицензия 1С, установленная программным способом.
2. Лицензия Windows Server, если сама виртуальная машина работает под Windows Server.

## 1. Если речь о лицензии 1С

Программная лицензия 1С может быть привязана к параметрам компьютера. В виртуальной машине в качестве таких параметров используются не только данные самой ВМ, но и виртуальные аппаратные идентификаторы:

— MAC-адрес сетевой карты;
— UUID виртуальной машины;
— идентификатор BIOS;
— параметры виртуального процессора;
— серийные номера виртуальных дисков;
— идентификаторы материнской платы и системного оборудования;
— иногда параметры гипервизора.

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

### Что желательно сделать заранее

Перед переносом виртуальной машины:

1. Сделать резервную копию информационной базы.
2. Зафиксировать текущий MAC-адрес виртуальной сетевой карты.
3. Зафиксировать UUID и настройки виртуальной машины.
4. Отключить автоматическую генерацию нового MAC-адреса.
5. Включить режим совместимости процессоров.
6. Не менять тип контроллера диска, тип BIOS и модель виртуального оборудования.
7. Не удалять и не создавать заново сетевой адаптер.
8. Не запускать одновременно старую и новую копию ВМ в одной сети.

Самая частая ошибка при восстановлении или клонировании ВМ заключается в том, что гипервизор назначает ей новый MAC-адрес. Это может повлиять не только на 1С, но и на лицензирование Windows, активацию программ, настройки сетевых служб и регистрацию сервера в домене.

—

## 2. Если используется Hyper-V

Для ВМ Hyper-V желательно сохранить следующие параметры:

PowerShell

Get-VM -Name "ИмяВМ" | Select-Object Name, VMId, Version Get-VMNetworkAdapter -VMName "ИмяВМ" | Select-Object VMName, MacAddress, DynamicMacAddressEnabled

1 2	Get-VM -Name "ИмяВМ" | Select-Object Name, VMId, Version Get-VMNetworkAdapter -VMName "ИмяВМ" | Select-Object VMName, MacAddress, DynamicMacAddressEnabled

Перед переносом можно задать статический MAC-адрес:

PowerShell

Set-VMNetworkAdapter ` -VMName "ИмяВМ" ` -StaticMacAddress "00155D123456"

1 2 3

Set-VMNetworkAdapter `     -VMName "ИмяВМ" `     -StaticMacAddress "00155D123456"

Проверьте, что MAC-адрес не используется другой виртуальной машиной.

Для совместимости процессоров:

PowerShell

Set-VMProcessor ` -VMName "ИмяВМ" ` -CompatibilityForMigrationEnabled $true

1 2 3

Set-VMProcessor `     -VMName "ИмяВМ" `     -CompatibilityForMigrationEnabled $true

Для переноса работающей ВМ между разными процессорами это особенно важно. Без режима совместимости миграция может завершиться ошибкой из-за различий в наборах инструкций CPU.

При переносе не следует менять:

— поколение виртуальной машины;
— тип виртуального BIOS или UEFI;
— контроллеры дисков;
— порядок загрузки;
— сетевой адаптер;
— MAC-адрес;
— виртуальный TPM, если он используется;
— настройки Secure Boot.

При этом даже сохранение MAC-адреса не гарантирует сохранение лицензии 1С, если сама лицензия была привязана к другим параметрам виртуального оборудования.

—

## 3. Если используется Proxmox

При переносе через резервную копию проверьте MAC-адрес:

Shell

qm config 100

1	qm config 100

В конфигурации должна быть строка примерно такого вида:

1С (Код)

net0: virtio=AA:BB:CC:11:22:33,bridge=vmbr0

1	net0: virtio=AA:BB:CC:11:22:33,bridge=vmbr0

После восстановления на новом сервере MAC-адрес необходимо оставить прежним. Если он изменился, задайте его вручную:

Shell

qm set 100 --net0 virtio=AA:BB:CC:11:22:33,bridge=vmbr0

1	qm set 100 --net0 virtio=AA:BB:CC:11:22:33,bridge=vmbr0

Также желательно сохранить:

— тип BIOS: seabios или ovmf;
— тип машины;
— модель сетевого адаптера;
— тип дискового контроллера;
— UUID ВМ;
— параметры CPU;
— наличие или отсутствие TPM;
— порядок подключения дисков.

Если перенос выполняется через vzdump и qmrestore, после восстановления не запускайте обе копии одновременно. Сначала отключите исходную ВМ от сети или полностью остановите ее.

—

## 4. Наиболее надежный вариант для 1С

Если 1С используется на постоянной основе, программную лицензию лучше не привязывать к каждой мигрирующей ВМ.

Практически применяются следующие варианты.

### Вариант 1. Аппаратный ключ 1С

Аппаратный USB-ключ HASP размещается:

— на физическом сервере;
— на отдельной стабильной виртуальной машине через USB-проброс;
— на USB-over-IP сервере;
— на сервере лицензирования, доступном по сети.

Плюс такого варианта в том, что перенос самой ВМ не меняет аппаратный ключ. ВМ переезжает между хостами, а ключ остается доступным по сети.

Нужно учитывать:

— USB-ключ не должен одновременно использоваться несколькими серверами без соответствующей схемы лицензирования;
— при размещении ключа на физическом хосте нужно обеспечить его доступность после отказа хоста;
— USB-over-IP должен поддерживать стабильное подключение и автоматическое переподключение;
— сетевой доступ к серверу лицензирования не должен блокироваться межсетевым экраном.

### Вариант 2. Отдельный сервер лицензирования

Можно вынести лицензирование 1С на отдельную ВМ или физический сервер, который не участвует в частых миграциях.

Рабочая схема:

1С (Код)

Пользователи 1С | v Сервер 1С | v Отдельный сервер лицензирования 1С

1 2 3 4 5 6 7

Пользователи 1С        |        v Сервер 1С        |        v Отдельный сервер лицензирования 1С

В этом случае сервер 1С можно переносить между хостами, а лицензирующая ВМ остается на заранее подготовленном узле.

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

### Вариант 3. Перевыпуск программной лицензии

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

Общий порядок:

1. Запустить базу 1С в режиме «Конфигуратор» или через соответствующий помощник лицензирования.
2. Открыть раздел получения программной лицензии.
3. Выбрать восстановление или повторное получение лицензии.
4. Указать регистрационный номер и PIN-код.
5. Использовать резервный PIN-код, если основной уже был активирован.
6. Получить новую лицензию для текущей конфигурации виртуального оборудования.

Важно: повторная активация может потребовать свободного PIN-кода из комплекта лицензии. Количество повторных получений и возможность восстановления зависят от типа поставки и использованного комплекта PIN-кодов.

Перед такими действиями нужно сохранить:

— регистрационный номер;
— комплект PIN-кодов;
— данные владельца лицензии;
— предыдущую лицензию;
— сведения о текущей конфигурации ВМ.

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

—

## 5. Live Migration и перенос с остановкой

Для лицензии 1С предпочтительнее следующая последовательность:

1. Остановить службы 1С:Предприятия.
2. Завершить сеансы пользователей.
3. Проверить резервную копию информационной базы.
4. Остановить ВМ.
5. Выполнить перенос ВМ.
6. На новом хосте проверить MAC-адрес и виртуальное оборудование.
7. Запустить ВМ без подключения к рабочей сети.
8. Проверить наличие лицензии 1С.
9. Проверить запуск сервера 1С и подключение тестового пользователя.
10. Только после проверки подключить ВМ к рабочей сети.

Для переноса лицензированной ВМ лучше использовать не клонирование, а штатную миграцию или перенос исходной ВМ. При клонировании появляются дополнительные проблемы:

— одинаковые MAC-адреса;
— одинаковые UUID;
— дублирование имени компьютера;
— повторная регистрация в домене;
— конфликт лицензий;
— одновременный доступ к одной и той же базе.

—

## 6. Если лицензия 1С привязана к виртуальному CPU

Иногда лицензия ломается не из-за MAC-адреса, а из-за изменения процессора. Например:

— на одном хосте Intel, на другом AMD;
— разное поколение Intel;
— изменилось количество виртуальных ядер;
— изменился режим представления CPU;
— на одном хосте доступны дополнительные инструкции, а на другом нет;
— изменился тип виртуального процессора.

В этом случае нужно:

— задать одинаковое количество виртуальных ядер;
— включить CPU compatibility mode;
— использовать максимально совместимую модель CPU;
— не менять количество сокетов без необходимости;
— не использовать проброс физического CPU или нестандартные CPU flags.

Для критичной ВМ обычно выбирают единый кластер хостов с совместимыми процессорами. Перенос между Intel и AMD для ВМ с лицензией, привязанной к аппаратным параметрам, может быть проблемным даже при сохранении MAC-адреса.

—

## 7. Если под «лицензией» имеется в виду Windows Server

Здесь есть два разных вопроса.

### Техническая активация Windows

При переносе ВМ Windows может потребовать повторную активацию, если изменилась конфигурация виртуального оборудования. Чтобы снизить вероятность этого:

— сохраняйте VM ID;
— не меняйте виртуальный диск и контроллер;
— сохраняйте MAC-адрес;
— не меняйте поколение ВМ;
— используйте одинаковую конфигурацию ВМ;
— не удаляйте виртуальный TPM;
— для доменных серверов не восстанавливайте одновременно старую и новую копию.

Проверить состояние активации можно так:

1С (Код)

slmgr.vbs /dlv slmgr.vbs /xpr

1 2	slmgr.vbs /dlv slmgr.vbs /xpr

### Лицензионные права Windows Server

Важен не только факт активации, но и право запуска Windows Server на целевом физическом хосте.

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

Для Windows Server Standard обычно лицензируются все физические ядра хоста, после чего лицензия дает право на определенное количество виртуальных экземпляров. Если на хосте размещается больше ВМ, лицензирование физического хоста может потребоваться выполнить повторно.

Windows Server Datacenter обычно выбирают, когда на физическом сервере должно работать много Windows Server ВМ.

При использовании лицензий с Software Assurance или подписочных правами могут действовать дополнительные права на перемещение виртуальных машин между серверами. Если таких прав нет, свободный перенос ВМ между разными физическими серверами может быть ограничен условиями лицензии, даже если технически миграция выполняется без проблем.

Рекомендую отдельно проверить условия именно вашей лицензии: OEM, Retail, CSP, Open, SPLA, Software Assurance или подписка. У этих вариантов права на перенос отличаются.

—

## 8. Практическая схема для отказоустойчивой 1С

Для двух аппаратно разных хостов лучше организовать так:

1С (Код)

Хост 1 Хост 2 ------ ------ ВМ 1С ---------------------> перенос ВМ 1С / / Сервер лицензирования

1 2 3 4 5 6

Хост 1                         Хост 2 ------                         ------ ВМ 1С  --------------------->  перенос ВМ 1С                             /                            /          Сервер лицензирования

При этом:

1. У ВМ фиксированный MAC-адрес.
2. CPU настроен в режиме совместимости.
3. На обоих хостах одинаковый тип виртуального оборудования.
4. ВМ переносится штатной миграцией, а не клонированием.
5. Сервер лицензирования не меняет свои идентификаторы.
6. Есть резервные PIN-коды 1С.
7. Перед переносом проверяется доступность аппаратного ключа или сервера лицензий.
8. Старая копия ВМ выключается до запуска новой в рабочей сети.
9. После миграции проверяется запуск клиента 1С, сервера 1С и получение лицензии.

Если лицензия 1С уже сломалась после переезда, сначала нужно вернуть прежние параметры ВМ, особенно MAC-адрес и CPU. Если это не помогло, выполнять восстановление программной лицензии через резервный PIN-код, а не просто копировать файлы лицензии со старой машины.

[Автор]

Записи