We hit these excptions whenever a management server held session that was with the old 5.1 vCenter server
is used to make resource calls to the new 5.5 vCenter.
Validate a vCenter session context before it is being used to make a resource call.
And if the context is invalid then discard the context and retrieve a new one.
During the invalidation of an old context handle the context disconnect better
by catching the appropriate exception and returning a newly created context.
Conflicts:
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareContextFactory.java
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareSecondaryStorageResourceHandler.java
vmware-base/src/com/cloud/hypervisor/vmware/util/VmwareContext.java
DetachISO is succeeding even though detach opeartion is failing as cdrom is locked by VM as it was mounted inside VM.
Detect if cdrom is locked or not. If locked fail detach operation and warn user to unmount before detaching the iso/cdrom device.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
Conflicts:
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareStorageProcessor.java
vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java
During VM start, if VM already exists and CS finds a matching disk in storage for each of the existing disk then the VM is reconfigured with VM's existing disk information. This existing disk information for a VM is got from vCenter.
CS checks if a matching disk exists in storage by checking if there is a disk in storage whose name atleast partially matches with the name of the existing disk.
Post 4.1, Volume path has been changed to ROOT-<instanceId> from ROOT-<instanceId>-<volumeId>. Hence in case of an upgraded setup (pre 4.1 to 4.2) during search for an existing disk in storage even though ROOT-<instanceId>-<volumeId> has been deleted, CS does a postive match of the old existing disk because of the partial match with the new disk ROOT-<instanceId> that exists in storage. And so when VM is being powered on by vCenter it looks for ROOT-<instanceId>-<volumeId> and fails to power on.
Solution - While looking for a VM's matching disk in storage, instead of checking if a disk with a partial match exists check if a disk with the exact name exists.
During ISO detach operation, answer question from vCenter by programmatically answering for VM question in detaching process.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
If HttpNfcLease initialization fails throw appropriate error
Catch throwable in addition to exceptions during file upload task while importing the OVA into vCenter
Cause - This issue can occur in VMware setups if the guest operating system is not specified when we install the virtual machine. In which case, since we map the OS to 'Other OS', VMwareInstallerISO attachment fails.
Added the necessary guest OS mapping for VMware.
The managed context framework provides a simple way to add logic
to ACS at the various entry points of the system. As threads are
launched and ran listeners can be registered for onEntry or onLeave
of the managed context. This framework will be used specifically
to handle DB transaction checking and setting up the CallContext.
This framework is need to transition away from ACS custom AOP to
Spring AOP.
