CLOUDSTACK-8726 : Automation for Quickly attaching multiple data disks to a new VMAttach multiple Volumes simultaneously to a Running VM ... === TestName: test_attach_multiple_volumes | Status : SUCCESS ===
ok
----------------------------------------------------------------------
Ran 1 test in 196.931s
OK
* pr/683:
changed the testcase skip code into setup method
Imparting changes mentioned by nitt10prashant
Automation for multiple disk attachments to instance
Signed-off-by: sanjeev <sanjeev@apache.org>
CLOUDSTACK-8756:Incorrect guest os mapping in CCP 4.2.1-6 for CentOS 5.9Check the bug 8756 for more details
* pr/728:
CLOUDSTACK-8756:Incorrect guest os mapping in CCP 4.2.1-6 for CentOS 5.9
Signed-off-by: Rajani Karuturi <rajani.karuturi@citrix.com>
CLOUDSTACK-8688 - default policies for INPUT and FORWARD should be set to DROP instead of ACCEPT
- In order to be able to access the routers via the link local interface, we have to add a rules with NEW and ESTABLISHED state
* pr/765:
CLOUDSTACK-8688 - Adding Marvin tests in order to cover the fixes applied
CLOUDSTACK-8688 - default policies for INPUT and FORWARD should be set to DROP instead of ACCEPT
Signed-off-by: wilderrodrigues <wrodrigues@schubergphilis.com>
- Changing refactored the utils.get_process_status() function
- Adding 2 tests: test_01_single_VPC_iptables_policies and test_02_routervm_iptables_policies
CLOUDSTACK-8759 - Destroying VPC router results in a new unusable VPC routerHow to reproduce the problem:
1. Stop/Destroy the VPC router
2. Add a virtual machine to one of the VPC tier - it will trigger a VPC router creation
3. Router is created, but the NICs are not configured
How to recover without this fix:
1. Stop/destroy the VPC router and restart the VPC
Side effects: private gateways could be misconfigured.
Root cause:
In the VpcNetworkHelperImpl.configureDefaultNics() method, the guest network nic was added in the map prior to the control and public NICs. The order in the map should not matter, however in the LibvirtComputingResource.createVifs() method, there is a logic that relies on the device index - the array index - in order to create the control nic. I advise a refactor on the data model in order to be able to identify the NIC type instead of relying in the array index.
An integration test was added to cover the fix:
* test_vpc_router_nics.py
Environment:
Management Server running on CentOS 7.1
KVM host running on CentOS 7.1
CloudStack Agent/Common 4.6.0-SNAPSHOT
Executing the test:
```
nosetests --with-marvin --marvin-config=/data/shared/marvin/mct-zone2-kvm2-ISOLATED.cfg -s -a tags=advanced,required_hardware=true component/test_vpc_router_nics.py
```
Remark: during the SSH there might be stack traces on the console due to the connection retry. It takes some time to get the PF rules in place and reach the VMs. So, just let the test run until the end.
```
Test results:
Create a vpc with two networks with two vms in each network ... === TestName: test_01_VPC_nics_after_destroy | Status : SUCCESS ===
ok
----------------------------------------------------------------------
Ran 1 test in 774.020s
OK
/tmp//MarvinLogs/test_vpc_router_nics_VH6E9S/results.txt (END)
```
* pr/773:
CLOUDSTACK-8759 - Fix guets nic allocation
CLOUDSTACK-8759 - Adding a marvin test in order to cover the fix
CLOUDSTACK-8759 - The guest nic has to be added after the control nic
Signed-off-by: Remi Bergsma <github@remi.nl>
- The test will create a VPC, add 2 tier, 2 VMs, ACL, PF and SSH into the VM
- Then it will stop the router, destroy the router, add another VM to 1 tier and check that we can reach all the VMs
Made following fixes in simulator
- Support for ScaleVmCommand/NetworkRulesVmSecondaryIpCommand in resource layer
- Added support for scaling up a running VM in simulator
- Fixed some method names not following convention
In order to test PR #725 using simulator some of these changes are needed.
Based on the way HV check is present in the scale VM API, had to explicitly put simulator related check to allow support. The ideal way would be to remove all these HV specific check from code and made them some configuration (by putting them in hypervisor_capabilities table in DB). But that will be a bigger effort outside the scope of this PR.
Signed-off-by: Koushik Das <koushik@apache.org>
CLOUDSTACK-8716: Verify creation of snapshot from volume when the task is performed repeatedly in zone wide primary StorageOn VMWare with a Zone wide primary storage and more than two clusters verify successful creation of snapshot multiple times.
* pr/665:
CLOUDSTACK-8716: Verify creation of snapshot from volume when the task is performed repeatedly in zone wide primary Storage
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
CLOUDSTACK-8723: Verify API call "listUsageRecords" returns usage of new volume created after restore VMAfter restoring a running VM current ROOT disk gets destroyed and new ROOT disk gets created.
This testcase is to check if volume usage of this newly created volume is listed in listUsageRecords API.
* pr/675:
CLOUDSTACK-8723: Verify API call "listUsageRecords" returns usage of new volume created after restore VM
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
CLOUDSTACK-8757:FTP modules are not loaded in VRcheck bug 8757 for more details .
* pr/729:
CLOUDSTACK-8757:FTP modules are not loaded in VR
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
CLOUDSTACK-8716: Verify creation of snapshot from volume when the task is performed repeatedly in zone wide primary Storage
-Removing redundent code
-Added validate list function for list snapshot operation
CLOUDSTACK-8716: Verify creation of snapshot from volume when the task is performed repeatedly in zone wide primary Storage
Removed duplicate test data related to vm properties.Modified tests dependent on it
Removed duplicte service offerings from test data and modified tests dependent on it
Bug-Id: CLOUDSTACK-8617
This closes#644
CLOUDSTACK-8689-Verify-effect-of-changing-value-of-XenServer-Max-guest-limitis-on-previously-added-hosts -Addning check for empty list and increamenting maxguestlimit accordingly
CLOUDSTACK-8689: Verify effect of changing value of XenServer Maxguestlimits on previously added hosts -As testcase is changing maxguestlimits global setting it will affect on other testcases also hence moving it to component/maint folder
This closes#638
As part of volume sync, that runs during of SSVM start-up, the volume_store_ref entry was getting deleted. Volume GC relies on this entry to move volume to destroyed state.
Since the entry was getting deleted, GC thread never moved the volume from UploadError/UploadAbandoned to Destroyed. Fix is to not remove the volume_store_ref entry as part
of volume sync and let GC thread handle the clean up.
This closes#611
