---
description: >
  The Packer vSphere Template post-processor takes an artifact from the
  VMware-iso builder, built on ESXi (i.e. remote) or an artifact from the
  [vSphere](/docs/post-processors/vsphere) post-processor, marks the VM as a
  template, and leaves it in the path of your choice.
page_title: vSphere Template - Post-Processors
sidebar_title: vSphere Template
---

# vSphere Template Post-Processor

Type: `vsphere-template`
Artifact BuilderId: `packer.post-processor.vsphere`

The Packer vSphere Template post-processor takes an artifact from the
VMware-iso builder, built on ESXi (i.e. remote) or an artifact from the
[vSphere](/docs/post-processors/vsphere) post-processor, marks the VM as a
template, and leaves it in the path of your choice.

## Example

An example is shown below, showing only the post-processor configuration:

```json
{
  "type": "vsphere-template",
  "host": "vcenter.local",
  "insecure": true,
  "username": "root",
  "password": "secret",
  "datacenter": "mydatacenter",
  "folder": "/packer-templates/os/distro-7"
}
```

## Configuration

There are many configuration options available for the post-processor. They are
segmented below into two categories: required and optional parameters. Within
each category, the available configuration keys are alphabetized.

Required:

- `host` (string) - The vSphere host that contains the VM built by the
  vmware-iso.

- `password` (string) - Password to use to authenticate to the vSphere
  endpoint.

- `username` (string) - The username to use to authenticate to the vSphere
  endpoint.

Optional:

- `datacenter` (string) - If you have more than one, you will need to specify
  which one the ESXi used.

- `folder` (string) - Target path where the template will be created.

- `insecure` (boolean) - If it's true skip verification of server
  certificate. Default is false

- `keep_input_artifact` (boolean) - Unlike most post-processors, this option
  has no effect for vsphere-template. This is because in order for a template
  to work, you can't delete the vm that you generate the template from. The
  vsphere template post-processor will therefore always preserve the original
  vm.

- `snapshot_enable` (boolean) - Create a snapshot before marking as a
  template. Default is false

- `snapshot_name` (string) - Name for the snapshot. Required when
  `snapshot_enable` is `true`

- `snapshot_description` (string) - Description for the snapshot. Required
  when `snapshot_enable` is `true`

- `reregister_vm` (boolean) - Use the method of unregister VM and reregister
  as a template, rather than using the markAsTemplate method in vmWare.
  NOTE: If you are getting permission denied errors when trying to mark as a
  template, but it works fine in the vSphere UI, try setting this to false.
  Default is true.

## Using the vSphere Template with local builders

Once the [vSphere](/docs/post-processors/vsphere) takes an artifact from
the VMware builder and uploads it to a vSphere endpoint, you will likely want
to mark that VM as template. Packer can do this for you automatically using a
sequence definition (a collection of post-processors that are treated as as
single pipeline, see [Post-Processors](/docs/templates/legacy_json_templates/post-processors)
for more information):

```json
{
  "post-processors": [
    [
      {
        "type": "vsphere",
         ...
      },
      {
        "type": "vsphere-template",
         ...
      }
    ],
    {
      "type": "...",
      ...
    }
  ]
}
```

In the example above, the result of each builder is passed through the defined
sequence of post-processors starting with the `vsphere` post-processor which
will upload the artifact to a vSphere endpoint. The resulting artifact is then
passed on to the `vsphere-template` post-processor which handles marking a VM
as a template. Note that the `vsphere` and `vsphere-template` post-processors
are paired together in their own JSON array.

## Permissions

The vsphere post processor needs several permissions to be able to mark the
vm as a template. Rather than giving full administrator access, you can create
a role to give the post-processor the permissions necessary to run. Here is an
example role that will work. Please note that this is a user-supplied list so
there may be a few extraneous permissions that are not strictly required.

For Vsphere 5.5 the role needs the following privileges:

    Datastore.AllocateSpace
    Host.Config.AdvancedConfig
    Host.Config.NetService
    Host.Config.Network
    Network.Assign
    System.Anonymous
    System.Read
    System.View
    VApp.Import
    VirtualMachine.Config.AddNewDisk
    VirtualMachine.Config.AdvancedConfig
    VirtualMachine.Inventory.Delete

and either (If reregister_vm is false):

    VirtualMachine.Provisioning.MarkAsTemplate

or (if reregister_vm is true or unset):

    VirtualMachine.Inventory.Register
    VirtualMachine.Inventory.Unregister

And this role must be authorized on the:

    Cluster of the host
    The destination folder (not on Datastore, on the Vsphere logical view)
    The network to be assigned
    The destination datastore.

# Troubleshooting

Some users have reported that vSphere templates created from local VMWare builds
get their boot order reset to cdrom only instead of the original boot order
defined by the template. If this issue affects you, the solution is to set
`"bios.hddOrder": "scsi0:0"` in your builder's vmx_data.

Packer doesn't automatically do this for you because it causes strange upload
behavior in certain versions of ovftool.
