synergiator opened a new issue, #355:
URL: https://github.com/apache/cloudstack-terraform-provider/issues/355
# 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)
```go
// 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`:
```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`
```go
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)
```go
// 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. #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 #352, unrelated secgroups-in-projects,
is currently open).
## Local test workaround
Until upstream ships the fix, the throw-away VPC test uses the **<ORG>
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
