This is happening as concurrent operations are happening on the same VM. Earlier this was not seen as all vm operations were synchronized at agent layer. By making execute.in.sequence
global config to false this restriction is no longer there. In the latest code operations to a single vm are synchronized by maintaining a job queue. In some scenarios the destroy vm operation
was not going through this job queue mechanism and so was resulting in failures due to simultaneous operations.
For a detached volume, don't try to find the associated VM on the hypervisor/peer hypervisor host.
By default create a worker VM to perform snapshot operations.
Conflicts:
plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareStorageProcessor.java
this checkin adds support for plug-in that provides an in memory event
bus which could be used as alternative to RabbitMQ based event bus. Both
publisher are subscriber should be running with management server to use
in-memroy event bus.
on hyperv. There were multiple issues here. Upload volume was actually
failing because the post download check for vhd on the cifs share was
unsuccessful. Also the agent code wasn't parsing the volume path correctly.
Fixed it too.
The things is, VR would take time to execute the commands, say it would need
time t1(which is greater than 0).
And the interval between parallel deployment is t2(which can be almost 0). In
any case, VR need to handle commands in sequence internally, so if t1 > t2, then
the new task in the VR would wait longer and longer to execute, then some
commands result in timeout ultimately. No matter how long the timeout is, if
there are enough big number of queued task for VR, the last ones can timeout.
Currently VR has a robust mechanism to sequence the jobs internal and I
confirmed in this case, it works well. But there is no way to fix this issue if
VR is already 100% load at all time.
Probably we can improve the speed of VR internal executing, but seems the
ultimate answer is: set execute.in.sequence.network.element.commands to true. VR
doesn’t know how long it would take for mgmt. server to timeout, only mgmt.
server knows that.
By setting sequence execution in VR to "true", mgmt server would handle the
commands in a queue, make sure that VR won't be overload and report unexpected
failure just because it's overload.
Don't package the OVF and VMDK files into OVA after a template is created from volume.
Since packaging process contains reading and writing from the NFS mount, it doubles the amount of data that needs to be moved around
Conflicts:
plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareStorageProcessor.java
Added filters while listing scoped configuration parameters.
Fixed: Some parameters are missing from UI settings tab because of missing scope entry in configuration table.
Signed-off-by: Koushik Das <koushik@apache.org>
