OVF Deployment Failed: File ds:///vmfs/volumes/uuid/_deviceImage-0.iso was not found

来源:互联网 发布:查淘宝在线人数的插件 编辑:程序博客网 时间:2024/05/19 01:13
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2034422

Deploying an OVF fails on vCenter Server 5.1 when VMware tools are installed (2034422)

Symptoms

  • Deploying an OVF fails on vCenter Server 5.1 when VMware Tools are installed
  • When deploying an OVF from a virtual machine that has VMware Tools installed, you see the error:

    OVF Deployment Failed: File ds:///vmfs/volumes/uuid/_deviceImage-0.iso was not found

    Where uuid is the datastore ID where the OVF is being deployed

Cause

This error occurs when the VMware Tools installation task is not finished. The guest operating system may already have the Tools successfully installed and running, but the ESX task for installing the tools has not finished.
 
In vSphere 5.0 and earlier, device backings (what the device is connected to) were not exported. OVF files generated on ESX 5.0 and earlier do not contain the device backing information and therefore do not encounter this issue when importing on ESX 5.1
 
In vSphere 5.1, virtual machines device backing information is exported. When the Tools install task has not finished it leaves the virtual machine's CD-ROM device connected to a datastore ISO image that cannot be accessed upon re-deployment of the OVF to a new virtual machine, which causes the error.

Resolution

To resolve this issue:
  1. Right-click the virtual machine and clickGuest >End VMware Tools Install.
  2. Export the virtual machine to a new OVF file.
  3. Confirm in the newly exported OVF that the CD-ROMResourceSubType reads like this:

    <Item ovf:required="false">
        <rasd:AddressOnParent>0</rasd:AddressOnParent>
        <rasd:AutomaticAllocation>false</rasd:AutomaticAllocation>
        <rasd:ElementName>CD-ROM 1</rasd:ElementName>
        <rasd:InstanceID>9</rasd:InstanceID>
        <rasd:Parent>4</rasd:Parent>
        <rasd:ResourceSubType>vmware.cdrom.remotepassthrough</rasd:ResourceSubType>
        <rasd:ResourceType>15</rasd:ResourceType>
        <vmw:Config ovf:required="false" vmw:key="backing.exclusive" vmw:value="false" />
        <vmw:Config ovf:required="false" vmw:key="connectable.allowGuestControl" vmw:value="true" />
      </Item>

Note: When the ResourceSubType value is set tovmware.cdrom.iso, deploying the OVF fails and you see the error.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

Quick vSphere OVF/OVA Hack

Found myself in a predicament just the other day. I had spent several hours building out template VMs for a few servers, installing vmtools, applying all the latest updates, running sysprep, etc. At the end of that effort, I exported them to .ova files and removed the original VMs. Then I decided I might want to test these .ova exports to make sure they work. Well, guess what? I found myself with broken .ova files that would not import.

The error message, “OVF Deployment Failed: File ds:///vmfs/volumes/uuid/_deviceImage-0.iso was not found” led me toVMware KB article 2034422. The resolution, of course, required use of the original source VMs which I had over zealously deleted earlier. Thankfully, the article gave enough detail about the issue that I was able to work up the following little hack to repair my damaged .ova files:

  1. I extracted the contents of the .ova files using tar. This works because .ova files are just uncompressed tar archives. You could also use7zip on Windows.
  2. Inside, there was one .mf or manifest file, one .ovf file, and one .vmdk. There would be more .vmdk files if I had more drives associated with the VMs.
  3. I edited the .ovf file to change the text “vmware.cdrom.iso” to“vmware.cdrom.remotepassthrough”. The reason for the failure was that the import process was trying to mount a non-existent vmware tools iso image.
  4. Once edited, the SHA1 sum of the .ovf file had changed, causing it to not match the sum contained in the manifest. I generated a new SHA1 sum and replaced the original in the .mf manifest file.
  5. Finally, I re-archived the files with tar, making sure to change the extension on the end back to .ova. The tricky bit to this is to make sure you add the files to the archive in the correct order. The .ovf has to be the first file in the archive. Usetar cvf archive.ova vm.ovf to create, then tar uvf archive.ova *.mv *.vmdk to append the rest of the files. Note that I couldn’t get 7zip to archive these in order. I had to use GNU tar from an Ubuntu VM.

I was then able to successfully import the .ova files back into my vSphere environment.

http://kristau.net/?p=1265
原创粉丝点击