[
https://issues.apache.org/jira/browse/CLOUDSTACK-7102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty resolved CLOUDSTACK-7102.
----------------------------------------
Resolution: Fixed
+Root Cause Analysis+
When global configuration 'vm.instancename.flag' is set to true, VM files and
the ROOT disk is placed in the VM folder named after VM's name in vCenter. But
any further disks that are attached to the VM are placed in VM folder that is
named after VM's CCP internal name (e.g. i-2-3-VM). And due to this mismatch we
run into file not found errors. Also, since we do VM look-ups based on VM's CCP
internal name we run into 'VM i-2-3-VM does not exist in VMware datacenter'
exceptions.
+Proposed Solution+
Look-up for a VM in vCenter should be based on both the vCenter name and CS
internal name.
VM folder name in primary storage should always be VM's name in vCenter and all
the files related to the VM should reside in this folder.
During Attach Volume and Volume Migration, for lookup and other operations use
VM's name as obtained from vCenter instead of using the name that is set in the
agent command.
> Volume migration fails with 'VM i-2-3-VM does not exist in VMware datacenter'
> expection
> ---------------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-7102
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7102
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, VMware
> Affects Versions: 4.2.0
> Reporter: Likitha Shetty
> Assignee: Likitha Shetty
> Priority: Critical
> Labels: S1
> Fix For: 4.5.0
>
>
> Steps to reproduce
> ------------------------
> 1. Set global config 'vm.instancename.flag' to true.
> 2. Bring up CS in advanced zone with at-least one vmware cluster.
> 3. Add two primary storages to the cluster.
> 4. Deploy one guest VM.
> 5. Create a volume and attach the volume to the guest VM. (Ensure the volume
> is in primary storage that doesn't contain the root disk).
> 6. Migrate the volume to the primary storage that contains the root disk.
> Volume Migration will fail with the below error -
> {noformat}
> 2014-07-14 12:21:33,112 ERROR [c.c.h.v.r.VmwareResource]
> (DirectAgent-398:ctx-4797dd6a 10.102.192.7, job-878/job-879, cmd:
> MigrateVolumeCommand) Catch Exception java.lang.Exception due to
> java.lang.Exception: VM i-2-32-VM does not exist in VMware datacenter
> datacenter-30215
> java.lang.Exception: VM i-2-32-VM does not exist in VMware datacenter
> datacenter-30215
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3139)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:416)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:293)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
