vmware-iso builder usually fails to detach iso

[Gregory Ruiz-Ade]

packer 0.7.5, OS X 10.10.2, VMware Fusion 7.1.1 (2498930)

Annoyingly, most of the time (but not always), packer's vmware-iso builder will fail to properly detach the boot ISO from the VM, which causes all sorts of problems for anything later that tries to use the resulting VM (either subsequent vmware-vmx builds, or indirectly via OVA with virtualbox-ova builds).

My build process is to create a "base" VM with vmware-iso, which is then turned into appropriately tuned templates via vmware-vmx, or vagrant boxes via vmware-vmx and virtualbox-ova. Needless to say, the problem isn't noticed until my builder either tries to ship the vSphere template via ovftool, or tries to build the VirtualBox vagrant box.

For example, I attempted a build today:

All indications are that everything worked correctly with the vmware-iso builder:

packer build -var "prefix=runner-" -var "platform=centos" -var "platform_version=6.6" -var "release=test-20150319-1" -var "build_dir=../images" -var "headless=true" -var "checksum=2560335ef975907799251ae9d6a0fa2e4d289704" -var "checksum_type=sha1" -var "boot_iso=http://mirror.active.tan/ISOs/CentOS/CentOS-6.6-x86_64-netinstall.iso" -var "disk_size=81920" -var "chef_version=latest" -var "ks=ks_runner.cfg" rhel_common-baseimage.json

vmware-iso output will be in this color.

==> vmware-iso: Downloading or copying ISO

    vmware-iso: Downloading or copying: http://mirror.active.tan/ISOs/CentOS/CentOS-6.6-x86_64-netinstall.iso

<<< ... snip ... >>>

==> vmware-iso: Gracefully halting virtual machine...

    vmware-iso: Waiting for VMware to clean up after itself...

==> vmware-iso: Deleting unnecessary VMware files...

    vmware-iso: Deleting: ../images/runner-centos-6.6-x86_64-test-20150319-1-baseimage.vmwarevm/564d14e5-d730-b769-5a03-b283bfbbb016.vmem

    vmware-iso: Deleting: ../images/runner-centos-6.6-x86_64-test-20150319-1-baseimage.vmwarevm/runner-centos-6.6-x86_64-test-20150319-1-baseimage.plist

    vmware-iso: Deleting: ../images/runner-centos-6.6-x86_64-test-20150319-1-baseimage.vmwarevm/vmware.log

==> vmware-iso: Cleaning VMX prior to finishing up...

    vmware-iso: Unmounting floppy from VMX...

    vmware-iso: Detaching ISO from CD-ROM device...

==> vmware-iso: Compacting the disk image

Build 'vmware-iso' finished.

==> Builds finished. The artifacts of successful builds are:

--> vmware-iso: VM files in directory: ../images/runner-centos-6.6-x86_64-test-20150319-1-baseimage.vmwarevm

As you can see, there's no indication there was a problem at this point. So, the build process carries on and creates the OVA:

ovftool --compress ../images/runner-centos-6.6-x86_64-test-20150319-1-baseimage.vmwarevm/runner-centos-6.6-x86_64-test-20150319-1-baseimage.vmx ../images/runner-centos-6.6-x86_64-test-20150319-1.baseimage.ova

Opening VMX source: ../images/runner-centos-6.6-x86_64-test-20150319-1-baseimage.vmwarevm/runner-centos-6.6-x86_64-test-20150319-1-baseimage.vmx

Opening OVA target: ../images/runner-centos-6.6-x86_64-test-20150319-1.baseimage.ova

Writing OVA package: ../images/runner-centos-6.6-x86_64-test-20150319-1.baseimage.ova

Transfer Completed

Completed successfully

So far, so good. Well, now we have the OVA, let's use it to build a VirtualBox vagrant box:

packer build -only virtualbox-ovf -var "prefix=runner-" -var "platform=centos" -var "platform_version=6.6" -var "release=test-20150319-1" -var "build_dir=../images" -var "headless=true" -var "source_vmx=../images/runner-centos-6.6-x86_64-test-20150319-1-baseimage.vmwarevm/runner-centos-6.6-x86_64-test-20150319-1-baseimage.vmx" -var "source_ovf=../images/runner-centos-6.6-x86_64-test-20150319-1.baseimage.ova" rhel_common-vagrant.json

virtualbox-ovf output will be in this color.

==> virtualbox-ovf: Downloading or copying Guest additions

    virtualbox-ovf: Downloading or copying: file:///Applications/VirtualBox.app/Contents/MacOS/VBoxGuestAdditions.iso

==> virtualbox-ovf: Importing VM: ../images/runner-centos-6.6-x86_64-test-20150319-1.baseimage.ova

==> virtualbox-ovf: Error importing VM: VBoxManage error: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

==> virtualbox-ovf: Interpreting /Users/gruiz-ade/tmp/scm-images/images/runner-centos-6.6-x86_64-test-20150319-1.baseimage.ova...

==> virtualbox-ovf: OK.

==> virtualbox-ovf: 0%...

==> virtualbox-ovf: Progress state: NS_ERROR_FAILURE

==> virtualbox-ovf: VBoxManage: error: Appliance import failed

