Введение

В этой статье я расскажу о нюансах активации проф-версии обновлятора на виртуальных системах.

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

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

Чтобы увидеть эти параметры для своей системы (так как их видит обновлятор), нажмём в запущенном обновляторе комбинацию клавиш Ctrl + F6.

В отчёте мы увидим следующее:

В данном случае:

• модель материнской платы gigabyte 970a-ds3p
• модель процессора amd fx-6100

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

В виртуальной системе будут также присутствовать свои материнская плата и процессор.

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

Возможные трудности

Изменилось представление процессора или материнской платы

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

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

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

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

Рассмотрим трудный случай.

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

При миграции на другой узел, обновлятору будут возвращаться уже другие мат. плата и/или процессор и активация неизбежно слетит.

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

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

1. Тогда мы активируем обновлятор (используя первый регистрационный ключ) на одном из узлов кластера и полученный код активации (его нам высылает робот на почту) складываем в папку Keys, которую мы создаём внутри папки Data обновлятора.

В этой папке мы создаём файл с любым именем и с расширением ".txt" и записываем в него полученный на почту код активации. Назовём этот файл "1.txt".

2. После того как виртуальная система мигрирует на второй узел кластера обновлятор скажет нам, что текущая лицензия больше недействительна.

В этом случае мы вновь активируем его (используя второй регистрационный ключ) и полученный код активации также кладём в папку Keys в текстовый файл уже с другим именем, например, "2.txt".

3. После этих манипуляций в папке Keys будет лежать 2 файла: "1.txt" и "2.txt", в каждом из которых будет свой код активации соответствующий одному из узлов кластера.

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