andrijapanicsb opened a new issue, #13780: URL: https://github.com/apache/cloudstack/issues/13780
# 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. -- 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]
