ESXI 5.1 “O disco não é thin-provisioned” depois de copiar o vmdk para o novo armazenamento de dados

2

Eu queria criar um backup externo e uma segunda VM pronta para execução no segundo armazenamento de dados.

Eu removi todos os instantâneos, desliguei a VM e exportei o arquivo OVF para um computador, ajustei o tamanho da VM original, inicializei no Gparted para atualizar a partição e reinicializar. Tudo bem.

Eu então tentei implantar o OVF no armazenamento de dados alternativo (235GB fino, 250 de espessura de acordo com o assistente de implantação). Eu tentei grosso e fino, mas recebi o erro "Falha ao implantar o OVF. A operação foi cancelada pelo usuário".

Eu então carreguei manualmente o VMDK & Arquivo OVF para o segundo armazenamento de dados e tentou inflar mas, em seguida, recebeu a mensagem "Um parâmetro especificado não estava correto. O disco não é thin provisioned".

Com base em ( link ) Eu suspeito que há algo similar em 5.1. No entanto, não tenho ideia do que fazer agora ... e estou preocupado porque parece que meu plano de backup pode não funcionar se houver um problema crítico.

Rob

    
por Robert Peterson 30.10.2015 / 12:57

1 resposta

1

Um rápido Google com o erro que você está recebendo ( Failed to deploy the OVF. The operation was cancelled by the user ) me leva a esta postagem o site Comunidades VMware.

Diz

Deleted *.mf file and change settings en OVF file

Failed to deploy OVF package: The task was canceled by a user.

How misleading. I, or any other user, certainly didn’t cancel the task. So what happened? I took a look through the (horrendous) hostd.log on the ESXi box and found absolutely nothing of any value.

Frustrated by the inability to redeploy a template I spent so long preparing, I broke open the OVA template and took a look inside. There were three files with different extensions:

  1. .ova - OVF descriptor, written in XML, which describes the hardware requirements
  2. .mf – contains SHA1 checksums of the .OVA and .VMDK
  3. .vmdk – the virtual hard disk for the virtual machine.

I immediately discarded the .mf. If you modify the .ova and don’t update the .mf, it’ll complain that the checksum is invalid. Removing this file seems to prevent vSphere from checking the checksums, which is useful, seeing as we want to poke around the .ova. After fiddling around inside the .ova, I stumbled across the following line:

<rasd:ResourceSubType>vmware.cdrom.iso</rasd:ResourceSubType>

Changing the above line, to read:

<rasd:ResourceSubType>vmware.cdrom.atapi</rasd:ResourceSubType>

Appears to have fixed my deployment issues. Perhaps changing the ‘CD Drive Device type’ in the virtual machine’s settings would’ve fixed it. But by that point, I had already exported the OVA and deleted the source virtual machine.

Hopefully someone will stumble across this one day, and it’ll save them a few hours!

Há também uma resposta logo abaixo daquilo que pode funcionar também, já que basicamente faz o mesmo antes de exportar a VM / vApp:

Before creating an OVA file, in vSphere right click on the VM, open Settings, click on CD/DVD drive, check if Device Type is selected as Datastore ISO. If so, select Client Device. Save settings by clicking OK. Export OVA file, and then deploy.

    
por 30.10.2015 / 18:32