Alerts are generated for VM migration between:
1) Source host is dedicated and destination host is not.
2) Source host is not dedicated and destination host is dedicated.
3) Both hosts are dedicated to different accounts/domains
Detail: Get list of all nics and update user data on them, rather than just
the default nic for the VM. This makes the results consistent with the password
and SSH key metadata.
BUG-ID: CLOUDSTACK-3408
Bugfix-for: 4.1.1, 4.2.0
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1373345338 -0600
If the scaling up fails on the host the vm is running on try to migrate it to other hosts in the cluster and try scaling.
CLOUDSTACK-3349
For deciding the host in the cluster try the new deployment manager now
Signed off by : nitin mehta<nitin.mehta@citrix.com>
CLOUDSTACK-3042 - handle Scaling up of vm memory/CPU based on the presence of XS tools in the template
This also takes care of updation of VM after XS tools are installed in the vm and set memory values accordingly to support dynamic scaling after stop start of VM
Signed-off-by: Abhinandan Prateek <aprateek@apache.org>
This feature allows a user to deploy VMs only in the resources dedicated to his account or domain.
1. Resources(Zones, Pods, Clusters or hosts) can be dedicated to an account or domain.
Implemented 12 new APIs to dedicate/list/release resources:
- dedicateZone, listDedicatedZones, releaseDedicatedZone for a Zone.
- dedicatePod, listDedicatedPods, releaseDedicatedPod for a Pod.
- dedicateCluster, listDedicatedClusters, releaseDedicatedCluster for a Cluster
- dedicateHost, listDedicatedHosts, releaseDedicatedHost for a Host.
2. Once a resource(eg. pod) is dedicated to an account, other resources(eg. clusters/hosts) inside that cannot be further dedicated.
3. Once a resource is dedicated to a domain, other resources inside that can be further dedicated to its sub-domain or account.
4. If any resource (eg.cluster) is dedicated to a account/domain, then resources(eg. Pod) above that cannot be dedicated to different accounts/domain (not belonging to the same domain)
5. To use Explicit dedication, user needs to create an Affinity Group of type 'ExplicitDedication'
6. A VM can be deployed with the above affinity group parameter as an input.
7. A new ExplicitDedicationProcessor has been added which will process the affinity group of type 'Explicit Dedication' for a deployment of a VM that demands dedicated resources.
This processor implements the AffinityGroupProcessor adapter. This processor will update the avoid list.
8. A VM requesting dedication will be deployed on dedicatd resources if available with the user account.
9. A VM requesting dedication can also be deployed on the dedicated resources available with the parent domains iff no dedicated resources are available with the current user's account or
domain.
10. A VM (without dedication) can be deployed on shared host but not on dedicated hosts.
11. To modify the dedication, the resource has to be released first.
12. Existing Private zone functionality has been redirected to Explicit dedication of zones.
13. Updated the db upgrade schema script. A new table "dedicated_resources" has been added.
14. Added the right permissions in commands.properties
15. Unit tests: For the new APIs and Service, added unit tests under : plugins/dedicated-resources/test/org/apache/cloudstack/dedicated/DedicatedApiUnitTest.java
16. Marvin Test: To dedicate host, create affinity group, deploy-vm, check if vm is deployed on the dedicated host.
This is to support restore a vm to a new/currently_attached ISO.
In the restorevm API we have an optional parameter templateId to restore the vm to the new template/ISO ID.
1. Made a fix to make sure a null object is added to the exception.
2. Also fixed the marvin test cases for the feature. Account cleanup will remove the vms deployed for the account. There is no need to explicitly delete the vms for the account.
3. Fixed the assertion checks for the vm created for an account. If there are multiple vms for an account, the test script needs to compare the ids with the correct instance.
CLOUDSTACK-2349: Anti-Affinity - As admin user , using updateVMAffinityGroup() , we are allowed to update the affinity group of a Vm (that belongs to a regular user) to be set to admin's affinity group.
Changes:
- Even for root-admin make sure that the affinity group and the VM belong to same account
- Changes merged from planner_reserve branch
- Exposing deploymentplanner as an optional parameter while creating a service offering
- changes to DeploymentPlanningManagerImpl to make sure host reserve-release happens between conflicting planner usages.
