Chained remote vmware builds

[Jimmy The Dog]

Hi All,

First of all, please excuse the longish post...

We tend to build a standard base OS ova from an iso and, from that ova artifact, build other ova's - sometimes even building on top of those

For Virtualbox, we are able to use the virtualbox-iso builder to build the base ova from the iso, and the virtualbox-ovf builder to build ova's from other ova's - and this has worked fine for us.

We also want to perform the same workflow, but using remote ESXi hosts, to produce ova's that were built on ESX (yes, I know in theory we should be able to use the vbox ova's on VMware, but there is resistance internally to trust it ATM)

So, the first part (building the base OS ova from an iso) is fine using the vmware-iso builder and its remote_* properties

However, we then came to a grinding halt, as there is no vmware-ova builder, and the vmware-vmx builder does not support remote building - so, we have developed a vmware-esx-ova builder that does what we want

My questions are:

1. Did we need to do this i.e. is there something that already does this? And...
   
2. Would there be any "appetite" in me raising a Jira and creating a PR in an attempt to get this adopted into core packer?
   

Many thanks for you patience

Kevin

[Rickard von Essen]

Hi Kevin,

I think this is definitely a missing feature that we would like to have in Packer (builder/vmware-vmx with support for remote ESXi). Just 3 days ago the was a PR opened which adds this support, https://github.com/mitchellh/packer/pull/4591 . It might not make it to the 1.0 release so I recommend that you do a private build of the PR-branch and provide testing for it.

// Rickard

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
---
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/b7e19e28-ada7-41ff-90da-80fb4e38126b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jimmy The Dog]

Hi Rickard,

Thank you very much for the pointer to that PR

It looks promising, but doesn't quite fit in with our workflow, and I'll try to explain why...

• The `source_path` property points to the `.vmx` file (and associated `.vmdk` files) on the *remote* machine, whereas, we have the source files locally (they're downloaded as dependencies from a nexus repository)
  
• Also, the `output_directory` appears to also be a directory on the remote machine - we use it as a local directory where the VM is exported to after the build has completed
  

To summarise, it appears that the source & output files are stored on the remote ESXi server.

Our workflow is as follows:

1. The source files (`.vmx`, `vmdk`) are downloaded from a nexus repository
   
2. The local `.vmx` (pointed to by `source_path`) is imported to the remote ESXi server (using `ovftool`)
3. Build steps execute...
4. The VM is then exported to the `output_directory` (again, using `ovftool`)
5. The files in `output_directory` are then published to nexus (which could then be used by another builder, if so desired)

One disadvantage of the PR mechanism, is that we use multiple ESXi servers for building, so simply leaving a VM on ther to be cloned by another builder won't really work, as it could be on a different server?

Again, sorry for the long post, and may thanks for your help

Kevin

To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool...@googlegroups.com.