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>
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. 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>
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
can fail to start a VM without notifying caller, if no exception is triggered.
The result is that VM start looks successful but was not. This fixes it by
throwing an exception at the very end if the object to be passed back is still
null.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1366225829 -0600
Supporting kickstart in CloudStack baremetal
able to start vm
Conflicts:
client/tomcatconf/componentContext.xml.in
server/src/com/cloud/baremetal/BareMetalTemplateAdapter.java
server/src/com/cloud/baremetal/BareMetalVmManagerImpl.java
server/src/com/cloud/vm/UserVmManagerImpl.java
Description: Adds API calls updateDefaultNicForVirtualMachine,
addNicToVirtualMachine, and removeNicFromVirtualMachine. These are
intended to allow a user to modify a VM's configuration post
deployment, to adjust the networks to which the VM belongs.
BUG-ID: CLOUDSTACK-645
Submitted-by: Brian Angus <blangus@betterservers.com>
Submitted-by: Ryan Dietrich <ryan@betterservers.com>
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1359494800 -0700
Corresponding getter/setter is renamed too.
Reason is GenericDao does not update the field unless the method name matches the field name; the setter of this VO was one such case.
