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
- 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
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