* fix error test unit on MigrateWizard
* fix error test unit on AutogenView, ActionButton
* fix error lint
* fix error pollJob originalPage.starWith undefined
* Update ui/src/utils/plugins.js
Co-authored-by: davidjumani <dj.davidjumani1994@gmail.com>
* Update ui/src/utils/plugins.js
Co-authored-by: davidjumani <dj.davidjumani1994@gmail.com>
* uses a substitution variable if the originalPage is null with queryAsyncJob have jobstatus = 1
* remove argument null
Co-authored-by: davidjumani <dj.davidjumani1994@gmail.com>
* Fix of shrinking volumes with QCOW2 format
If the volumes are with QCOW2 format the shrinking will be handled on
the agents side. There are cases in some storage plugins where the
volumes' format is kept in the DB in QCOW2 but the actual format is raw.
Till the current implementation this was limiting the plugins to shrink
the volumes. Now this will be handled by the storage plugins
* Addressed @nvazquez suggested change
Will log the exception instead the exception message
* refactor async job polling codebase-wide
* fix multiple call fetchData() when async job completed
* remove unnecessary functions
* remove const not use
* move closeaction out of handleResponse
* call closeAction without waiting for all group actions to complete
* refactor polljob network provider
* removed variable not use
* remove await
On newer libvirt/qemu it seems PCI hot-plugging could be an issue as
seen in:
https://www.suse.com/support/kb/doc/?id=000019383https://bugs.launchpad.net/nova/+bug/1836065
This was found to be true on ARM64/aarch64 platform (tested on
RaspberryPi4). As per the default machine doc, it advises to
pre-allocate PCI controllers on the machine and pcie-to-pci-bridge based
controller for legacy PCI models:
https://libvirt.org/pci-hotplug.html#x86_64-q35
This patch introduces the concept as a workaround until a proper fix is
done (ideally in the upstream libvirt/qemu projects). Until then client
code can add 32 PCI controllers and a pcie-to-pci-bridge controller for
aarch64 platforms.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
* server: fix failed to apply userdata when enable static nat
* server: fix cannot expunge vm as applyUserdata fails
* configdrive: fix ISO is not recognized when plug a new nic
* configdrive: detach and attach configdrive ISO as it is changed when plug a new nic or migrate vm
* configdrive test: (1) password file does not exists in recreated ISO; (2) vm hostname should be changed after migration
* configdrive: use centos55 template with sshkey and configdrive support
* configdrive: disklabel is 'config-2' for configdrive ISO
* configdrive: use copy for configdrive ISO and move for other template/volume/iso
* configdrive: use public-keys.txt
* configdrive test: fix (1) update_template ; (2) ssh into vm by keypair
* ui: refactor get api params in forms
Refactor code getting api params for APIs in UI forms.
Added a new util plugin in plugins.js
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
* fix
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
* fix
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
* Change logrotate interval to hourly
The logrotate config says interval as hourly but it relies
on timer service to be invoked but in timer the frequency
is mentioned as 12h. So it wont be invoked every hour.
So change the frequency to hourly
* Add change to vpc router
This PR fixes the issue that nic has wrong gateway after updating vm nic.
Steps to reproduce the issue
(1) create shared network (in advanced zone or advanced zone with sg)
(2) create new shared network (with same startip/endip/netmask, but different gateway).
(3) create a vm in new network
(4) stop vm and update vm nic ip address
Expected result:
The vm has correct gateway and netmask (of second network)
Actual result:
The vm has wrong gateway and netmask (of first network)
* vxlan: arp does not work between hosts as multicast group is communicated over physical nic instead of linux bridge
when linux bridge is setup (refer to http://docs.cloudstack.apache.org/projects/archived-cloudstack-getting-started/en/latest/networking/vxlan.html#configure-product-to-use-vxlan-plugin) and used as the kvm traffic label of physical networks, the vms on different hosts cannot reach each other.
(1) does not work:
```
/usr/share/cloudstack-common/scripts/vm/network/vnet/modifyvxlan.sh -v 1001 -p eth1 -b brvx-1001 -o add
```
"bridge fdb" shows
```
00:00:00:00:00:00 dev vxlan1001 dst 239.0.3.233 via eth1 self permanent
```
(2) this works:
```
/usr/share/cloudstack-common/scripts/vm/network/vnet/modifyvxlan.sh -v 1001 -p cloudbr1 -b brvx-1001 -o add
```
"bridge fdb" shows
```
00:00:00:00:00:00 dev vxlan1001 dst 239.0.3.233 via cloudbr1 self permanent
```
* vxlan: fix issue if kvm network label is not set
* Cover a case where resizing root disk failed; add isNotPossibleToResize method.
* remove format from resize validation
* Revert if-conditional changes that removed ImageFormat.ISO validation
* Add JUnit tests for VolumeApiServiceImpl.isNotPossibleToResize
* Fix checkstyle of test Class
* Use _templateDao.findByIdIncludingRemoved instead of _templateDao.findById
* Prevent null serviceOfferingView and Mock findByIdIncludingRemoved instead of findById
Added action in UI for syncStoragePool API for DatastoreCluster type primary storages.
Fixes#5086
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
his PR fixes the problem of not updating the chain info or setting chain info to null after volume migrations.
Problem: While fetching the volume chain info, management server assumes datastore name to be a UUID (this is true only for NFS storages added by CloudStack) but datastore name can be with any name.
Solution: To fetch the volume chain info, use datastore name instead of UUID.
The fix is made in the flow of following API operations
migrateVirtualMachine
migrateVirtualMachineWithVolume
migrateVolume
Hoang Nguyen
Wei Zhou
davidjumani
Abhishek Kumar
Pearl Dsilva
slavkap
Michael
Rohit Yadav
DK101010
Rakesh
Gabriel Beims Bräscher
dahn
Abhishek Kumar
fermosan
Harikrishna
Nicolas Vazquez
Peinthor Rene