0.7.0 bug

[synergiator]

Upstream bug: cloudstack_port_forward fails for project-scoped VMs with account-level keys

Placeholder	Meaning
<ACCOUNT_KEY_NAME>	Name of the account-level API key profile
<PROJECT>	CloudStack project name
<PROJECT_ID>	CloudStack project UUID
<VM_ID_WEB>	UUID of the web VM
<VM_ID_BASTION>	UUID of the bastion VM
<VM_NAME_WEB>	Name of the web VM
<VM_NAME_BASTION>	Name of the bastion VM
<ORG>	Organisation running a downstream fork
<ORG_FORK_PATH>	Local path of the downstream fork

Summary

cloudstack_port_forward create fails with No match found for <vm-id>: &{Count:0 VirtualMachines:[]}
when the API key is account-level (e.g. <ACCOUNT_KEY_NAME>) and the target VM lives in a project.
createPortForward calls GetVirtualMachineByID without a projectid, and account-level keys
cannot see project-scoped VMs without one. This is a bug (same class as #319, merged for the
data source), not a feature gap.

Reproduction

Throw-away VPC test against the real <PROJECT> backend (<ACCOUNT_KEY_NAME> account-level key,
project <PROJECT>):

cloudstack_port_forward.this[0]: Creating...
Error: No match found for <VM_ID_BASTION>: &{Count:0 VirtualMachines:[]}

The VM exists and is Running. Proven via CloudMonkey:

$ cmk -p <ACCOUNT_KEY_NAME> list virtualmachines filter=id,name                          # no projectid
   (no output — 0 VMs visible to the account-level key)

$ cmk -p <ACCOUNT_KEY_NAME> list virtualmachines projectid=<PROJECT_ID> filter=id,name   # with projectid
  { "count": 2, "virtualmachine": [
      { "id": "<VM_ID_WEB>",      "name": "<VM_NAME_WEB>" },
      { "id": "<VM_ID_BASTION>",  "name": "<VM_NAME_BASTION>" } ] }

Root cause

Upstream createPortForward queries the VM with no project filter, hard-coding a false assumption:

cloudstack/resource_cloudstack_port_forward.go:197-200 (apache/cloudstack-terraform-provider, v0.7.0 == HEAD)

// Query VM without project filter - it will be found regardless of project
vm, _, err := cs.VirtualMachine.GetVirtualMachineByID(
    forward["virtual_machine_id"].(string),
)

The SDK's GetVirtualMachineByID accepts WithProject(...) and sets projectid on the
listVirtualMachines call (apache/cloudstack-go, VirtualMachineService.go:4667;
ListVirtualMachinesParams.SetProjectid at :4314). The project attribute is already
populated on the resource by the time createPortForward runs — it is inherited from the IP
address in resourceCloudStackPortForwardCreate (:124-134, added by #280). It is simply never
passed to the VM lookup.

This is the same bug #319 fixed — for the data source only

#319 "Fix cloudstack_instance data source ignoring project" (merged 2026-08-17) fixed the
identical root cause in the data.cloudstack_instance data source and shipped a regression test
whose comment states the bug plainly:

"instances deployed inside a project were never returned by the data source because
ListVirtualMachines was called without a projectid"

PR #319 patch (relevant hunk), cloudstack/data_source_cloudstack_instance.go:

 p := cs.VirtualMachine.NewListVirtualMachinesParams()
+
+// If there is a project supplied, we retrieve and set the project id
+if err := setProjectid(p, cs, d); err != nil {
+    return err
+}
+
 csInstances, err := cs.VirtualMachine.ListVirtualMachines(p)

#319 touched the data source only. The resource create path (createPortForward) was missed and
still carries the wrong assumption as a comment.

A downstream fork already carries the fix

A downstream fork at <ORG_FORK_PATH> already passes the project to the VM lookup, confirming
the pattern:

cloudstack/resource_cloudstack_port_forward.go:149-151

vm, _, err := cs.VirtualMachine.GetVirtualMachineByID(
    forward["virtual_machine_id"].(string),
    cloudstack.WithProject(d.Get("project").(string)),
)

Proposed upstream fix (one-liner, mirrors #319 + the downstream fork)

// Pass the project so account-level keys can resolve project-scoped VMs.
vm, _, err := cs.VirtualMachine.GetVirtualMachineByID(
    forward["virtual_machine_id"].(string),
    cloudstack.WithProject(d.Get("project").(string)),
)

Plus a regression test mirroring TestAccInstanceDataSource_project (a project-scoped VM + a
project-less API key asserting the rule is created).

Classification & version target

• Bug, not feature. The API supports projectid on listVirtualMachines (proven above); the
  provider omits it on one call site. Fix cloudstack_instance data source ignoring project #319 establishes both the bug class and the fix pattern.
• Severity: blocks cloudstack_port_forward create for any account-level key used against
  project-scoped VMs — a common real-world setup (the <ACCOUNT_KEY_NAME> key in this environment).
• Target: backport to 0.7.1 (bug fix). No 0.7.1 milestone exists; the only open milestone
  is 0.8.0 (11 open / 2 closed). v0.7.0 shipped 2026-09-15, HEAD == v0.7.0 (zero commits since
  tag), so the fix is not yet on any release branch.
• No open issue tracks this (only Fix secgroups targeting other secgroups in projects #352, unrelated secgroups-in-projects, is currently open).

Local test workaround

Until upstream ships the fix, the throw-away VPC test uses the fork build via Terraform
dev_overrides (the fork already carries the fix at :151). dev_overrides affects local runs
only; nothing is published to a registry.