vlan id format was like "vlan://<id>" instead of just "<id>". This causes numberformatexception while converting the vlan id to integer form from string form. this was fixed for standard vswitch in bug Cloudstack-5046. now fixed for other 2 cases of dvswitch as well as pvlan.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
(cherry picked from commit a605ca09cd)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Change in vCenter 5.5 API from prior versions forced code change in CloudStack. Update property value of property "VirtualE1000.deviceInfo.summary" is accommodated now.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
(cherry picked from commit dfa607fb44)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Conflicts:
vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java
In vCenter 5.5, once a volume is migrated the VMDKs are renamed to match the name of the VM.
If a volume has been renamed upon migration update its volumePath to that of the new disk filename.
(cherry picked from commit c652ff45df)
Signed-off-by: Animesh Chaturvedi <animesh@apache.org>
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.
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>
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>
During VM deployment when base template is being cloned to create VM ROOT disk, get the disk path
i.e. base file name of the VM's ROOT disk from vCenter
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.
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.