The value in the Name field returned by 'esxcli network vm list'
actually returns the VMs `displayName`. As such, we need to match
against `displayName` to discover the VMs 'WorldID'.
'WorldId' is ultimately used/needed as an argument in the command that
returns the VMs IP.
Some platforms with incomplete XHCI implementations (i.e. FreeBSD)
will poll the bus despite there being no usb devices available.
This disables XHCI by default and documents how to enable it using
the vmx_data option.
This closes issue #5961.
The ESX5 driver doesn't have a way of mapping the network name to its device name because a .vmx template uses different field names for it and so packer let's ESX handle filling this in. This patch will check to see if the driver that packer determines is missing a NetworkMapper implementation (by checking for nil). If it is, then fall back to using "nat" despite ESX not using the network type at all. This is what packer did prior to exposing the network type to the user back in version 1.1.3.
This closes issue #5916.
arizvisa: Updated icnocop's documentation to include the possible disk adapter types that one can specify.
arizvisa: Tweaked icnocop's support for the `disk_adapter_type` option to the VMWare builder that caused conflicts due to version skew.
icnocop: Updated links to the Virtual Disk Manager User's Guide PDF to open in a new window and also added the Adobe PDF icon
icnocop: Added support for vmware to specify the disk adapter type, ide or scsi (lsilogic or buslogic)
Included the yield option to all the serial port types.
Added the ability for the network type to fallback to a custom network if the
specified network name is not found in netmap.conf.
Promoted the scope for both Read{Dhcp,Netmap}Config inside vmwcommon.driver.
Updated the documentation for the VMware builder.
builder/vmware/{iso,vmx}:
Added the specific configuration options that get parsed.
Normalize paths when pulling them from the json template so that they'll work on Windows too.
Added some improved error checking when parsing these options.
Stash the vm's network connection type so that other steps can figure out addressing information
Modified the esx5 driver to support the new addressing logic.
Modified the template in step_create_vmx to include the new options.
builder/vmware/common:
Implemented a parser for vmware's configuration files to the vmware builder.
Modified the driver's interface to include support for resolving both guest/host hw and ip addresses
Implemented a base structure with some methods that implement these features.
Rewrote all ip and mac address dependent code to utilize these new methods.
Removed host_ip and guest_ip due to their logic being moved directly into a
base-structure used by each driver. The code was explicitly checking runtime.GOOS
instead of portably using net.Interfaces() anyways.
Updated driver_mock to support the new addressing methods
Run now takes a context as well as a statebag. We'll assign the context
to the blank identifier to prevent namespace collisions. We'll let the
step authors opt-in to using the context.
`find . -iname "step_*.go" -exec gsed -i'' 's/func \(.*\)Run(/func \1Run(_ context.Context, /' {} \;`
This commit adds a new option, `vmx_remove_ethernet_interfaces`, to both
of the VMWare builders. This is useful when building Vagrant boxes,
since Vagrant now produces output such as:
```
WARNING: The VMX file for this box contains a setting that is
automatically overwritten by Vagrant when started. Vagrant will stop
overwriting this setting in an upcoming release which may pre vent
proper networking setup. Below is the detected VMX setting:
ethernet0.pcislotnumber = "33"
If networking fails to properly configure, it may require this VMX
setting. It can be manually applied via the Vagrantfile:
Vagrant.configure(2) do |config|
config.vm.provider :vmware_fusion do |vmware|
vmware.vmx["ethernet0.pcislotnumber"] = "33"
end
end
```
This can be avoided entirely by removing the ethernet adapters from the
VMX file prior to packaging as a Vagrant box, in which case adapters are
created as expected according to the Vagrantfile specification.
This option allows to set the extension of the ISO file after download.
Defaults to "iso". It makes sense for building Mac OS X guests, where the
bootable image is actually a DMG, not an ISO.
In particular, it is important for "parallels-iso" builder to set the right extension.
Ensure that all builders include FloppyDirectories in the StepCreateFloppy options.
Changed the way the unit-tests in common/step_create_floppy_test work to use the static test-fixtures directory instead of creating the paths dynamically.
Removed a duplicate line of documentation from parallels-pvm.html.md that occurred during rebasing.
Moved the support for recursive paths from the floppy_files keyword to the new floppy_contents keyword.
Shifted some of the code around to add better logging of what's actually being copied.
Added a couple of unit-tests for the new floppy_contents implementation.
Ensured that all files that were being added were also being included in state.FilesAdded so that the older unit-tests will work.
* The remotedisplay.vnc.ip vmx data key breaks ESXi, this commit prevents it
from being automatically added during VNC configuration when using the ESX5
driver.
* It can still be configured via the vmx_data section of the builder
template
Signed-off-by: Sunjay Bhatia <sbhatia@pivotal.io>
When debugging a build (or maintaining an existing packer file), teach `packer build -debug` how to step through individual `boot_command`s in order to triage the packer file.
```
==> vmware-iso: Typing the boot command over VNC...
==> vmware-iso: Pausing after run of step 'boot_command[0]: <enter><wait>'. Press enter to continue.
==> vmware-iso: Pausing after run of step 'boot_command[1]: <enter><wait>'. Press enter to continue.
==> vmware-iso: Pausing after run of step 'boot_command[2]: freebsd-vagrant<enter><wait>'. Press enter to continue.
==> vmware-iso: Pausing after run of step 'boot_command[3]: <down><spacebar>'. Press enter to continue. ^C
```
Prevalidates hardware resources on Linux platforms for Virtualbox and
VMware builders. This is currently only available on Linux, as enabling
for both Darwin and Windows platforms, relies on cgo bindings that would
prevent effective cross-compilation.
Packer will now fail to build and validate templates if the template is
requesting that the VM to be created would allocate more system
resources than the host system has available.
This _however_ doesn't catch parallel builds that overflow the hosts
resources, will probably still need a better error message for VM's
failing to boot in that case.
Example Outputs:
```
$ $GOPATH/bin/packer build -debug ./vmware-iso.json
Debug mode enabled. Builds will not be parallelized.
vmware-iso output will be in this color.
2 error(s) occurred:
* Unavailable Resources: RAM - Requested - 204800000MB - Available 21721MB
* Unavailable Resources: Disk - Requested - 4000000000MB - Available 76701MB
```
```
$ $GOPATH/bin/packer build -debug ./vbox-iso.json
Debug mode enabled. Builds will not be parallelized.
virtualbox-iso output will be in this color.
2 error(s) occurred:
* Unavailable Resources: RAM - Requested - 10240000MB - Available 21721MB
* Unavailable Resources: Disk - Requested - 1000000000MB - Available 76701MB
```
* I suspect the logic written for checking if the vm has been destroyed is incorrect. The test will come back from the esx server indicating that the vm is gone as it should, but the logic I believe is reversed so we never hit the break in the if statement
* Feedback is MORE than welcome