Usamos os recursos da matriz de armazenamento para clonar LUNs e mapear essas "novas" LUNs novamente para os mesmos ou diferentes hosts. Um caso típico é quando atualizamos entre ambientes, então imagine clonar um LUN contendo um monte de VMs do host de origem TEST1 para o host de destino TEST2. Às vezes, o host de destino atribuirá a unidade automaticamente e, às vezes, não. O storage array muda o número de série do LUN clonado (mas podemos modificá-lo de volta), mas para o resto o conteúdo do LUN clonado é idêntico ao da fonte. No caso de uma atualização (portanto, neste exemplo, remova o antigo LUN do TEST2 e, em seguida, mapeie o LUN clonado em seu lugar), o ID do LUN também permanece o mesmo. Os LUNs são acessados por uma SAN Fibre Channel e, portanto, não são vistos como dispositivos removíveis. Escusado será dizer que, na situação aqui, não estamos clonando o próprio LUN de inicialização.
Eu encontrei o Microsoft KB234048 descrevendo o comportamento do Windows 2000, mas suspeito que muita coisa mudou nos últimos 10 anos.
Se alguém tiver detalhes, incluindo casos especiais como se forem discos compartilhados do MSCS ou vários discos com assinaturas correspondentes (ou seja, o disco clonado estiver mapeado para o mesmo servidor), compartilhe!
Bem, na verdade, não mudou muito - as associações ainda estão armazenadas no registro na HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices key . Algumas informações sobre o que colocar lá / como interpretar os dados são provenientes de documentos de terceiros .
Para armazenamento em cluster, o Windows examina a assinatura MBR ou o GPT Guid (dependendo do formato do disco) para identificar o disco, de modo que ele possa ser usado em outros nós no cluster. Se dois discos aparecerem com assinaturas / guias duplicadas, acredito que o primeiro seja usado e os outros sejam deixados offline. Se você quiser que um disco clonado apareça como um novo disco, você precisará alterar a assinatura / guid.