Why is the vmware-iso builder unregistering the VM from the ESXi after a succesful build ?

[Jean-Francois Gratton]

Good evening,

I've managed to build my Debian VM on our lab ESX server, but once the OS is installed, the VM rebooted and the 3 post-install scripts (defined in the "provisionners" template) executed and succesfull, the VM unregisters itself and disappears from the ESX server. Why is that ? How can I keep it there ?

I'm not running the vSphere post-processor (..yet), especially as it needs the ovftool (why ?) and it stumbles because it needs a cluster name and I don't run an ESX cluster, it's in our lab. Any way to avoid post-processors ?

Here's the packer build output (end of it, that is). 

==> vmware-iso: Provisioning with shell script: scripts/users.sh

    vmware-iso: Adding group `[groupName]' (GID 1000) ...

    vmware-iso: Done.

==> vmware-iso: Provisioning with shell script: scripts/cleanup.sh

    vmware-iso: sleeping 20 seconds before shutdown

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

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

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

    vmware-iso: Deleting: /vmfs/volumes/[DATASTORE]/[SOME_PATH]/[SOME_OTHER_PATH]/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

==> vmware-iso: Unregistering virtual machine...

Build 'vmware-iso' finished.

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

--> vmware-iso: VM files in directory: /vmfs/volumes//[DATASTORE]/[SOME_PATH]/output-vmware-iso

The JSON file is good, so is the preseed, as the install completes properly. I'm stuck right now..

--Jeff

[David Hekimian]

Haven't found a solution to keep packer from do this... To get it back SSH to the ESX host and run 'vim-cmd solo/registervm /vmfs/volumes//[DATASTORE]/[SOME_PATH]/output-vmware-iso.vmx' 

- David

[Dong Xie]

Second the question, would be great to have a simple tag in the JSON to say I want keep my VM after build. Having Packer de-register the VM first then we call vim-cmd to add it back is kind of "..."

Also would be great if we can run scripts in Post-Processors.

By reading around recent questions, I think lots of us are trying to build 'template' other than vmdk, i.e. we want OVF/OVA as final product, we may then even push those to various cloud platforms.

Packer might started to be a tool to just 'pack', but gradually we are pushing it into a key piece of the CI/CD story, e.g. instead of thinking run Packer once to have a VM for many user, what if we run Packer to build a VM for a single user, on-demand?

My 2 pence

[Jean-Francois Gratton]

Well, since I was thinking about a wrapper around my JSON config + preseed files to automate the batch creation of many VMs, adding a few commands to the ESX server shouldn't be a problem then. Thank you David for the suggestion.

I do agree with Xie on the futility of creating a VM and then unregister it. Especially as it's not that much documented (correct me if I'm wrong here). Also true for the evolution of Packer in the CI/CD ecosystem.

Thanks everyone !

-- Jeff

[Peter Loron]

This! I'd really like to have the option of the end product being a template, not a VM. Right now, I need to:

1. Re-register the VM.
   
2. Start VM.
3. Manually remove the ISO from being mounted in the CD.
4. Stop VM.
5. Convert to template.
6. Remove VM.

[Jean-Francois Gratton]

Do not forget to make sure that your CDROM device points to the client device, not to an ISO in some datastore on the ESX server. You'll be able to export to OVA/OVF, but once you try to deploy your OVA somewhere else, if the CDROM points to a datastore it will fail.

I guess that if by luck you happen to have a file with the same name in a datastore of the same name on that new ESX server, it might work, but I haven't tried that and wouldn't want to rely on pure blind luck.

--Jeff

[Yathindra Raj]

Hey Jean-Francois Gratton, 

                                             I think packer use case  was similar to what you tried .So needed a bit guidance in this.I have posted my issue (https://groups.google.com/forum/#!topic/packer-tool/0_kOXXLKhng) but no help .So thought of refering you for some pointers.Please help me out.

Thanks ,

Yethindra

[Jean-Francois Gratton]

Sorry I'm late answering.

Here's a quick way to get your VM configured and (almost) up and running.

Some pre-requisites:

1) admin access to the ESX server where your VM is being created with Packer, as well as onto the ESX server where it will ultimately end up (might be the same)

2) ovftool binaries

The process is a two- or three-steps process, depending if the VM will reside onto the same ESX server it has been created

1) Create the VM with Packer

   the VM will get unregistered from the ESX server once completed, but not destroyed; its artefacts will remain

2) Re-register the VM using vim-cmd (you will need to know where the VM's vmx file resides onto the ESX server)

If you plan on moving the VM onto another ESX server

3) Export the VM from the ESX server using ovftool

4) Import the resulting OVA file onto the target ESX server (admin access is required onto that server), again using ovftool

That's it. Everything is easily scriptable. That is your homework for today :-)

--Jeff

[Piotr Mitoraj]

It sounds like vSphere post-processor does not work with esxi. https://github.com/mitchellh/packer/issues/1457#issuecomment-54297049

I think that ovftool is required, because packer uses ovftool to export image (ova) of the vm, then it is downloaded and ovftool is used to deploy it to the vsphere endpoint.

Piotr