Add support for the VMware Workstation Pro API with the vmware-vmx builder

niwamo commented 12 months ago

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request. If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Description

Create a new "driver" for vmrest, the API that ships with VMWare Workstation Pro. Due to API limitations, only the vmware-vmx builder can be implemented.

Use Case(s)

Implement the vmware-vmx functionality using the API. Enables using Packer from a remote host or from a container.

Potential configuration

Already implemented and ready for a PR. See https://github.com/niwamo/packer-plugin-vmware.

I also updated /docs/builders/vmx.mdx and ran .web-docs/scripts/compile-to-webdocs.sh.

Opening an issue for discussion prior to making the PR, as directed in the README.

The code is reasonably well-commented, and I endeavored to limit changes outside of the new driver file to the greatest extent possible. Please take a look and lmk if/when you're ready for a PR.

Potential References

If you'd like to repeat my tests:

Set the API credentials on the VMWare host
Run the API
Install the updated plugin in a WSL container
Create a new VM using the "New Virtual Machine" menu in VMWare
- Assign a Debian .iso for the installer, but don't run the VM
Use the created .vmx filepath in a configuration like the following:

packer {
  required_plugins {
    vmware = {
      version = ">= 1.0"
      source = "github.com/niwamo/vmware"
    }
  }
}

source "vmware-vmx" "vmrest" {
  remote_type     = "vmrest"
  remote_host     = // the VMWare host's WSL interface IP
  remote_port     = 8697
  remote_username = // username you set for the API
  remote_password = // password you set for the API
  skip_export     = true

  source_path = // vmx filepath - make sure all backslashes are doubled/escaped, e.g. "C:\\Users\\test.vmx"

  vnc_bind_address  = "0.0.0.0"

  http_content = {
    "/preseed.cfg" = file("./preseed.cfg")
  }

  boot_wait    = "10s"
  boot_command = [
    "<esc><wait>",
    "auto url=http://{{ .HTTPIP }}:{{ .HTTPPort }}/preseed.cfg",
    "<enter>"
  ]

  ssh_username      = // user created by the preseed
  ssh_password      = // pwd for user created by the preseed
  ssh_timeout       = "30m"
  shutdown_command  = "shutdown -P now"
}

build {
  sources = ["sources.vmware-vmx.vmrest"]
  provisioner "shell" {
    script = "./scripts/test-1.sh"
  }
}

Note that this test config requires

a valid "preseed.cfg" to be present
a valid "./scripts/test-1.sh" to be present
your Windows firewall to allow all inbound connections from your WSL distro

niwamo commented 12 months ago

Thought of a couple things to add --

First, if you want to follow my testing methodology as described above, you'll need to proxy incoming connections, as the VMRest API only listens on localhost (127.0.0.1). You can achieve this with a port proxy: netsh interface portproxy add v4tov4 listenport=8697 listenaddress=0.0.0.0 connectport=8697 connectaddress=127.0.0.1.

Secondly, the WSL firewall rule I mentioned can be accomplished with: New-NetFirewallRule -DisplayName "Allow all WSL inbound" -Direction Inbound -InterfaceAlias "vEthernet (WSL)" -Action Allow

Finally, I added more details to my documentation updates in https://github.com/niwamo/packer-plugin-vmware

tenthirtyam commented 2 months ago

Now that VMware Workstation 17.6 has been released (and VMware Fusion 13.6), I can share that we (HashiCorp + VMware) plan to drive this towards the use of the new vmcli in the plugin.

Release Notes excerpt:

"vmcli is a command-line tool included with VMware Workstation Pro, enabling users to interact with the hypervisor directly from a Linux or macOS terminal, or the Windows command prompt. With vmcli, you can perform a variety of operations such as creating new virtual machines, generating VM templates, powering on VMs, and modifying various VM settings. Additionally, you can also create scripts to run multiple commands sequentially."

vmcli will eventually replace both vmrun and vdisk-manager and we'll work to update this plugin to use this method for the next major (v2) and remove deprecations.

Ryan Johnson Distinguished Engineer, VMware by Broadcom

hashicorp / packer-plugin-vmware