==> virtualbox-ovf: VBoxManage: error: Internal inconsistency looking up disk image 'runner-centos-6.6-x86_64-test-20150319-1.baseimage-file1.iso.gz'. Check compliance OVA package structure and file names references in the section <References> in the OVF file

==> virtualbox-ovf: VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component Appliance, interface IAppliance

==> virtualbox-ovf: VBoxManage: error: Context: "int handleImportAppliance(HandlerArg*)" at line 779 of file VBoxManageAppliance.cpp

==> virtualbox-ovf: Deleting output directory...

Build 'virtualbox-ovf' errored: Error importing VM: VBoxManage error: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

Interpreting /Users/gruiz-ade/tmp/scm-images/images/runner-centos-6.6-x86_64-test-20150319-1.baseimage.ova...

OK.

0%...

Progress state: NS_ERROR_FAILURE

VBoxManage: error: Appliance import failed

VBoxManage: error: Internal inconsistency looking up disk image 'runner-centos-6.6-x86_64-test-20150319-1.baseimage-file1.iso.gz'. Check compliance OVA package structure and file names references in the section <References> in the OVF file

VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component Appliance, interface IAppliance

VBoxManage: error: Context: "int handleImportAppliance(HandlerArg*)" at line 779 of file VBoxManageAppliance.cpp

==> Some builds didn't complete successfully and had errors:

--> virtualbox-ovf: Error importing VM: VBoxManage error: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

Interpreting /Users/gruiz-ade/tmp/scm-images/images/runner-centos-6.6-x86_64-test-20150319-1.baseimage.ova...

OK.

0%...

Progress state: NS_ERROR_FAILURE

VBoxManage: error: Appliance import failed

VBoxManage: error: Internal inconsistency looking up disk image 'runner-centos-6.6-x86_64-test-20150319-1.baseimage-file1.iso.gz'. Check compliance OVA package structure and file names references in the section <References> in the OVF file

VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component Appliance, interface IAppliance

VBoxManage: error: Context: "int handleImportAppliance(HandlerArg*)" at line 779 of file VBoxManageAppliance.cpp

==> Builds finished but no artifacts were created.

As you can see, it's gone completely off the rails. If I go open the original VM from the first packer build in Fusion, I see that yes, indeed there is an ISO connected (screen shot: http://cl.ly/image/2F2i3O1a1619).

Running the packer build with --debug hasn't given any additional insight.

So... How do I begin to figure out where and why this is failing?

Thanks in advance,

Gregory

[Alvaro Miranda Aguilera]

On Fri, Mar 20, 2015 at 12:19 PM, Gregory Ruiz-Ade
<gregory....@gmail.com> wrote:
> vmware-iso: Unmounting floppy from VMX...
> vmware-iso: Detaching ISO from CD-ROM device...

Hello,

If you can please share json template file to reproduce, or you can
file an issue in the packer github that will be great.

As a workaround, please have in mind I am not a vmware expert so
please forgive me..


I understand you can attach a VMX file, like a post VMX file once the
machine has been built. basically you upload one to use the vmdk disk
generated.


vmx_data_post (object of key/value strings) - Identical to vmx_data,
except that it is run after the virtual machine is shutdown, and
before the virtual machine is exported.

vmx_template_path (string) - Path to a configuration template that
defines the contents of the virtual machine VMX file for VMware. This
is for advanced users only as this can render the virtual machine
non-functional. See below for more information. For basic VMX
modifications, try vmx_data first.

[Gregory Ruiz-Ade]

On Thursday, March 19, 2015 at 6:07:04 PM UTC-7, Alvaro Miranda Aguilera wrote:

On Fri, Mar 20, 2015 at 12:19 PM, Gregory Ruiz-Ade
<gregory....@gmail.com> wrote:
>     vmware-iso: Unmounting floppy from VMX...
>     vmware-iso: Detaching ISO from CD-ROM device...

Hello,

If you can please share json template file to reproduce, or you can
file an issue in the packer github that will be great.

So, interesting data point:

If I build the VM in headless mode, packer fails to detach the ISO. If I build and disable headless, it works properly.

I'm going to poke at this for a bit more.. If I can't suss anything else out, I'll post my JSON template.

Thanks,

Gregory 

[Ruben Alves]

Hello,

Maybe it's a Kickstart related issue.

Somehow, reboot doesn't work properly.  Please check your ks.cfg if you're using this feature on your kickstart.

The work around is to add the umount on the post install 

https://bugs.centos.org/view.php?id=3584

Kind regards.

[Blake Garner]

I am also seeing this issue and have for a while. Today I attempted to use the vmx_data_post and in the debug log it shows the apparently successful actions being taken. When I look at the resulting .vmx file the changes are not present. My guess is that the .vmx file is still locked when packer is attempting to make changes both unmounting the .iso and doing the vmx_data_post. I'm going to file a bug unless I find an existing one. 

Blake

[Anthony Spring]

This is my PR related to the issue from over a year ago, where essentially VMWare says its done with the vmx file but actually isnt, so packers changes get overwritten.

https://github.com/mitchellh/packer/pull/903

--
You received this message because you are subscribed to the Google Groups "Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Blake Garner]

Ok I see that one is closed now. I opened a new bug today. 

https://github.com/mitchellh/packer/issues/2026

Thanks,

Blake