apache / apache/cloudstack

Import Instance (VMware to KVM): guest network is not scoped to the destination account, and the mismatch is only rejected after the disk copy has already run

Open
#13,780 2 comments 0 reactions 0 assignees View on GitHub
component:migration
Dominant language
Java
Stars
3.1k
Forks
1.4k
Avg merge
6d 19h
Merged PRs (30d)
32

Description

# Description

Two related problems, one in the UI and one in the API. Seen on a current main/4.23 build, but the behavior looks much older than that.

## 1. UI: the network dropdown ignores the destination account

In the Import Instance form (Tools > Import-Export Instances, "VMware migration mode", the VDDK mode that is selected by default), the guest network dropdown is already pre-filled before you pick the destination domain and account — and it happily preselects a network that belongs to some other account (in my case an isolated network owned by an account in a subdomain).

Changing the destination domain/account later does not re-filter the network list. So as admin you can very easily submit an import for account X with a network that belongs to account Y, without ever noticing.

The dropdown should only offer networks the chosen destination account (or project) can actually use, and it should re-populate when the domain/account selection changes.

## 2. API: the mismatch is only caught at the very end

`importVm` (and the same for the newer VMware migration APIs) accepts the account/network mismatch at submit time. The whole disk copy then runs — for a big VM that can be hours — and only the final import step fails, with:

```
NIC(ID: ...) needs a valid IP address ... / Unable to use network with id= ..., permission denied
```

So the expensive part of the work is done and thrown away, and the error shows up at the point where it is least useful.

The ownership check is clearly there — it just runs last. The same check should run up front, when the import is submitted, so a bad combination is rejected before any data is copied. (Resource limits behave the same way, by the way: an account already at its VM limit can start an import, the full copy runs, and the limit is only enforced at the end. Same idea — check it up front.)

# Steps to reproduce

1. Have a domain with an account, and an isolated network owned by that account.
2. As root admin, open Tools > Import-Export Instances, VMware migration mode.
3. Note the network preselected in the form — it can be the other account's network, before any domain/account was chosen.
4. Pick a different destination account, keep the preselected network, submit.
5. The import runs the full disk copy and fails at the last step with a permission error on the network.

# Expected

- The UI only offers networks that the selected destination account/project can use.
- The API rejects an account/network mismatch (and blown resource limits) at submit time, before any data is copied.

# Actual

- The UI preselects and offers networks across accounts.
- The API accepts the mismatch and fails only after the full copy, at the import step.

Contributor guide

Open the contributing guide

Research direction

Start with the Import Instance form at Tools > Import-Export Instances in VMware migration mode and the importVm and newer VMware migration API entry points. Reproduce the cross-account network selection and late failure; done means the UI filters and repopulates networks for the destination account or project, while the API validates network ownership and resource limits before disk copying.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend-api-design, cloud, frontend, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.