Skip to content

VMware vSphere: AI assistant (LLM)

If you are deploying with an AI coding assistant (Claude, Codex, and similar), copy the prompt below and paste it into your assistant. It drives the same ovftool flow as the CLI (ovftool) guide, but written for the assistant to follow step by step, pausing for your confirmation and for the values only you can supply.

Before you paste

Give the assistant a session that already has VMware OVF Tool (ovftool) installed (verify with ovftool --version) and your vCenter or ESXi credentials on hand (an agentic tool with shell access, or paste the commands it returns into your own terminal). Have your engagement lead's values ready: the OVA URL or file path, the vCenter/ESXi host, and the datacenter, datastore, cluster or resource pool, and network port group to deploy into. The assistant will ask for anything it is missing.

Deployment prompt

You are helping me deploy the Sophos Remote Testing Appliance (RTA) as a virtual
machine on VMware vSphere, using VMware OVF Tool (ovftool). Work through the steps
below in order. Before any command that changes state, tell me what it will do and
wait for my confirmation.

CONTEXT:
- The appliance ships as a single OVA file that my engagement lead provides. It is
  customized for my engagement before I receive it: the OVA bundles the appliance's
  root disk and a small cidata seed disk, and one deploy attaches both. The OVA
  descriptor also sets the VM's firmware (EFI with Secure Boot off) and hardware
  version (vmx-13, which needs ESXi 6.5 or later), so there is nothing to change
  before power-on. There is no software to install and no inbound access. The
  appliance boots already registered and brings up its outbound tunnel on its own;
  there is no code to read and nothing for me to activate.

WHAT I WILL PROVIDE (ask me for any you do not have; never guess these):
- <OVA_URL_OR_PATH>: the OVA download URL or local .ova file path.
- <VCENTER_HOST>: the vCenter Server FQDN or IP (or an ESXi host FQDN/IP for a direct deploy).
- <USER>: a vCenter or ESXi username with permission to create VMs (for example administrator@vsphere.local).
- <DATACENTER>: the datacenter name as shown in vSphere Client (vCenter deploys only).
- <CLUSTER_OR_HOST>: the cluster name or ESXi hostname within that datacenter (vCenter deploys only).
- <DATASTORE>: the datastore that will hold the VM disks.
- <NETWORK>: the port group with Layer-2 access to the engagement targets (not an isolated, NAT, or management-only network).

STEPS:
1. Confirm ovftool is installed and recent enough (4.6 or later):
   ovftool --version
   If it is missing or older, stop and tell me. Do not try to install or upgrade it
   yourself.

2. Deploy the OVA to vCenter with a single ovftool command. This creates the VM,
   attaches both disks, applies the OVA's EFI / Secure-Boot-off / vmx-13 settings, and
   powers the VM on. Do NOT change the firmware, boot type, or hardware version; they
   are correct as shipped.
   ovftool \
     --acceptAllEulas \
     --noSSLVerify \
     --name=Sophos-RTA \
     --datastore=<DATASTORE> \
     --network=<NETWORK> \
     --diskMode=thin \
     --powerOn \
     <OVA_URL_OR_PATH> \
     "vi://<USER>@<VCENTER_HOST>/<DATACENTER>/host/<CLUSTER_OR_HOST>/"
   ovftool prompts for the password. If I am targeting a standalone ESXi host instead
   of vCenter, use the target "vi://<USER>@<VCENTER_HOST>/" (no datacenter or cluster
   path) and tell me before you run it.

3. Wait for the import task to finish (typically 2 to 10 minutes, depending on OVA
   size and network speed). ovftool prints its progress; report the result to me.

VERIFY:
4. Confirm the VM is powered on and has picked up an address once it has booted:
   govc vm.info Sophos-RTA
   govc vm.ip Sophos-RTA
   If you do not have govc, tell me and check the power state in the vSphere Client
   instead.

5. Open the VM console in the vSphere Client (Launch Web Console) and confirm what it
   shows. The appliance is pre-registered, so the console displays a live status and
   troubleshooting dashboard: network interface, VPN tunnel, and connectivity health.
   The outbound tunnel comes up on its own within a few minutes. There is no code to
   read and nothing for me to activate. If the dashboard reports a problem, tell me
   exactly what it shows.

RULES YOU MUST FOLLOW:
- These steps are authoritative. If a command fails, returns something unexpected,
  or reality does not match what is written here, STOP and show me the exact output.
  Do not improvise, invent flags, or try alternative commands on your own.
- The appliance needs exactly ONE connection: an outbound tunnel on TCP/443 to
  connect.remotetesting.secureworks.com. Never open, forward, or allow any INBOUND
  port to it. If connectivity fails, the problem is on the outbound path, never a
  missing inbound rule.
- Never enable Secure Boot and never change the firmware or boot type away from what
  these steps specify (UEFI / Generation 2). The appliance will not boot otherwise.
- Do not SSH into, log in to, or reconfigure the appliance. Once it boots it
  provisions itself; there is nothing to set up inside it.
- Every value in angle brackets (<LIKE_THIS>) must come from me. Never guess, invent,
  or reuse one. Ask me for any you do not have before running the step that needs it.
- Do not weaken security to force the connection (do not disable TLS inspection, and
  do not turn off a firewall). If something is blocked, tell me what and let me decide.
- Do only what these steps describe: deploy this one appliance. Do not create extra
  resources, install extra software, or take any action beyond that.

Network access

The appliance makes one connection to do its job: an outbound tunnel to the Sophos headend. Nothing inbound is ever required: you never open or forward any ports to the appliance.

Allow this outbound destination

Destination connect.remotetesting.secureworks.com
IP addresses 3.33.194.251 and 15.197.255.2 (static; these do not change)
Port / protocol TCP 443, carrying OpenVPN (not HTTPS)
Direction Outbound only

Allow egress on TCP/443 to that destination from the appliance's network. On a next-generation firewall or NAC-controlled network, an L3 "allow 443" rule is often not enough: Layer-7 application control, TLS/SSL decryption, or NAC can still drop the tunnel even when the port is open. See Connectivity troubleshooting for the exact firewall and NAC exceptions to request.

Troubleshooting

Deployed but something isn't right?

See this platform's troubleshooting guide for the most common issues here and how to fix them.