* Fix NPE while cloudstack agent failed to connect to mgt server
If `ramOvercommitRatio` field is missing in user_vm_details table
is missing then agent throws NPE after restarting
It is because in user_vm_details, there are 'cpuOvercommitRatio' for all
vms, but for vms the field 'ramOvercommitRatio' is missing in the table.
* code feedback
* server: delete template on storage over capacity threshold
While deleting template for a specific zone, check should be done only for writable secondary storages and not for storages with available capacity threshold.
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
* fix for ISOs and refactor
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
* remove writable store check
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
* fix exception message
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
This fixes the ostype ID returned in listUsageRecords API response to
be uuid instead of internal DB ID and also returns the os category ID
(uuid) and name.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
The `account` is no longer set in the listProjects API response that is
still mentioned in the API docs. API consumers should now use the
`owner` key from the listProjects API response which returns a list of
owners (accounts and users).
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
* novnc: Add client IP check for novnc console in cloudstack 4.16
* novnc ip check : Fix restart CPVM or mgt server does not update novnc param
* novnc ip check: move to method
* server: fix failed to remove template/iso if upload from local fails
When upload template/iso/volume from local fails, the install_path will not be a full path of file so removing it will fail.
```
mysql> select install_path from template_store_ref;
+--------------------------------------------------------------------+
| install_path |
+--------------------------------------------------------------------+
| template/tmpl/1/3/805f4763-248e-40ec-b79a-b868cc480d0a.qcow2 |
| template/tmpl/1/4/c7e32c9e-5e72-3726-85cf-aa5ccd84118d.qcow2 |
| template/tmpl/2/201/bc4f4f08-138a-31b8-af1a-d4450eff7982.qcow2 |
| template/tmpl/2/202 |
| template/tmpl/2/203/203-2-d47f8cde-a2a8-31e7-a826-2628ad98a6c8.iso |
| template/tmpl/2/204 |
| template/tmpl/5/205 |
| template/tmpl/2/206 |
| template/tmpl/2/207 |
| template/tmpl/2/208 |
| template/tmpl/2/209 |
| template/tmpl/2/210 |
+--------------------------------------------------------------------+
12 rows in set (0.00 sec)
mysql> select install_path from volume_store_ref;
+---------------------------------------------------------+
| install_path |
+---------------------------------------------------------+
| volumes/2/22 |
| volumes/2/19/f93face9-6521-4184-b89a-cb07f86bbae8.qcow2 |
| volumes/2/23 |
| volumes/2/24 |
+---------------------------------------------------------+
4 rows in set (0.00 sec)
```
* server: disallow removing template/iso in NotUpload and UploadInProgress state
When running get_bridge_physdev(brname) from security_group.py it is returned the bridge device as brname: instead of the expected brname.
We experienced this issue on CloudStack 4.13.1.0 with Security Groups enabled for Advanced Networking. Additionally, KVM nodes are running on Ubuntu 18.04.
PR #4303 (merged in 4.15) added support for Ubuntu 20.04 which turned out to fix get_bridge_physdev(brname); however, we faced the very same issue with the previous CloudStack and Ubuntu versions.
Even though we might not get a 4.13.2, and CloudStack 4.14.1.0 has just been released, this PR proposes merging the fix into branch 4.13 and then get it forwarded into 4.14. Thus, allowing users to have this fix referenced and also opening the possibility of addressing this in case of a potential 4.14.2.0.
While finding pools for volume migration list following compatible storages:
- all zone-wide storages of the same hypervisor.
- when the volume is attached to a VM, then all storages from the same cluster as that of VM.
- for detached volume, all storages that belong to clusters of the same hypervisor.
Fixes#4692Fixes#4400
These changes are related to PR #3194, but include suspending/resuming the VM when doing a VM snapshot as well, when deleting a VM snapshot, as it is performing the same operations via Libvirt. Also, there was an issue with the UI/localization changes in the prior PR, as that PR was altering the Volume snapshot behavior, but was altering the VM snapshot wording. Both have been altered in this PR.
Issuing this in response to the work happening in PR #4029.
If the template from which VR is created got deleted, the state
is set to inactive and removed to null.
Since the template is already deleted, the VR can't be created
using this template again.
If someone restarts network with cleanup then it will try to
deploy the vr from the old non existing template again.
So search only for active template which are not yet deleted.
When adding a cluster from existing host-datacenter UI shoudl list and autofill host, DC name while making addCluster API call.
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
This PR aims at restoring the previous level of leniency in listing templates on stores that have been marked as deleted / removed by updating the DB.
While Cloudstack doesn't allow deleting stores that have resources on them, it may so happen that users may mimic a deletion of a store by merely updating the DB. Under such a case, listing of templates is hampered due to an NPE that is caused. (as seen in #4606)
Co-authored-by: Pearl Dsilva <pearl.dsilva@shapeblue.com>
