Мы используем функции массива хранения для клонирования LUN, а затем снова отображаем эти «новые» LUN на тот же или другой хост. Типичный случай - это обновление между средами, поэтому представьте себе клонирование LUN, содержащего группу виртуальных машин, с исходного хоста TEST1 на целевой хост TEST2. Иногда целевой хост назначает диск автоматически, а иногда нет. Массив хранения изменяет серийный номер клонированного LUN (но мы можем изменить его обратно), но в остальном содержимое клонированного LUN идентично исходному. В случае обновления (в этом примере удалите старый LUN из TEST2, а затем сопоставьте клонированный LUN на его месте) идентификатор LUN также останется прежним. Доступ к LUN осуществляется через Fibre Channel SAN, поэтому они не рассматриваются как съемные устройства. Излишне говорить, что в данной ситуации мы также не клонируем сам загрузочный LUN.
я нашел Microsoft KB234048 описывая поведение Windows 2000, но я подозреваю, что за последние 10 лет многое изменилось.
Если у кого-то есть подробности, включая особые случаи, например, являются ли они общими дисками MSCS или несколькими дисками с совпадающими подписями (например, клонированный диск сопоставлен с тем же сервером), поделитесь!
Что ж, на самом деле мало что изменилось - ассоциации по-прежнему хранятся в реестре внутри HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices ключ. Некоторое представление о том, что туда вставить / как интерпретировать данные, дает это сторонние документы.
Для кластерного хранилища Windows проверяет подпись MBR или GPT Guid (в зависимости от формата диска), чтобы идентифицировать диск, чтобы его можно было использовать на других узлах в кластере. Если два диска появляются с дублирующимися подписями / руководствами, я считаю, что используется первый, а остальные остаются в автономном режиме. Если вы хотите, чтобы клонированный диск отображался как новый, вам необходимо изменить подпись / guid.