Hyper-V, Disco Diferencial, Alterar caminho é resolver junções - como parar isso?

Question

Me dá dor de cabeça.

Eu tenho uma tonelada de discos diferenciais. A fim de mover os machiens ao redor - e porque (Thank heaven) vm move NÃO copia as fontes de discos diferenciais (infelizmente exporta), minha idéia é ter uma cópia central de todos os Masters em todos os computadores Hyper-V. / p>

Exemplo: A VM X tem um vhdx chamado "System.vhdx" e isso é diferente de ... \ masters \ x64-2012std.vhdx "

Para padronizar os caminhos dos discos diferenciais, eu gostaria que eles estivessem em c: \ Hyper-V \ Masters ....

Agora, C nem sempre tem espaço suficiente, então minha ideia era que \ Masters \ ali é uma junção ao caminho real.

Trabalhos, EXCETO:

PowerShell set-vhd ...... \ system.vhdx -ParentPath c: \ Hyper-V \ Mestre ..... goon.vhdx

funciona, a VM começa, MAS ...

get-vhd

me deixa ver que o vhdx está diretamente ligado ao arquivo - de alguma forma o Hyper-V achou legal RESOLVER a junção e substituí-la pelo caminho "real" do arquivo.

O que quebra totalmente quando eu movo a VM para outro host que tem um layout de disco diferente (e atualmente planejamos 3 unidades).

Agora, há alguma maneira de contornar isso? Eu gostaria que o ParentPath fosse o ParentPath AS que eu defini, não algo mudou, ou para obter um erro.

    

Answer 1

O PowerShell é executado em um contexto de usuário totalmente diferente e, às vezes, em uma máquina totalmente diferente do próprio Hyper-V. Portanto, qualquer caminho de arquivo usado dentro dele deve ser totalmente expandido para ser significativo. Para caminhos relativos, simplesmente não há uma boa resposta para a pergunta "em relação ao que" porque as expansões do caminho do arquivo podem ser específicas do contexto do usuário.

Eu entendo, no entanto, que sua estratégia tem uma resposta para essa pergunta, mas a maioria deles não. E o código de expansão do caminho está apenas usando a expansão subjacente do caminho .net, que aparentemente expande os pontos de nova análise.

Você pode tentar falar diretamente com a camada WMI, em vez de usar os cmdlets do PowerShell. Você pode encontrar um monte de exemplos no blog "Virtual PC Guy" de Ben Armstrong.