> On July 17, 2013, 12:24 a.m., Sheng Yang wrote: > > server/src/com/cloud/template/TemplateManagerImpl.java, line 999 > > <https://reviews.apache.org/r/12612/diff/1/?file=322288#file322288line999> > > > > How can this happen?? Add Min Chen in reviewer. > > Venkata Siva Vijayendra Bhamidipati wrote: > This is because vmware tools or xenserver tools ISOs aren't actual ISOs. > They're internally provisioned by vmware/xenserver, so the URL will be null. > Since it isn't really resident anywhere, the image store will also be absent > for it, i.e., null. > > Min Chen wrote: > Vijay, I don't quite understand this. This check is to check if VM is at > running state. Original logic is that if VM that we are going to attach ISO > to is not at running, we just directly return true and update DB to put iso > id for this VM. Why did you change to return false here? > > Venkata Siva Vijayendra Bhamidipati wrote: > Hi Min, VMWare does not allow attaching the vmware tools iso if the VM is > not running. Here is the exception response we get from vCenter if true is > returned when the VM is not running, and we attempt to carry on with the > mount operation: > > 2013-07-16 09:44:26,158 ERROR [storage.resource.VmwareStorageProcessor] > (DirectAgent-7:10.223.74.131) AttachIsoCommand(attach) failed due to > Exception: com.vmware.vim25.InvalidState > message: [] > > com.vmware.vim25.InvalidStateFaultMsg: The operation is not allowed in > the current state. > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:532) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:130) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at sun.proxy.$Proxy95.mountToolsInstaller(Unknown Source) > at > com.cloud.hypervisor.vmware.mo.VirtualMachineMO.mountToolsInstaller(VirtualMachineMO.java:2152) > at > com.cloud.storage.resource.VmwareStorageProcessor.attachIso(VmwareStorageProcessor.java:883) > at > com.cloud.storage.resource.VmwareStorageProcessor.attachIso(VmwareStorageProcessor.java:768) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:125) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:55) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:565) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:679) > >
In such case, it's VMware specific thing, you shouldn't change the behavior of other hypervisors. And according to Min, the attachment is done after VM boot up, here we just modify DB. Why VMware behavior differently? - Sheng ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12612/#review23217 ----------------------------------------------------------- On July 17, 2013, 12:39 a.m., Venkata Siva Vijayendra Bhamidipati wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/12612/ > ----------------------------------------------------------- > > (Updated July 17, 2013, 12:39 a.m.) > > > Review request for cloudstack, Chip Childers, edison su, Kelven Yang, Sateesh > Chodapuneedi, and Sheng Yang. > > > Bugs: CLOUDSTACK-3554 > > > Repository: cloudstack-git > > > Description > ------- > > Fixing NPE that occurs when attaching vmware-tools.iso to a guest VM on ESX. > > > Diffs > ----- > > > plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareStorageProcessor.java > 4113803 > server/src/com/cloud/template/TemplateManagerImpl.java c7cc818 > > Diff: https://reviews.apache.org/r/12612/diff/ > > > Testing > ------- > > With the fix in place, vmware-tools.iso attach to a vmware guest VM works as > expected. > > > Thanks, > > Venkata Siva Vijayendra Bhamidipati > >
