Applying the short term fix of force cleaning up if the answer recieved from startcommand is not valid
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>
for number of commands participating in Vm deployment process, as parallel deployment is supported on the hypervisor side.
The behavior is controlled by global config varirables:
"execute.in.sequence.hypervisor.commands" (false by default) sets/resets the synchronization for commands:
=========================
StartCommand
StopCommand
CreateCommand
CopyVolumeCommand
"execute.in.sequence.network.element.commands" (false by default) sets/resets the synchronization for commands:
==========================
DhcpEntryCommand
SavePasswordCommand
UserDataCommand
VmDataCommand
As a part of the fix, increased the global lock timeout to 30 mins in several VR scripts:
===========================
edithosts.sh
savepassword.sh
userdata.sh
to support situations when multiple concurrent calls to the script are being made.
During Scale up of VM, memory/cpu calculations should consider the memory/cpu overprovisioning factors which are set per cluster.
CLOUDSTACK-2939: CPU limit is not getting set for vm after scaleup to a service offering which have cpu cap enabled
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.
The location of the virtual machine is provided by DeployDestination, which will
be passed in NetworkGuru#reserve and NetworkElement#prepare.
During the virtual machine migration, it actually changes DeployDestination and
it looks like that it will tell that event to network components as it has
NetworkManager#prepareNicForMigration. The problem is that althogh the interface
has that method, NetworkManagerImpl does not tell the DeployDestination changes
to network components.
So IMHO, we need to add calls of NetworkGuru#reserve and NetworkElement#prepare
in NetworkManagerImpl#prepareNicForMigration . And then, we also need to add
calls NetworkGuru#release and NetworkElement#release after the migration,
otherwise the network resources that plugin reserved will be kept even when the
vm leaves off.
(Sheng Yang: rebase code, add license header)
Signed-off-by: Sheng Yang <sheng.yang@citrix.com>
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.
1. Keeping the description consistent - Memory not RAM when referring to
overcommit
2. getters And setters grouped, provided right casing.
3. Removed wildcard imports
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
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:
- There is no good mechanism currently to figure out if the deployment failed due to affinity groups only
- We can just hint the user that the deployment might have failed due to the affinity groups and ask to review the input
- 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.
This feature enables adding of guest ip ranges (public ips) form different subnets.
In order to provide the dhcp service to a different subnet we create an ipalias on the router. This allows the router to listen to the dhcp request from the guest vms and respond accordingly. Every time a vm is deployed in the new subnet we configure an ip alias on the router. Cloudstack uses dnsmasq to provide dhcp service. We need to configure the dnsmasq to issue ips on the new subnets. Added a new class dnsmasqconfigurator which generates the dnsmasq confg file, this file replaces the old config in the router.
The details of the alias ips are stored in db in the nic_ip_alias table. Every time a new subnet is added one of the ip from the subnet is used to configure the ip alias.
I have pushed the code to https://github.com/bvbharatk/cloud-stack/tree/Cloudstack-702 , also rebased the code with master.
I need to test the code for advanced sg enabled network using kvm.
I have added the unit test
Marvin tests are at https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=53e4965
Also accomodated some of the changes suggested by koushik.
corrected the import statements. renamed the IpAlias command to createIpAlias command.
This feature supports only ipv4
Nitin Mehta
Mike Tutkowski
Murali Reddy
Wei Zhou
Harikrishna Patnala
Sheng Yang
Edison Su
Bharat Kumar
Edison Su
Alena Prokharchyk
Prachi Damle
Hugo Trippaers
Min Chen
Saksham Srivastava
Mice Xia
Wido den Hollander
Hiroaki Kawai
Devdeep Singh
Prasanna Santhanam
Vijayendra Bhamidipati