[jira] [Commented] (CLOUDSTACK-8111) NFS secondary storage repetitively mounted on MS with ESXi hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256726#comment-14256726 ] ASF subversion and git services commented on CLOUDSTACK-8111: - Commit 647532376fc090f75e6fa0ad66ee36241084dec9 in cloudstack's branch refs/heads/master from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6475323 ] CLOUDSTACK-8111. NFS secondary storage repetitively mounted on CS server with ESXi hypervisors. Fix cleanup of NFS mounts on management server during server starup by correcting how mount points are listed for a management server. NFS secondary storage repetitively mounted on MS with ESXi hypervisors -- Key: CLOUDSTACK-8111 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8111 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: Future During MS start, CS should look for NFS mounts left over from the previous MS sessions and clean them up. This isn't working as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8111) NFS secondary storage repetitively mounted on MS with ESXi hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256728#comment-14256728 ] Likitha Shetty commented on CLOUDSTACK-8111: +Verification Steps+ 1. Run mount on CS MS - Notice the secondary storage(s) is mounted on a path that begins with /mnt/VM/ 2. Restart the MS - Verify the secondary storage mounts are cleaned up. 3. Additionally verify that the operations that involve mounting the secondary storage on MS succeed. Operations could be VM migration with storage, deploying the first VM from a template. NFS secondary storage repetitively mounted on MS with ESXi hypervisors -- Key: CLOUDSTACK-8111 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8111 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: Future During MS start, CS should look for NFS mounts left over from the previous MS sessions and clean them up. This isn't working as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8111) NFS secondary storage repetitively mounted on MS with ESXi hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty resolved CLOUDSTACK-8111. Resolution: Fixed NFS secondary storage repetitively mounted on MS with ESXi hypervisors -- Key: CLOUDSTACK-8111 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8111 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: Future During MS start, CS should look for NFS mounts left over from the previous MS sessions and clean them up. This isn't working as expected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8112) Creating VM using an existing display name fails when vm.instancename.flag is set to true.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256740#comment-14256740 ] ASF subversion and git services commented on CLOUDSTACK-8112: - Commit 5f9e4fddf303f312a0b17abc0d837f28042caeda in cloudstack's branch refs/heads/master from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5f9e4fd ] CLOUDSTACK-8112. CS allows creation of VM's with the same Display name when vm.instancename.flag is set to true. During VM creation, if vm.instancename.flag is set to true and hypervisor type is VMware, check if VM with the same hostname already exists in the zone. Creating VM using an existing display name fails when vm.instancename.flag is set to true. -- Key: CLOUDSTACK-8112 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8112 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: Future CS restricts 2 VMs from having the same name only if they are in the same network. But in case vm.instancename.flag is set to true, VM name in vCenter will be its VM's CS display name. And vCenter doesn't allow two VMs to have the same name under the same DC which results in the failure of VM start in CS and is not handled correctly. CS should throw an error message to the user that a VM with the same name already exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8112) Creating VM using an existing display name fails when vm.instancename.flag is set to true.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty resolved CLOUDSTACK-8112. Resolution: Fixed During VM creation, if vm.instancename.flag is set to true and hypervisor type is VMware, check if VM with the same hostname already exists in the zone. Why is check being made under the zone? There are two types of VMware zones: legacy zones and non-legacy zones. - In case of a non-legacy zone, since a CS zone maps to a VMware DC, by checking under the CS zone we ensure that no two VMs with same name are created under the same DC. - In case of legacy zone, we don't have 1-1 mapping between CS zones and VMware DCs. But we still need to check under the entire zone to avoid any potential failures for other CS operations. For e.g. In case of cold migration, CS allows a volume to be moved across between VMware DCs if they belong to the same CS zone. Now if a VM with an existing VM name is allowed to be created under a different DC (but same CS zone) the after a cold migration, when an attempt is made to start the VM it will fail with conflicting name issue. Creating VM using an existing display name fails when vm.instancename.flag is set to true. -- Key: CLOUDSTACK-8112 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8112 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: Future CS restricts 2 VMs from having the same name only if they are in the same network. But in case vm.instancename.flag is set to true, VM name in vCenter will be its VM's CS display name. And vCenter doesn't allow two VMs to have the same name under the same DC which results in the failure of VM start in CS and is not handled correctly. CS should throw an error message to the user that a VM with the same name already exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7769) [Automation] Fix the script test_ssvm.py - SSVM Gateway Assertion is not valid in EIP-ELB case
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256752#comment-14256752 ] ASF subversion and git services commented on CLOUDSTACK-7769: - Commit ab3af7b014d7391da056e6461e1c1f432e62d827 in cloudstack's branch refs/heads/4.5 from [~chandanp] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ab3af7b ] CLOUDSTACK-7769 - Fixed test_ssvm.py script [Automation] Fix the script test_ssvm.py - SSVM Gateway Assertion is not valid in EIP-ELB case Key: CLOUDSTACK-7769 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7769 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 SSVM and CPVM's gateway in EIP-ELB Setup is present in the Public Network and not in the private network. Hence needs to avoid that assertion in EIP-ELB Setup scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8096) [Automation] Fix failures in smoke/test_ssvm.py (reboot ssvm and cpvm test cases)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256753#comment-14256753 ] ASF subversion and git services commented on CLOUDSTACK-8096: - Commit 1413efcac3c80e0dd6561a35cf8fa2df10c2ad46 in cloudstack's branch refs/heads/4.5 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1413efc ] CLOUDSTACK-8096: Fixed test_ssvm.py for issues while checking the result of diagnostic scripts Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org [Automation] Fix failures in smoke/test_ssvm.py (reboot ssvm and cpvm test cases) - Key: CLOUDSTACK-8096 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8096 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 After reboot SSVM and CPVM operation, if we run diagnostic script on SSVM, it fails with NFS server is not currently mounted. Also if we run command service cloud status, it says Cloudstack cloud service is not running. But if we check after some time, everything is fine. Some delay in test cases is needed to allow the SSVM and CPVM to start all services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8096) [Automation] Fix failures in smoke/test_ssvm.py (reboot ssvm and cpvm test cases)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256755#comment-14256755 ] ASF subversion and git services commented on CLOUDSTACK-8096: - Commit 77bd069cc7b38bf93cc4e314d5d1ddcada56f11d in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=77bd069 ] CLOUDSTACK-8096: Fixed test_ssvm.py for issues while checking the result of diagnostic scripts Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org [Automation] Fix failures in smoke/test_ssvm.py (reboot ssvm and cpvm test cases) - Key: CLOUDSTACK-8096 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8096 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 After reboot SSVM and CPVM operation, if we run diagnostic script on SSVM, it fails with NFS server is not currently mounted. Also if we run command service cloud status, it says Cloudstack cloud service is not running. But if we check after some time, everything is fine. Some delay in test cases is needed to allow the SSVM and CPVM to start all services. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8113) VM migration fails with Message: No such disk device: error
Likitha Shetty created CLOUDSTACK-8113:
--
Summary: VM migration fails with Message: No such disk device:
error
Key: CLOUDSTACK-8113
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8113
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Deploy VM
2. Live Migrate VM to another primary storage pool
3. Take VM snapshot
4. Delete VM snapshot
5. Attempt to Migrate VM will fail with below error -
{noformat}
WARN [c.c.h.v.r.VmwareResource] (DirectAgent-30:ctx-8ec50a5a 10.102.192.7)
MigrationCommand failed due to Exception: java.lang.Exception
Message: No such disk device: ROOT-20-01.vmdk
java.lang.Exception: No such disk device: ROOT-20-01.vmdk
at
com.cloud.hypervisor.vmware.resource.VmwareResource.getVirtualDiskInfo(VmwareResource.java:4814)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4644)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:529)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:215)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
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:47)
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)
INFO [c.c.h.v.u.VmwareContextPool] (DirectAgent-30:ctx-8ec50a5a 10.102.192.7)
Recycle VmwareContext into idle pool: administrator@10.102.192.248, current
idle pool size: 3, outstanding count: 3
ERROR [o.a.c.s.m.VmwareStorageMotionStrategy] (Work-Job-Executor-5:ctx-0b939401
job-252/job-253 ctx-0a71c68d) Migration with storage of vm VM[User|i-2-20-VM]
failed. Details: No such disk device: ROOT-20-01.vmdk
ERROR [o.a.c.s.m.VmwareStorageMotionStrategy] (Work-Job-Executor-5:ctx-0b939401
job-252/job-253 ctx-0a71c68d) copy failed
com.cloud.utils.exception.CloudRuntimeException: Error while migrating the vm
VM[User|i-2-20-VM] to host Host[-6-Routing]. No such disk device:
ROOT-20-01.vmdk
at
org.apache.cloudstack.storage.motion.VmwareStorageMotionStrategy.migrateVmWithVolumesAcrossCluster(VmwareStorageMotionStrategy.java:144)
at
org.apache.cloudstack.storage.motion.VmwareStorageMotionStrategy.copyAsync(VmwareStorageMotionStrategy.java:103)
at
org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:89)
at
org.apache.cloudstack.storage.volume.VolumeServiceImpl.migrateVolumes(VolumeServiceImpl.java:1023)
at
org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.migrateVolumes(VolumeOrchestrator.java:958)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrateWithStorage(VirtualMachineManagerImpl.java:2138)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrateWithStorage(VirtualMachineManagerImpl.java:5220)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5315)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:101)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:519)
at
[jira] [Commented] (CLOUDSTACK-8113) VM migration fails with Message: No such disk device: error
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256758#comment-14256758
]
ASF subversion and git services commented on CLOUDSTACK-8113:
-
Commit cb211f18d14dcc9d988254a4b50b55ca0b080ed5 in cloudstack's branch
refs/heads/master from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cb211f1 ]
CLOUDSTACK-8113. VM migration fails with Message: No such disk device: error.
Consolidate VM disks once VM/volumes are migrated.
VM migration fails with Message: No such disk device: error
--
Key: CLOUDSTACK-8113
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8113
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Deploy VM
2. Live Migrate VM to another primary storage pool
3. Take VM snapshot
4. Delete VM snapshot
5. Attempt to Migrate VM will fail with below error -
{noformat}
WARN [c.c.h.v.r.VmwareResource] (DirectAgent-30:ctx-8ec50a5a 10.102.192.7)
MigrationCommand failed due to Exception: java.lang.Exception
Message: No such disk device: ROOT-20-01.vmdk
java.lang.Exception: No such disk device: ROOT-20-01.vmdk
at
com.cloud.hypervisor.vmware.resource.VmwareResource.getVirtualDiskInfo(VmwareResource.java:4814)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4644)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:529)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:215)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
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:47)
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)
INFO [c.c.h.v.u.VmwareContextPool] (DirectAgent-30:ctx-8ec50a5a
10.102.192.7) Recycle VmwareContext into idle pool:
administrator@10.102.192.248, current idle pool size: 3, outstanding count: 3
ERROR [o.a.c.s.m.VmwareStorageMotionStrategy]
(Work-Job-Executor-5:ctx-0b939401 job-252/job-253 ctx-0a71c68d) Migration
with storage of vm VM[User|i-2-20-VM] failed. Details: No such disk device:
ROOT-20-01.vmdk
ERROR [o.a.c.s.m.VmwareStorageMotionStrategy]
(Work-Job-Executor-5:ctx-0b939401 job-252/job-253 ctx-0a71c68d) copy failed
com.cloud.utils.exception.CloudRuntimeException: Error while migrating the vm
VM[User|i-2-20-VM] to host Host[-6-Routing]. No such disk device:
ROOT-20-01.vmdk
at
org.apache.cloudstack.storage.motion.VmwareStorageMotionStrategy.migrateVmWithVolumesAcrossCluster(VmwareStorageMotionStrategy.java:144)
at
org.apache.cloudstack.storage.motion.VmwareStorageMotionStrategy.copyAsync(VmwareStorageMotionStrategy.java:103)
at
org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:89)
at
org.apache.cloudstack.storage.volume.VolumeServiceImpl.migrateVolumes(VolumeServiceImpl.java:1023)
at
org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.migrateVolumes(VolumeOrchestrator.java:958)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrateWithStorage(VirtualMachineManagerImpl.java:2138)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrateWithStorage(VirtualMachineManagerImpl.java:5220)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
[jira] [Resolved] (CLOUDSTACK-8113) VM migration fails with Message: No such disk device: error
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty resolved CLOUDSTACK-8113.
Resolution: Fixed
+Root Cause Analysis+
Volume migration /VM migration with storage will fails if volume's path in DB
(volume attached to the VM) doesn't match the volume's actual VMDK path.
When a VM is migrated with storage, all its volume's (entire disk chain) is
migrated to the destination primary storage. In case of linked clones, the ROOT
volume's chain will contain the parent template which is present in primary
storage and the ROOT disk VMDK. Once the VM has been migrate if a volume
snapshot is taken on the volume, it results in the coalesce of the ROOT disk
chain wherein vCenter removes the top of the disk chain. This is because volume
snapshot involves creation and deletion of VM snapshots during which vCenter
coalesces the disk chain. Since vCenter removes the top of the disk chain, ROOT
volumes' path changes. CS updates the volume path of only the volume whose
snapshot is being taken once a volume snapshot has been taken. That is why any
further operations on the volume like migration that depend on the volume's
path will fail for the ROOT volume is the snapshot of a Datadisk is taken.
VM migration fails with Message: No such disk device: error
--
Key: CLOUDSTACK-8113
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8113
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Deploy VM
2. Live Migrate VM to another primary storage pool
3. Take VM snapshot
4. Delete VM snapshot
5. Attempt to Migrate VM will fail with below error -
{noformat}
WARN [c.c.h.v.r.VmwareResource] (DirectAgent-30:ctx-8ec50a5a 10.102.192.7)
MigrationCommand failed due to Exception: java.lang.Exception
Message: No such disk device: ROOT-20-01.vmdk
java.lang.Exception: No such disk device: ROOT-20-01.vmdk
at
com.cloud.hypervisor.vmware.resource.VmwareResource.getVirtualDiskInfo(VmwareResource.java:4814)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4644)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:529)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:215)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
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:47)
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)
INFO [c.c.h.v.u.VmwareContextPool] (DirectAgent-30:ctx-8ec50a5a
10.102.192.7) Recycle VmwareContext into idle pool:
administrator@10.102.192.248, current idle pool size: 3, outstanding count: 3
ERROR [o.a.c.s.m.VmwareStorageMotionStrategy]
(Work-Job-Executor-5:ctx-0b939401 job-252/job-253 ctx-0a71c68d) Migration
with storage of vm VM[User|i-2-20-VM] failed. Details: No such disk device:
ROOT-20-01.vmdk
ERROR [o.a.c.s.m.VmwareStorageMotionStrategy]
(Work-Job-Executor-5:ctx-0b939401 job-252/job-253 ctx-0a71c68d) copy failed
com.cloud.utils.exception.CloudRuntimeException: Error while migrating the vm
VM[User|i-2-20-VM] to host Host[-6-Routing]. No such disk device:
ROOT-20-01.vmdk
at
org.apache.cloudstack.storage.motion.VmwareStorageMotionStrategy.migrateVmWithVolumesAcrossCluster(VmwareStorageMotionStrategy.java:144)
at
[jira] [Commented] (CLOUDSTACK-8098) [Automation] Fix smoke/test_vm_snapshots.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256772#comment-14256772 ] ASF subversion and git services commented on CLOUDSTACK-8098: - Commit fc2c1a09a7064aa9121ead7c9f88fb268698c22e in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fc2c1a0 ] CLOUDSTACK-8098: Fixed VM snapshot issue in smoke/test_vm_snapshots.py Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org [Automation] Fix smoke/test_vm_snapshots.py --- Key: CLOUDSTACK-8098 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8098 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The test case fails while reverting the VM snapshot because the snapshot does not contain the memory and VM is not in stopped state. Solution: Stop the VM before reverting the snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7762) [Automation] - Fix test failure for test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256771#comment-14256771
]
ASF subversion and git services commented on CLOUDSTACK-7762:
-
Commit 0d75682a341162b45afd1bc7784a4aaffd1a5aa6 in cloudstack's branch
refs/heads/master from SrikanteswaraRao Talluri
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0d75682 ]
Revert CLOUDSTACK-7762 -[Automation] - Fix test failure for
test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py
This reverts commit f510ef995baaa9addefc22ff0330cd51dee1dd95.
[Automation] - Fix test failure for test_02_revert_vm_snapshots in
smoke/test_vm_snapshots.py
---
Key: CLOUDSTACK-7762
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7762
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Test
Affects Versions: 4.5.0
Environment: Build from master
Reporter: Sangeetha Hariharan
Fix For: 4.5.0
test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py fails in BVT runs
with the following exception:
2014-10-20 16:41:00,497 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-120:ctx-83b738d9 job-459) Add job-459 into job monitoring
2014-10-20 16:41:00,497 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-120:ctx-83b738d9 job-459) Executing AsyncJobVO {id:459,
userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vmsnapshot.RevertToVMSnapshotCmdByAdmin,
cmdInfo:
{response:json,ctxDetails:{\com.cloud.vm.snapshot.VMSnapshot\:\12280973-a1e4-43e3-80b3-3afacd607909\},cmdEventType:VMSNAPSHOT.REVERTTO,ctxUserId:2,httpmethod:GET,vmsnapshotid:12280973-a1e4-43e3-80b3-3afacd607909,ctxAccountId:2,ctxStartEventId:1406,apiKey:aJwkScf5ziRwz8gKQ9HB0Ce6hSsTJTUtmUDUQ_U2teV3vVmuLQRLad8xqAgr7CrFOEQbywdVpKSt2yC_ORXLYg,signature:cYBxgg8eBfktovmCaHYox2xoTE8\u003d},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 11489258594360, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-10-20 16:41:00,529 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-120:ctx-83b738d9 job-459) Unexpected exception while
executing
org.apache.cloudstack.api.command.admin.vmsnapshot.RevertToVMSnapshotCmdByAdmin
com.cloud.exception.InvalidParameterValueException: VM Snapshot revert not
allowed. This will result in VM state change. You can revert running VM to
disk and memory type snapshot and stopped VM to disk type snapshot
at
com.cloud.vm.snapshot.VMSnapshotManagerImpl.revertToSnapshot(VMSnapshotManagerImpl.java:581)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8114) Stop and start of VM doesn't update volume path.
Likitha Shetty created CLOUDSTACK-8114: -- Summary: Stop and start of VM doesn't update volume path. Key: CLOUDSTACK-8114 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8114 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: Future In case of VMware upon start of a VM, the path and chain-info of the volumes associated with the VM should be updated. Path update is not happening in 4.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8098) [Automation] Fix smoke/test_vm_snapshots.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256782#comment-14256782 ] ASF subversion and git services commented on CLOUDSTACK-8098: - Commit 125c1c27fc0ebe3781fd2fb63e2d2dd5689c9fa0 in cloudstack's branch refs/heads/4.5 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=125c1c2 ] CLOUDSTACK-8098: Fixed VM snapshot issue in smoke/test_vm_snapshots.py Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org [Automation] Fix smoke/test_vm_snapshots.py --- Key: CLOUDSTACK-8098 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8098 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The test case fails while reverting the VM snapshot because the snapshot does not contain the memory and VM is not in stopped state. Solution: Stop the VM before reverting the snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7762) [Automation] - Fix test failure for test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256780#comment-14256780
]
ASF subversion and git services commented on CLOUDSTACK-7762:
-
Commit f18e00abf148423797f911e3ec7764c21bac6a00 in cloudstack's branch
refs/heads/4.5 from SrikanteswaraRao Talluri
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f18e00a ]
Revert CLOUDSTACK-7762 -[Automation] - Fix test failure for
test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py
This reverts commit f510ef995baaa9addefc22ff0330cd51dee1dd95.
[Automation] - Fix test failure for test_02_revert_vm_snapshots in
smoke/test_vm_snapshots.py
---
Key: CLOUDSTACK-7762
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7762
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Test
Affects Versions: 4.5.0
Environment: Build from master
Reporter: Sangeetha Hariharan
Fix For: 4.5.0
test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py fails in BVT runs
with the following exception:
2014-10-20 16:41:00,497 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-120:ctx-83b738d9 job-459) Add job-459 into job monitoring
2014-10-20 16:41:00,497 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-120:ctx-83b738d9 job-459) Executing AsyncJobVO {id:459,
userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vmsnapshot.RevertToVMSnapshotCmdByAdmin,
cmdInfo:
{response:json,ctxDetails:{\com.cloud.vm.snapshot.VMSnapshot\:\12280973-a1e4-43e3-80b3-3afacd607909\},cmdEventType:VMSNAPSHOT.REVERTTO,ctxUserId:2,httpmethod:GET,vmsnapshotid:12280973-a1e4-43e3-80b3-3afacd607909,ctxAccountId:2,ctxStartEventId:1406,apiKey:aJwkScf5ziRwz8gKQ9HB0Ce6hSsTJTUtmUDUQ_U2teV3vVmuLQRLad8xqAgr7CrFOEQbywdVpKSt2yC_ORXLYg,signature:cYBxgg8eBfktovmCaHYox2xoTE8\u003d},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 11489258594360, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-10-20 16:41:00,529 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-120:ctx-83b738d9 job-459) Unexpected exception while
executing
org.apache.cloudstack.api.command.admin.vmsnapshot.RevertToVMSnapshotCmdByAdmin
com.cloud.exception.InvalidParameterValueException: VM Snapshot revert not
allowed. This will result in VM state change. You can revert running VM to
disk and memory type snapshot and stopped VM to disk type snapshot
at
com.cloud.vm.snapshot.VMSnapshotManagerImpl.revertToSnapshot(VMSnapshotManagerImpl.java:581)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8099) [Automation] Fix test_dynamic_compute_offering.py - unittest is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256783#comment-14256783 ] ASF subversion and git services commented on CLOUDSTACK-8099: - Commit bce67bc282e12db15a2630af30a0bf9ea5d46c29 in cloudstack's branch refs/heads/master from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bce67bc ] CLOUDSTACK-8099: Fixed missing import in test_dynamic_compute_offering.py Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org [Automation] Fix test_dynamic_compute_offering.py - unittest is not defined --- Key: CLOUDSTACK-8099 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8099 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.5.0 Fix the import. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8099) [Automation] Fix test_dynamic_compute_offering.py - unittest is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256786#comment-14256786 ] ASF subversion and git services commented on CLOUDSTACK-8099: - Commit 5a6eb3b6e186fc5e45216647e8f521ace7f11ec3 in cloudstack's branch refs/heads/4.5 from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5a6eb3b ] CLOUDSTACK-8099: Fixed missing import in test_dynamic_compute_offering.py Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org [Automation] Fix test_dynamic_compute_offering.py - unittest is not defined --- Key: CLOUDSTACK-8099 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8099 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.5.0 Fix the import. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7788) [Automation][Simulator] Fix the script test_dynamic_compute_offering.py - Test Cases failing on Simulator due to hardware resources requirement for test executio
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256785#comment-14256785 ] ASF subversion and git services commented on CLOUDSTACK-7788: - Commit ddcbfb43bc0cb76ad32c81c74416cf0c98d3eb3e in cloudstack's branch refs/heads/4.5 from [~chandanp] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ddcbfb4 ] CLOUDSTACK-7788: Fixed the script 'test_dynamic_compute_offering.py' to be run only on hardware [Automation][Simulator] Fix the script test_dynamic_compute_offering.py - Test Cases failing on Simulator due to hardware resources requirement for test execution Key: CLOUDSTACK-7788 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7788 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Fix For: 4.5.0 Test Cases are trying to perform operations that can only be done on hardware and supported hypervisors. These Test Cases are not meant to be run on SImulator due to their validation requirements. Hence they cannot be run with Simulator -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5511) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-5511. - Resolution: Fixed Please delete old releases from mirroring system Key: CLOUDSTACK-5511 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5511 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: https://dist.apache.org/repos/dist/release/cloudstack/releases/ Reporter: Sebb Assignee: Daan Hoogland To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [Note that older releases are always available from the ASF archive server] Any links to older releases on download pages should first be adjusted to point to the archive server. [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7527) XenServer heartbeat-script: make it reboot faster (when fencing)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland resolved CLOUDSTACK-7527. --- Resolution: Fixed XenServer heartbeat-script: make it reboot faster (when fencing) Key: CLOUDSTACK-7527 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7527 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: XenServer Affects Versions: 4.3.0, 4.4.0 Reporter: Remi Bergsma Assignee: Daan Hoogland Priority: Minor xenheartbeat.sh: I've seen the 'reboot' command hang, even though it has the force option specified (last line of the script). Wouldn't it be better to invoke it like this: echo b /proc/sysrq-trigger Tested it, starts boot sequence immediately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7781) Typo in calling /opt/cloud/bin/createipAlias.sh
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-7781: -- Fix Version/s: (was: 4.4.3) 4.4.2 Typo in calling /opt/cloud/bin/createipAlias.sh --- Key: CLOUDSTACK-7781 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7781 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.4.0, 4.4.1 Environment: CentOS 6.5 mgmt HVs Reporter: Nux Priority: Blocker Labels: systemvm Fix For: 4.4.2 Hello, During a VR upgrade from 4.3.1 the VM will not start because missing /opt/cloud/bin/createipAlias.sh, this is a typo as the file is present as /opt/cloud/bin/createIpAlias.sh. This blocks the VR upgrade, but not the SSVM or the CPVM. The work-around was to copy /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh in the SSVM template, before running the cloudstack-systemvmadm upgrade procedure. The problem is not always encountered, I do have a testing environment that was not hit by the issue. Sod's law dictates this will manifest itself only in production, critical deployments. :) Imho the 4.4.1 sysvm template should be updated ASAP so other people won't hit this issue. For 4.5 this is fixed in https://issues.apache.org/jira/browse/CLOUDSTACK-7246 Made some noise about it on the mailing list, so for more details and logs go to eg http://www.mail-archive.com/dev@cloudstack.apache.org/msg36853.html http://www.mail-archive.com/dev@cloudstack.apache.org/msg36871.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7781) Typo in calling /opt/cloud/bin/createipAlias.sh
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland resolved CLOUDSTACK-7781. --- Resolution: Fixed please verify Typo in calling /opt/cloud/bin/createipAlias.sh --- Key: CLOUDSTACK-7781 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7781 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.4.0, 4.4.1 Environment: CentOS 6.5 mgmt HVs Reporter: Nux Priority: Blocker Labels: systemvm Fix For: 4.4.2 Hello, During a VR upgrade from 4.3.1 the VM will not start because missing /opt/cloud/bin/createipAlias.sh, this is a typo as the file is present as /opt/cloud/bin/createIpAlias.sh. This blocks the VR upgrade, but not the SSVM or the CPVM. The work-around was to copy /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh in the SSVM template, before running the cloudstack-systemvmadm upgrade procedure. The problem is not always encountered, I do have a testing environment that was not hit by the issue. Sod's law dictates this will manifest itself only in production, critical deployments. :) Imho the 4.4.1 sysvm template should be updated ASAP so other people won't hit this issue. For 4.5 this is fixed in https://issues.apache.org/jira/browse/CLOUDSTACK-7246 Made some noise about it on the mailing list, so for more details and logs go to eg http://www.mail-archive.com/dev@cloudstack.apache.org/msg36853.html http://www.mail-archive.com/dev@cloudstack.apache.org/msg36871.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7702) keytool not in sudoers file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-7702: -- Fix Version/s: (was: 4.4.3) 4.4.1 keytool not in sudoers file --- Key: CLOUDSTACK-7702 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7702 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.1 Reporter: Daan Hoogland Assignee: Daan Hoogland Fix For: 4.4.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7702) keytool not in sudoers file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland resolved CLOUDSTACK-7702. --- Resolution: Fixed keytool not in sudoers file --- Key: CLOUDSTACK-7702 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7702 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.1 Reporter: Daan Hoogland Assignee: Daan Hoogland Fix For: 4.4.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-6485: -- Fix Version/s: 4.6.0 [vpc] new private gateway network is registered wrong in network table -- Key: CLOUDSTACK-6485 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1 Reporter: Anton Opgenoort Assignee: Daan Hoogland Fix For: 4.6.0 When creating a private gateway for a VPC router on a network not yet known to Cloudstack, Cloudstack ‘documents’ this network in the networks table. For normal guest networks, which should be associated with a single VPC, Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to provision all networks and nics on a VPC router when it is created. Since this table is all about network provisioning it makes sense to ‘document’ the network cidr and gateway present in that nework. For guest tiers this usually is the VPC router itself, so the interface IP’s on a VPC router are the gateway IP’s found in the networks table. Unfortunately the VPC_ID is also recorded for the private gateway network when it is first created. So the first VPC to be plugged on the private gateway network also has that same network associated as a guest network tier, instead of just a private gateway network. This by itself will not quickly become a problem, because private gateways are first plugged on a running vpc router which is not likely to be recreated any time soon after that. But as soon as this first ever VPC router on the private gateway network is recreated due to a destroy of the VPC Router, all associated networks are looked up in the networks table. Because the private gateway network is ‘documented’ with the actual upstream gateway used by the VPC router defintion, the VPC router provisions a NIC on the private gateway network using the IP address of the actual upstream gateway creating an IP conflict on the private gateway network, effectively breaking down the upstream gateway functionality for all attached private gateways of other vpc's. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-6485: -- Fix Version/s: (was: 4.6.0) [vpc] new private gateway network is registered wrong in network table -- Key: CLOUDSTACK-6485 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1 Reporter: Anton Opgenoort Assignee: Daan Hoogland When creating a private gateway for a VPC router on a network not yet known to Cloudstack, Cloudstack ‘documents’ this network in the networks table. For normal guest networks, which should be associated with a single VPC, Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to provision all networks and nics on a VPC router when it is created. Since this table is all about network provisioning it makes sense to ‘document’ the network cidr and gateway present in that nework. For guest tiers this usually is the VPC router itself, so the interface IP’s on a VPC router are the gateway IP’s found in the networks table. Unfortunately the VPC_ID is also recorded for the private gateway network when it is first created. So the first VPC to be plugged on the private gateway network also has that same network associated as a guest network tier, instead of just a private gateway network. This by itself will not quickly become a problem, because private gateways are first plugged on a running vpc router which is not likely to be recreated any time soon after that. But as soon as this first ever VPC router on the private gateway network is recreated due to a destroy of the VPC Router, all associated networks are looked up in the networks table. Because the private gateway network is ‘documented’ with the actual upstream gateway used by the VPC router defintion, the VPC router provisions a NIC on the private gateway network using the IP address of the actual upstream gateway creating an IP conflict on the private gateway network, effectively breaking down the upstream gateway functionality for all attached private gateways of other vpc's. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-6485) [vpc] new private gateway network is registered wrong in network table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland resolved CLOUDSTACK-6485. --- Resolution: Fixed this hack will have to be acceptable for now. Private Gateway functionality needs revisiting. [vpc] new private gateway network is registered wrong in network table -- Key: CLOUDSTACK-6485 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6485 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.3.1 Reporter: Anton Opgenoort Assignee: Daan Hoogland When creating a private gateway for a VPC router on a network not yet known to Cloudstack, Cloudstack ‘documents’ this network in the networks table. For normal guest networks, which should be associated with a single VPC, Cloudstack includes the VPC_ID in the database. The VPC_ID field is used to provision all networks and nics on a VPC router when it is created. Since this table is all about network provisioning it makes sense to ‘document’ the network cidr and gateway present in that nework. For guest tiers this usually is the VPC router itself, so the interface IP’s on a VPC router are the gateway IP’s found in the networks table. Unfortunately the VPC_ID is also recorded for the private gateway network when it is first created. So the first VPC to be plugged on the private gateway network also has that same network associated as a guest network tier, instead of just a private gateway network. This by itself will not quickly become a problem, because private gateways are first plugged on a running vpc router which is not likely to be recreated any time soon after that. But as soon as this first ever VPC router on the private gateway network is recreated due to a destroy of the VPC Router, all associated networks are looked up in the networks table. Because the private gateway network is ‘documented’ with the actual upstream gateway used by the VPC router defintion, the VPC router provisions a NIC on the private gateway network using the IP address of the actual upstream gateway creating an IP conflict on the private gateway network, effectively breaking down the upstream gateway functionality for all attached private gateways of other vpc's. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-5511) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb reopened CLOUDSTACK-5511: -- Please now delete 4.3.2. By the way, 4.3.2 does not appear on either the current download page or the archives page. Also, please update the release documentation to ensure that the release area is tidied up going forward. Please delete old releases from mirroring system Key: CLOUDSTACK-5511 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5511 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: https://dist.apache.org/repos/dist/release/cloudstack/releases/ Reporter: Sebb Assignee: Daan Hoogland To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [Note that older releases are always available from the ASF archive server] Any links to older releases on download pages should first be adjusted to point to the archive server. [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5511) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-5511: -- Assignee: Rohit Yadav (was: Daan Hoogland) Please delete old releases from mirroring system Key: CLOUDSTACK-5511 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5511 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: https://dist.apache.org/repos/dist/release/cloudstack/releases/ Reporter: Sebb Assignee: Rohit Yadav To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [Note that older releases are always available from the ASF archive server] Any links to older releases on download pages should first be adjusted to point to the archive server. [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8115) Update default ordering of HA investigators
Koushik Das created CLOUDSTACK-8115: --- Summary: Update default ordering of HA investigators Key: CLOUDSTACK-8115 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8115 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 The PingInvestigator goes through all other hosts in a pod to determine if a host is alive or not. This can take considerable amount of time if there are many hosts in a pod. So placing the HV specific investigators before it in the default ordering. The default order can always be changed from global config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8115) Update default ordering of HA investigators
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das updated CLOUDSTACK-8115: Description: The PingInvestigator goes through all other hosts in a pod to determine if a host is alive or not. This can take considerable amount of time if there are many hosts in a pod. So placing the HV specific investigators before it in the default ordering. The order can always be changed from global config. was: The PingInvestigator goes through all other hosts in a pod to determine if a host is alive or not. This can take considerable amount of time if there are many hosts in a pod. So placing the HV specific investigators before it in the default ordering. The default order can always be changed from global config. Update default ordering of HA investigators --- Key: CLOUDSTACK-8115 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8115 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 The PingInvestigator goes through all other hosts in a pod to determine if a host is alive or not. This can take considerable amount of time if there are many hosts in a pod. So placing the HV specific investigators before it in the default ordering. The order can always be changed from global config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8115) Update default ordering of HA investigators
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256841#comment-14256841 ] ASF subversion and git services commented on CLOUDSTACK-8115: - Commit ceae97868cb98b503324afb7743a25ce1f5c1516 in cloudstack's branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ceae978 ] CLOUDSTACK-8115: Update default ordering of HA investigators Moved HV specific investigators before PingInvestigator in default ordering Update default ordering of HA investigators --- Key: CLOUDSTACK-8115 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8115 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 The PingInvestigator goes through all other hosts in a pod to determine if a host is alive or not. This can take considerable amount of time if there are many hosts in a pod. So placing the HV specific investigators before it in the default ordering. The order can always be changed from global config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8115) Update default ordering of HA investigators
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das resolved CLOUDSTACK-8115. - Resolution: Fixed Update default ordering of HA investigators --- Key: CLOUDSTACK-8115 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8115 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 The PingInvestigator goes through all other hosts in a pod to determine if a host is alive or not. This can take considerable amount of time if there are many hosts in a pod. So placing the HV specific investigators before it in the default ordering. The order can always be changed from global config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5511) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256843#comment-14256843 ] Rohit Yadav commented on CLOUDSTACK-5511: - [~s...@apache.org] the 4.3.2 release was passed today few hours ago so I'm yet to update the page and work on the announcements etc. Our latest release is 4.4.2 and 4.3.2 is a latest bugfix on the 4.3 branch so since it's lower than 4.4.2 I'll put it on the archives page. I lack the permission to move the artifact from releases to archive for 4.3.2, so until a PMC can help do that the 4.3.2 release won't be available from archives. I'll go ahead and add a link based on file names and expected paths. [~dahn] if you've time can you please help move the 4.3.2 artifacts to archives? sorry in case I'm troubling you during holidays, thanks :) Please delete old releases from mirroring system Key: CLOUDSTACK-5511 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5511 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: https://dist.apache.org/repos/dist/release/cloudstack/releases/ Reporter: Sebb Assignee: Rohit Yadav To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [Note that older releases are always available from the ASF archive server] Any links to older releases on download pages should first be adjusted to point to the archive server. [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5511) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256849#comment-14256849 ] Sebb commented on CLOUDSTACK-5511: -- Sorry, did not notice that it was a recent addition. SInce it's a current release, it should go on the current downloads page, not the archives page. The downloads page should correspond with the mirrored download files. Note that the archives server is automatically populated from the www.apache.org/dist every so often (once a day?) - there is no need to do anything special. Please delete old releases from mirroring system Key: CLOUDSTACK-5511 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5511 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: https://dist.apache.org/repos/dist/release/cloudstack/releases/ Reporter: Sebb Assignee: Rohit Yadav To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [Note that older releases are always available from the ASF archive server] Any links to older releases on download pages should first be adjusted to point to the archive server. [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8116) Move ldap config data to configurableData section in test_data.py and make related changes in the test case
Gaurav Aradhye created CLOUDSTACK-8116: -- Summary: Move ldap config data to configurableData section in test_data.py and make related changes in the test case Key: CLOUDSTACK-8116 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8116 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-4587) VM is failing to deploy on a Legacy zone after adding zone wide primary storage and moving cluster wide primary storage to maintenance mode
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanteswararao Talluri closed CLOUDSTACK-4587. After moving the cluster scoped primary storages into maintenance mode, SystemVMs came up on zone wide primary storage. Hence, closing the bug. VM is failing to deploy on a Legacy zone after adding zone wide primary storage and moving cluster wide primary storage to maintenance mode Key: CLOUDSTACK-4587 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4587 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.1 Reporter: Sailaja Mada Assignee: Likitha Shetty Fix For: 4.5.0 Attachments: failureloigs.rar, logs.rar, vmdeploylogs.rar Steps: 1. Upgraded from 307 to 4.2 using VMWARE Cluster with Cluster level primary storage 2. Add Zone wide primary storage after upgrade 3. Move the cluster level scope storage to Maintenance mode 4. Try to deploy new VM. Observation: VM is failing to deploy on a Legacy zone after adding zone wide primary storage and moving cluster wide primary storage to maintenance mode 2013-09-01 14:21:10,323 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Network id=207 is already implemented 2013-09-01 14:21:10,354 DEBUG [network.guru.PodBasedNetworkGuru] (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Allocated a nic NicProfile[119-35-4a8f547b-7bff-4b3f-ba10-b0146af4d1bb-10.102.195.111-null for VM[DomainRouter|r-35-VM] 2013-09-01 14:21:10,390 DEBUG [cloud.storage.VolumeManagerImpl] (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Checking if we need to prepare 1 volumes for VM[DomainRouter|r-35-VM] 2013-09-01 14:21:10,400 DEBUG [storage.image.TemplateDataFactoryImpl] (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) template 203 is already in store:2, type:Image 2013-09-01 14:21:10,409 DEBUG [storage.image.TemplateDataFactoryImpl] (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) template 203 is already in store:203, type:Primary 2013-09-01 14:21:10,410 DEBUG [storage.volume.VolumeServiceImpl] (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Found template 203-2-3cfe22ca-3a33-39a0-bf5e-0dab154869fd in storage pool 203 with VMTemplateStoragePool id: 11 2013-09-01 14:21:10,421 DEBUG [storage.volume.VolumeServiceImpl] (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Acquire lock on VMTemplateStoragePool 11 with timeout 3600 seconds 2013-09-01 14:21:10,423 INFO [storage.volume.VolumeServiceImpl] (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) lock is acquired for VMTemplateStoragePool 11 2013-09-01 14:21:10,431 DEBUG [storage.motion.AncientDataMotionStrategy] (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) copyAsync inspecting src type TEMPLATE copyAsync inspecting dest type TEMPLATE 2013-09-01 14:21:10,519 DEBUG [storage.motion.AncientDataMotionStrategy] (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) copy object failed: java.lang.NullPointerException at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyObject(AncientDataMotionStrategy.java:210) at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:411) at org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:55) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:440) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:569) at com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2536) at com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2592) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:888) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2740) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1872) at
[jira] [Commented] (CLOUDSTACK-5511) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256936#comment-14256936 ] Rohit Yadav commented on CLOUDSTACK-5511: - Thanks for the pointers. I'll add a link below the current release on the downloads page soon. Please delete old releases from mirroring system Key: CLOUDSTACK-5511 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5511 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: https://dist.apache.org/repos/dist/release/cloudstack/releases/ Reporter: Sebb Assignee: Rohit Yadav To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [Note that older releases are always available from the ASF archive server] Any links to older releases on download pages should first be adjusted to point to the archive server. [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5511) Please delete old releases from mirroring system
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-5511. --- Resolution: Fixed Closing since 4.3.2 is a new release, we should put it on downloads/releases page and not on archives yet. Please delete old releases from mirroring system Key: CLOUDSTACK-5511 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5511 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: https://dist.apache.org/repos/dist/release/cloudstack/releases/ Reporter: Sebb Assignee: Rohit Yadav To reduce the load on the ASF mirrors, projects are required to delete old releases [1] Please can you remove all non-current releases? Thanks! [Note that older releases are always available from the ASF archive server] Any links to older releases on download pages should first be adjusted to point to the archive server. [1] http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8117) Increase the allowed margin (+/-) for memory of VM on hyperv used to equate with the memory specified in service offering
Gaurav Aradhye created CLOUDSTACK-8117: -- Summary: Increase the allowed margin (+/-) for memory of VM on hyperv used to equate with the memory specified in service offering Key: CLOUDSTACK-8117 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8117 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 Increase the allowed margin (+/-) for memory of VM on hyperv used to equate with the memory specified in service offering. Large component of memory is consumed by the Ui component, hence the memory for VM is listed lesser than that is specified in the service offering. Increase the range from 20 to 200 for hyperv because of the difference in template used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7781) Typo in calling /opt/cloud/bin/createipAlias.sh
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14256991#comment-14256991 ] Nux commented on CLOUDSTACK-7781: - The issue seemed fixed the last time I tried, thanks. Typo in calling /opt/cloud/bin/createipAlias.sh --- Key: CLOUDSTACK-7781 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7781 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.4.0, 4.4.1 Environment: CentOS 6.5 mgmt HVs Reporter: Nux Priority: Blocker Labels: systemvm Fix For: 4.4.2 Hello, During a VR upgrade from 4.3.1 the VM will not start because missing /opt/cloud/bin/createipAlias.sh, this is a typo as the file is present as /opt/cloud/bin/createIpAlias.sh. This blocks the VR upgrade, but not the SSVM or the CPVM. The work-around was to copy /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh in the SSVM template, before running the cloudstack-systemvmadm upgrade procedure. The problem is not always encountered, I do have a testing environment that was not hit by the issue. Sod's law dictates this will manifest itself only in production, critical deployments. :) Imho the 4.4.1 sysvm template should be updated ASAP so other people won't hit this issue. For 4.5 this is fixed in https://issues.apache.org/jira/browse/CLOUDSTACK-7246 Made some noise about it on the mailing list, so for more details and logs go to eg http://www.mail-archive.com/dev@cloudstack.apache.org/msg36853.html http://www.mail-archive.com/dev@cloudstack.apache.org/msg36871.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8103) Vmsync marks VM as stopped even after failing to stop it in HV
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257056#comment-14257056 ] ASF subversion and git services commented on CLOUDSTACK-8103: - Commit 145b4a1f2c46aa6c50c8abf191d6d08a78f3a1fb in cloudstack's branch refs/heads/4.4 from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=145b4a1 ] CLOUDSTACK-8103: Vmsync marks VM as stopped even after failing to stop it in HV During vmsync if StopCommand (issued as part of PowerOff/PowerMissing report) fails to stop VM (since VM is running on HV), don't transition VM state to Stopped in CS db. Also added a check to throw ConcurrentOperationException if vm state is not Running after start operation. (cherry picked from commit 788fe5a27365e57508e0c1c967da46da0314e3e4) Vmsync marks VM as stopped even after failing to stop it in HV -- Key: CLOUDSTACK-8103 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8103 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Priority: Critical Fix For: 4.5.0 Vmsync reports poweroff/powermissing and tries to stop vm. The stop agent command fails as it finds VM to be running in HV. Even though stop command fails, the VM is marked as stopped in the database. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8107) Failed to create snapshot from volume when the task is performed repeatedly in zone wide primary Storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257077#comment-14257077 ] ASF subversion and git services commented on CLOUDSTACK-8107: - Commit 9be404a93ed0ca99df4fa60d7943a4598ab9fe91 in cloudstack's branch refs/heads/4.4 from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9be404a ] CLOUDSTACK-8107. Failed to create snapshot from volume when the task is performed repeatedly in zone wide primary Storage. While taking a snapshot of a volume, CS chooses the endpoint to perform backup snapshot operation by selecting any host that has the storage containing the volume mounted on it. Instead, if the volume is attached to a VM, the endpoint chosen by CS should be the host that contains the VM. (cherry picked from commit a75a43137316a60b20760aa5015d97f55520fd16) Failed to create snapshot from volume when the task is performed repeatedly in zone wide primary Storage. - Key: CLOUDSTACK-8107 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8107 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: Future +Steps to reproduce+ 1. Setup a CS zone with a VMware DC. 2. Ensure the DC has 2 clusters with a host each. 3. Add 2 Cluster-Wide primary storage pool to each of the clusters. 4. Add a Zone-wide primary storage pool. 5. Deploy a VM with a data-disk. Ensure both the ROOT and Data disk of the VM is in the zone-wide storage pool. 6. Take snapshots for the Data volume till the operation fails. In vCenter, the failure will be while Reconfiguring (worker)VM and the error will be '.vmdk was not found'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8109) [VMware] Extract Template is failing.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257086#comment-14257086 ] ASF subversion and git services commented on CLOUDSTACK-8109: - Commit 53fbe840147ab5ffe6f02be155d0fbc836000e92 in cloudstack's branch refs/heads/4.4 from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=53fbe84 ] CLOUDSTACK-8109. Extract Template is failing. Fix the OVA path that is returned once an OVA is packaged using a META file. (cherry picked from commit 507d9d337d2e80f7f6e5d665708c0687c387c5fc) [VMware] Extract Template is failing. -- Key: CLOUDSTACK-8109 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8109 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: Future +Steps to reproduce+ 1. Deploy a VM. 2. Stop the VM. 3. Create template from VM’s root disk. 4. Try to download the template - FAILURE -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8112) Creating VM using an existing display name fails when vm.instancename.flag is set to true.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257514#comment-14257514 ] ASF subversion and git services commented on CLOUDSTACK-8112: - Commit 4807fa7de64d287950d45717a40a36e72efaabad in cloudstack's branch refs/heads/4.4 from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4807fa7 ] CLOUDSTACK-8112. CS allows creation of VM's with the same Display name when vm.instancename.flag is set to true. Before registering a VM check if a different CS VM with same name exists in vCenter. (cherry picked from commit 33179cce56b15f0632e38afa260cb829bb2a2273) Creating VM using an existing display name fails when vm.instancename.flag is set to true. -- Key: CLOUDSTACK-8112 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8112 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: Future CS restricts 2 VMs from having the same name only if they are in the same network. But in case vm.instancename.flag is set to true, VM name in vCenter will be its VM's CS display name. And vCenter doesn't allow two VMs to have the same name under the same DC which results in the failure of VM start in CS and is not handled correctly. CS should throw an error message to the user that a VM with the same name already exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8103) Vmsync marks VM as stopped even after failing to stop it in HV
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-8103: -- Fix Version/s: 4.4.3 Vmsync marks VM as stopped even after failing to stop it in HV -- Key: CLOUDSTACK-8103 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8103 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Priority: Critical Fix For: 4.5.0, 4.4.3 Vmsync reports poweroff/powermissing and tries to stop vm. The stop agent command fails as it finds VM to be running in HV. Even though stop command fails, the VM is marked as stopped in the database. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8107) Failed to create snapshot from volume when the task is performed repeatedly in zone wide primary Storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-8107: -- Fix Version/s: (was: Future) 4.4.3 Failed to create snapshot from volume when the task is performed repeatedly in zone wide primary Storage. - Key: CLOUDSTACK-8107 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8107 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: 4.4.3 +Steps to reproduce+ 1. Setup a CS zone with a VMware DC. 2. Ensure the DC has 2 clusters with a host each. 3. Add 2 Cluster-Wide primary storage pool to each of the clusters. 4. Add a Zone-wide primary storage pool. 5. Deploy a VM with a data-disk. Ensure both the ROOT and Data disk of the VM is in the zone-wide storage pool. 6. Take snapshots for the Data volume till the operation fails. In vCenter, the failure will be while Reconfiguring (worker)VM and the error will be '.vmdk was not found'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8109) [VMware] Extract Template is failing.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-8109: -- Fix Version/s: (was: Future) 4.4.3 [VMware] Extract Template is failing. -- Key: CLOUDSTACK-8109 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8109 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: 4.4.3 +Steps to reproduce+ 1. Deploy a VM. 2. Stop the VM. 3. Create template from VM’s root disk. 4. Try to download the template - FAILURE -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8112) Creating VM using an existing display name fails when vm.instancename.flag is set to true.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-8112: -- Fix Version/s: (was: Future) 4.4.3 Creating VM using an existing display name fails when vm.instancename.flag is set to true. -- Key: CLOUDSTACK-8112 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8112 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.4.3 CS restricts 2 VMs from having the same name only if they are in the same network. But in case vm.instancename.flag is set to true, VM name in vCenter will be its VM's CS display name. And vCenter doesn't allow two VMs to have the same name under the same DC which results in the failure of VM start in CS and is not handled correctly. CS should throw an error message to the user that a VM with the same name already exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8114) Stop and start of VM doesn't update volume path.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257947#comment-14257947 ] ASF subversion and git services commented on CLOUDSTACK-8114: - Commit 521258bafb91e30d7bd43fba62cc47a77c078028 in cloudstack's branch refs/heads/master from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=521258b ] CLOUDSTACK-8114. Ensure VM stop and then start updates the volume path correctly in the DB. Stop and start of VM doesn't update volume path. Key: CLOUDSTACK-8114 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8114 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: Future In case of VMware upon start of a VM, the path and chain-info of the volumes associated with the VM should be updated. Path update is not happening in 4.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8114) Stop and start of VM doesn't update volume path.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty resolved CLOUDSTACK-8114. Resolution: Fixed Stop and start of VM doesn't update volume path. Key: CLOUDSTACK-8114 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8114 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: Future In case of VMware upon start of a VM, the path and chain-info of the volumes associated with the VM should be updated. Path update is not happening in 4.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8118) Root volume migration fails with 'No such disk device' in case of vCenter 5.5 setup
Likitha Shetty created CLOUDSTACK-8118:
--
Summary: Root volume migration fails with 'No such disk device' in
case of vCenter 5.5 setup
Key: CLOUDSTACK-8118
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8118
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Setup CS with vCenter 5.5.
2. Deploy a VM in cluster. Say ROOT volume is in primary storage P1
3. Add another primary storage to the same cluster (P2).
4. Migrate ROOT volume to primary storage P2.
Migration fails with -
{noformat}
2014-12-24 15:13:29,299 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-325:ctx-0dbf332a) Seq 5-6870804181507113730: Executing request
2014-11-24 15:13:29,299 INFO [c.c.h.v.r.VmwareResource]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Executing resource Mi grateVolumeCommand:
{volumeId:106,volumePath:ROOT-40-01,pool:
{id:8,uuid:251a42e1-7316-30a8-ad11-bf03421f39f2,host:10.147.28.7,path:/export/home/manasa/priVMw2,port:2049,type:NetworkFilesystem}
,attachedVmName:i-2-40-VM,wait:3600}
2014-12-24 15:13:29,422 INFO [c.c.h.v.m.VirtualMachineMO]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Look for disk devic e info from volume :
ROOT-40-01.vmdk with trimmed base name: ROOT-40
2014-12-24 15:13:29,422 INFO [c.c.h.v.m.VirtualMachineMO]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Test against disk d evice, controller key: 1000, unit
number: 0
2014-11-24 15:13:29,422 INFO [c.c.h.v.m.VirtualMachineMO]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Test against disk b acking :
[f159abf3a6863ff1ad6a24d59100bdb9] vm-test/ROOT-40-01.vmdk
2014-12-24 15:13:29,422 ERROR [c.c.h.v.r.VmwareResource]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Catch Exception java. lang.Exception due to
java.lang.Exception: No such disk device: ROOT-40-01.vmdk
java.lang.Exception: No such disk device: ROOT-40-01.vmdk
at
com.cloud.hypervisor.vmware.resource.VmwareResource.getVirtualDiskInfo(VmwareResource.java:3366)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3319)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:403)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:304)
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$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2014-11-24 15:13:29,424 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-325:ctx-0dbf332a) Seq 5-6870804181507113730: Response Received:
2014-11-24 15:13:29,425 DEBUG [c.c.a.t.Request] (DirectAgent-325:ctx-0dbf332a)
Seq 5-6870804181507113730: Processing: { Ans: , MgmtId: 6662467354709, via: 5,
Ver: v1 , Flags: 110,
[{com.cloud.agent.api.storage.MigrateVolumeAnswer:{result:false,details:Catch
Exception java.lang.Exception due to java.lang.Exception: No such d isk
device: ROOT-40-01.vmdk,wait:0}}] }
2014-12-24 15:13:29,425 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-151:ctx-1199aeb3 job-760/job-761 ctx-63b18747) Seq
5-6870804181507113730: Received: { Ans: , MgmtI d: 6662467354709, via: 5, Ver:
v1, Flags: 110,
{ MigrateVolumeAnswer }
}
2014-11-24 15:13:29,425 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(Work-Job-Executor-151:ctx-1199aeb3 job-760/job-761 ctx-63b18747) copy failed
com.cloud.utils.exception.CloudRuntimeException: Failed to migrate volume
[jira] [Commented] (CLOUDSTACK-8118) Root volume migration fails with 'No such disk device' in case of vCenter 5.5 setup
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257969#comment-14257969
]
ASF subversion and git services commented on CLOUDSTACK-8118:
-
Commit ddcae8a9306f5f7dd416b859e59fd10094c91551 in cloudstack's branch
refs/heads/master from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ddcae8a ]
CLOUDSTACK-8118. Root volume migration fails with 'No such disk device' in case
of vCenter 5.5 setup.
If an exact match is being done while locating disk chain by name, don't trim
snapshot postfix appended to the disk name.
Root volume migration fails with 'No such disk device' in case of vCenter 5.5
setup
---
Key: CLOUDSTACK-8118
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8118
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Setup CS with vCenter 5.5.
2. Deploy a VM in cluster. Say ROOT volume is in primary storage P1
3. Add another primary storage to the same cluster (P2).
4. Migrate ROOT volume to primary storage P2.
Migration fails with -
{noformat}
2014-12-24 15:13:29,299 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-325:ctx-0dbf332a) Seq 5-6870804181507113730: Executing request
2014-11-24 15:13:29,299 INFO [c.c.h.v.r.VmwareResource]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Executing resource Mi grateVolumeCommand:
{volumeId:106,volumePath:ROOT-40-01,pool:
{id:8,uuid:251a42e1-7316-30a8-ad11-bf03421f39f2,host:10.147.28.7,path:/export/home/manasa/priVMw2,port:2049,type:NetworkFilesystem}
,attachedVmName:i-2-40-VM,wait:3600}
2014-12-24 15:13:29,422 INFO [c.c.h.v.m.VirtualMachineMO]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Look for disk devic e info from volume :
ROOT-40-01.vmdk with trimmed base name: ROOT-40
2014-12-24 15:13:29,422 INFO [c.c.h.v.m.VirtualMachineMO]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Test against disk d evice, controller key: 1000, unit
number: 0
2014-11-24 15:13:29,422 INFO [c.c.h.v.m.VirtualMachineMO]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Test against disk b acking :
[f159abf3a6863ff1ad6a24d59100bdb9] vm-test/ROOT-40-01.vmdk
2014-12-24 15:13:29,422 ERROR [c.c.h.v.r.VmwareResource]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Catch Exception java. lang.Exception due to
java.lang.Exception: No such disk device: ROOT-40-01.vmdk
java.lang.Exception: No such disk device: ROOT-40-01.vmdk
at
com.cloud.hypervisor.vmware.resource.VmwareResource.getVirtualDiskInfo(VmwareResource.java:3366)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3319)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:403)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:304)
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$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2014-11-24 15:13:29,424 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-325:ctx-0dbf332a) Seq 5-6870804181507113730: Response Received:
2014-11-24 15:13:29,425 DEBUG [c.c.a.t.Request]
(DirectAgent-325:ctx-0dbf332a) Seq 5-6870804181507113730:
[jira] [Resolved] (CLOUDSTACK-8118) Root volume migration fails with 'No such disk device' in case of vCenter 5.5 setup
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty resolved CLOUDSTACK-8118.
Resolution: Fixed
In case of vSphere 5.5 + ESXi 5.5, CS ROOT volumes created for a VM have the
disk name appended with a post-fix for e.g. 01.
During migration and other volume related operations we do a disk look up in
vCenter based on the CCP volume path. And during this disk look-up, we trim the
snapshot post-fix that is appended to CCP volume path (if present). So when we
do an exact match the look up fails because of the trimmed name.
Root volume migration fails with 'No such disk device' in case of vCenter 5.5
setup
---
Key: CLOUDSTACK-8118
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8118
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Setup CS with vCenter 5.5.
2. Deploy a VM in cluster. Say ROOT volume is in primary storage P1
3. Add another primary storage to the same cluster (P2).
4. Migrate ROOT volume to primary storage P2.
Migration fails with -
{noformat}
2014-12-24 15:13:29,299 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-325:ctx-0dbf332a) Seq 5-6870804181507113730: Executing request
2014-11-24 15:13:29,299 INFO [c.c.h.v.r.VmwareResource]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Executing resource Mi grateVolumeCommand:
{volumeId:106,volumePath:ROOT-40-01,pool:
{id:8,uuid:251a42e1-7316-30a8-ad11-bf03421f39f2,host:10.147.28.7,path:/export/home/manasa/priVMw2,port:2049,type:NetworkFilesystem}
,attachedVmName:i-2-40-VM,wait:3600}
2014-12-24 15:13:29,422 INFO [c.c.h.v.m.VirtualMachineMO]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Look for disk devic e info from volume :
ROOT-40-01.vmdk with trimmed base name: ROOT-40
2014-12-24 15:13:29,422 INFO [c.c.h.v.m.VirtualMachineMO]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Test against disk d evice, controller key: 1000, unit
number: 0
2014-11-24 15:13:29,422 INFO [c.c.h.v.m.VirtualMachineMO]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Test against disk b acking :
[f159abf3a6863ff1ad6a24d59100bdb9] vm-test/ROOT-40-01.vmdk
2014-12-24 15:13:29,422 ERROR [c.c.h.v.r.VmwareResource]
(DirectAgent-325:ctx-0dbf332a 10.147.40.14, job-760/job-761, cmd:
MigrateVolumeCommand) Catch Exception java. lang.Exception due to
java.lang.Exception: No such disk device: ROOT-40-01.vmdk
java.lang.Exception: No such disk device: ROOT-40-01.vmdk
at
com.cloud.hypervisor.vmware.resource.VmwareResource.getVirtualDiskInfo(VmwareResource.java:3366)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3319)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:403)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:304)
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$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
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:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2014-11-24 15:13:29,424 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-325:ctx-0dbf332a) Seq 5-6870804181507113730: Response Received:
2014-11-24 15:13:29,425 DEBUG [c.c.a.t.Request]
(DirectAgent-325:ctx-0dbf332a) Seq 5-6870804181507113730: Processing: { Ans:
, MgmtId:
[jira] [Created] (CLOUDSTACK-8119) [VMware] Attaching multiple volumes to a VM is failing.
Likitha Shetty created CLOUDSTACK-8119:
--
Summary: [VMware] Attaching multiple volumes to a VM is failing.
Key: CLOUDSTACK-8119
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8119
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Deploy a VM using default template.
2. Created 13 volumes.
4. Attach 8 volumes to the VM.
Attaching the 9th volume to VM, will fail with following exception:
{noformat}
2014-11-24 12:15:05,301 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-73:ctx-eea7360f job-612/job-613 ctx-455626cf) Seq
5-6870804181507113057: Executing: { Cmd , MgmtId: 6662467354709, via:
5(10.147.40.14), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.AttachCommand:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:7a3ae3ed-42dc-4b39-aa49-f247ccb5b20d,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:f159abf3-a686-3ff1-ad6a-24d59100bdb9,id:3,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/manasa/primaryVMw2,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/manasa/primaryVMw2/?ROLE=PrimarySTOREUUID=f159abf3-a686-3ff1-ad6a-24d59100bdb9}},name:vol10,size:5368709120,path:f43757595f63473eb2e49643f76b63f1,volumeId:89,accountId:2,format:OVA,provisioningType:THIN,id:89,hypervisorType:VMware}},diskSeq:9,path:f43757595f63473eb2e49643f76b63f1,type:DATADISK,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:5368709120}},vmName:i-2-25-VM,inSeq:false,diskController:scsi,wait:0}}]
}
2014-11-24 12:15:05,301 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-97:ctx-11cd0d9d) Seq 5-6870804181507113057: Executing request
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) find VM i-2-25-VM on host
2014-11-24 12:15:05,388 INFO [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) VM i-2-25-VM not found in
host cache
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) load VM cache on host
2014-11-24 12:15:05,536 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Folder test2 exists on datastore
2014-11-24 12:15:05,541 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,562 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9] f43757595f63473eb2e49643f76b63f1.vmdk
does not exist on datastore
2014-11-24 12:15:05,567 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9] test2
2014-11-24 12:15:05,591 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9]
test2/f43757595f63473eb2e49643f76b63f1.vmdk exists on datastore
2014-11-24 12:15:05,597 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1-flat.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,622 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-flat.vmdk does not exist on datastore
2014-11-24 12:15:05,630 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1-delta.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,655 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-delta.vmdk does not exist on datastore
2014-11-24 12:15:05,660 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,681 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9]
[jira] [Commented] (CLOUDSTACK-8117) Increase the allowed margin (+/-) for memory of VM on hyperv used to equate with the memory specified in service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257976#comment-14257976 ] ASF subversion and git services commented on CLOUDSTACK-8117: - Commit 239150c558380ee860ae991c0d7f197030087463 in cloudstack's branch refs/heads/4.5 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=239150c ] CLOUDSTACK-8117: Increase the allowed margin (+/-) for memory of VM on hyperv used to equate with the memory specified in service offering Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org Increase the allowed margin (+/-) for memory of VM on hyperv used to equate with the memory specified in service offering - Key: CLOUDSTACK-8117 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8117 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 Increase the allowed margin (+/-) for memory of VM on hyperv used to equate with the memory specified in service offering. Large component of memory is consumed by the Ui component, hence the memory for VM is listed lesser than that is specified in the service offering. Increase the range from 20 to 200 for hyperv because of the difference in template used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8116) Move ldap config data to configurableData section in test_data.py and make related changes in the test case
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257977#comment-14257977 ] ASF subversion and git services commented on CLOUDSTACK-8116: - Commit 94237a4c5b08356bb0a4950ce9fd7ec78f2168f9 in cloudstack's branch refs/heads/4.5 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=94237a4 ] CLOUDSTACK-8116: Moved ldap data to configurableData section in test_data.py and made related changes in the test case Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org Move ldap config data to configurableData section in test_data.py and make related changes in the test case --- Key: CLOUDSTACK-8116 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8116 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8119) [VMware] Attaching multiple volumes to a VM is failing.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257980#comment-14257980
]
ASF subversion and git services commented on CLOUDSTACK-8119:
-
Commit f420dd55fb5c4ec40aec0232618b2162c6d2f88c in cloudstack's branch
refs/heads/master from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f420dd5 ]
CLOUDSTACK-8119. [VMware] Cannot attach more than 8 volumes to a VM.
While attaching a new disk to an instance, the unit number on the controller
key should be the lowest unit number
that is not in use. And in case the controller type is SCSI it shouln't be the
reserved SCSI unit number.
[VMware] Attaching multiple volumes to a VM is failing.
---
Key: CLOUDSTACK-8119
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8119
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Deploy a VM using default template.
2. Created 13 volumes.
4. Attach 8 volumes to the VM.
Attaching the 9th volume to VM, will fail with following exception:
{noformat}
2014-11-24 12:15:05,301 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-73:ctx-eea7360f job-612/job-613 ctx-455626cf) Seq
5-6870804181507113057: Executing: { Cmd , MgmtId: 6662467354709, via:
5(10.147.40.14), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.AttachCommand:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:7a3ae3ed-42dc-4b39-aa49-f247ccb5b20d,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:f159abf3-a686-3ff1-ad6a-24d59100bdb9,id:3,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/manasa/primaryVMw2,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/manasa/primaryVMw2/?ROLE=PrimarySTOREUUID=f159abf3-a686-3ff1-ad6a-24d59100bdb9}},name:vol10,size:5368709120,path:f43757595f63473eb2e49643f76b63f1,volumeId:89,accountId:2,format:OVA,provisioningType:THIN,id:89,hypervisorType:VMware}},diskSeq:9,path:f43757595f63473eb2e49643f76b63f1,type:DATADISK,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:5368709120}},vmName:i-2-25-VM,inSeq:false,diskController:scsi,wait:0}}]
}
2014-11-24 12:15:05,301 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-97:ctx-11cd0d9d) Seq 5-6870804181507113057: Executing request
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) find VM i-2-25-VM on host
2014-11-24 12:15:05,388 INFO [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) VM i-2-25-VM not found in
host cache
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) load VM cache on host
2014-11-24 12:15:05,536 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Folder test2 exists on datastore
2014-11-24 12:15:05,541 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,562 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1.vmdk does not exist on datastore
2014-11-24 12:15:05,567 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9] test2
2014-11-24 12:15:05,591 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
test2/f43757595f63473eb2e49643f76b63f1.vmdk exists on datastore
2014-11-24 12:15:05,597 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1-flat.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,622 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-flat.vmdk does not exist on datastore
2014-11-24 12:15:05,630 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14,
[jira] [Updated] (CLOUDSTACK-8119) [VMware] Attaching multiple volumes to a VM is failing.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty updated CLOUDSTACK-8119:
---
Description:
+Steps to reproduce+
1. Deploy a VM using default template.
2. Creat 13 volumes.
3. Attach 8 volumes to the VM.
4. Attach 9th volume to the VM, it will fail with following exception:
{noformat}
2014-11-24 12:15:05,301 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-73:ctx-eea7360f job-612/job-613 ctx-455626cf) Seq
5-6870804181507113057: Executing: { Cmd , MgmtId: 6662467354709, via:
5(10.147.40.14), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.AttachCommand:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:7a3ae3ed-42dc-4b39-aa49-f247ccb5b20d,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:f159abf3-a686-3ff1-ad6a-24d59100bdb9,id:3,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/manasa/primaryVMw2,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/manasa/primaryVMw2/?ROLE=PrimarySTOREUUID=f159abf3-a686-3ff1-ad6a-24d59100bdb9}},name:vol10,size:5368709120,path:f43757595f63473eb2e49643f76b63f1,volumeId:89,accountId:2,format:OVA,provisioningType:THIN,id:89,hypervisorType:VMware}},diskSeq:9,path:f43757595f63473eb2e49643f76b63f1,type:DATADISK,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:5368709120}},vmName:i-2-25-VM,inSeq:false,diskController:scsi,wait:0}}]
}
2014-11-24 12:15:05,301 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-97:ctx-11cd0d9d) Seq 5-6870804181507113057: Executing request
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) find VM i-2-25-VM on host
2014-11-24 12:15:05,388 INFO [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) VM i-2-25-VM not found in
host cache
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) load VM cache on host
2014-11-24 12:15:05,536 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Folder test2 exists on datastore
2014-11-24 12:15:05,541 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,562 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9] f43757595f63473eb2e49643f76b63f1.vmdk
does not exist on datastore
2014-11-24 12:15:05,567 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9] test2
2014-11-24 12:15:05,591 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9]
test2/f43757595f63473eb2e49643f76b63f1.vmdk exists on datastore
2014-11-24 12:15:05,597 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1-flat.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,622 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-flat.vmdk does not exist on datastore
2014-11-24 12:15:05,630 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1-delta.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,655 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-delta.vmdk does not exist on datastore
2014-11-24 12:15:05,660 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,681 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9] f43757595f63473eb2e49643f76b63f1.vmdk
does not exist on datastore
2014-11-24 12:15:05,733 INFO [c.c.h.v.u.VmwareContext]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Connected, conn:
[jira] [Updated] (CLOUDSTACK-8119) [VMware] Attaching multiple volumes to a VM is failing.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty updated CLOUDSTACK-8119:
---
Description:
+Steps to reproduce+
1. Deploy a VM using default template.
2. Created 13 volumes.
3. Attach 8 volumes to the VM.
4. Attach 9th volume to the VM, it will fail with following exception:
{noformat}
2014-11-24 12:15:05,301 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-73:ctx-eea7360f job-612/job-613 ctx-455626cf) Seq
5-6870804181507113057: Executing: { Cmd , MgmtId: 6662467354709, via:
5(10.147.40.14), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.AttachCommand:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:7a3ae3ed-42dc-4b39-aa49-f247ccb5b20d,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:f159abf3-a686-3ff1-ad6a-24d59100bdb9,id:3,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/manasa/primaryVMw2,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/manasa/primaryVMw2/?ROLE=PrimarySTOREUUID=f159abf3-a686-3ff1-ad6a-24d59100bdb9}},name:vol10,size:5368709120,path:f43757595f63473eb2e49643f76b63f1,volumeId:89,accountId:2,format:OVA,provisioningType:THIN,id:89,hypervisorType:VMware}},diskSeq:9,path:f43757595f63473eb2e49643f76b63f1,type:DATADISK,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:5368709120}},vmName:i-2-25-VM,inSeq:false,diskController:scsi,wait:0}}]
}
2014-11-24 12:15:05,301 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-97:ctx-11cd0d9d) Seq 5-6870804181507113057: Executing request
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) find VM i-2-25-VM on host
2014-11-24 12:15:05,388 INFO [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) VM i-2-25-VM not found in
host cache
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) load VM cache on host
2014-11-24 12:15:05,536 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Folder test2 exists on datastore
2014-11-24 12:15:05,541 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,562 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9] f43757595f63473eb2e49643f76b63f1.vmdk
does not exist on datastore
2014-11-24 12:15:05,567 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9] test2
2014-11-24 12:15:05,591 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9]
test2/f43757595f63473eb2e49643f76b63f1.vmdk exists on datastore
2014-11-24 12:15:05,597 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1-flat.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,622 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-flat.vmdk does not exist on datastore
2014-11-24 12:15:05,630 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1-delta.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,655 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-delta.vmdk does not exist on datastore
2014-11-24 12:15:05,660 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,681 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
File [f159abf3a6863ff1ad6a24d59100bdb9] f43757595f63473eb2e49643f76b63f1.vmdk
does not exist on datastore
2014-11-24 12:15:05,733 INFO [c.c.h.v.u.VmwareContext]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd: AttachCommand)
Connected, conn:
[jira] [Resolved] (CLOUDSTACK-8119) [VMware] Attaching multiple volumes to a VM is failing.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty resolved CLOUDSTACK-8119.
Resolution: Fixed
During the addition of the 9th disks, while trying to decide the device number
on the controller key for the volume, CCP was picking the device number of the
previous volume. And that is why the disk addition failed with 'Invalid
configuration' in vCenter.
[VMware] Attaching multiple volumes to a VM is failing.
---
Key: CLOUDSTACK-8119
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8119
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Deploy a VM using default template.
2. Creat 13 volumes.
3. Attach 8 volumes to the VM.
4. Attach 9th volume to the VM, it will fail with following exception:
{noformat}
2014-11-24 12:15:05,301 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-73:ctx-eea7360f job-612/job-613 ctx-455626cf) Seq
5-6870804181507113057: Executing: { Cmd , MgmtId: 6662467354709, via:
5(10.147.40.14), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.AttachCommand:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:7a3ae3ed-42dc-4b39-aa49-f247ccb5b20d,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:f159abf3-a686-3ff1-ad6a-24d59100bdb9,id:3,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/manasa/primaryVMw2,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/manasa/primaryVMw2/?ROLE=PrimarySTOREUUID=f159abf3-a686-3ff1-ad6a-24d59100bdb9}},name:vol10,size:5368709120,path:f43757595f63473eb2e49643f76b63f1,volumeId:89,accountId:2,format:OVA,provisioningType:THIN,id:89,hypervisorType:VMware}},diskSeq:9,path:f43757595f63473eb2e49643f76b63f1,type:DATADISK,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:5368709120}},vmName:i-2-25-VM,inSeq:false,diskController:scsi,wait:0}}]
}
2014-11-24 12:15:05,301 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-97:ctx-11cd0d9d) Seq 5-6870804181507113057: Executing request
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) find VM i-2-25-VM on host
2014-11-24 12:15:05,388 INFO [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) VM i-2-25-VM not found in
host cache
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) load VM cache on host
2014-11-24 12:15:05,536 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Folder test2 exists on datastore
2014-11-24 12:15:05,541 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,562 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1.vmdk does not exist on datastore
2014-11-24 12:15:05,567 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9] test2
2014-11-24 12:15:05,591 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
test2/f43757595f63473eb2e49643f76b63f1.vmdk exists on datastore
2014-11-24 12:15:05,597 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1-flat.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,622 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-flat.vmdk does not exist on datastore
2014-11-24 12:15:05,630 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1-delta.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,655 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File
[jira] [Commented] (CLOUDSTACK-8117) Increase the allowed margin (+/-) for memory of VM on hyperv used to equate with the memory specified in service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257990#comment-14257990 ] ASF subversion and git services commented on CLOUDSTACK-8117: - Commit 67eff27f548ec8a708247938c93200f27e22073b in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=67eff27 ] CLOUDSTACK-8117: Increase the allowed margin (+/-) for memory of VM on hyperv used to equate with the memory specified in service offering Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org Increase the allowed margin (+/-) for memory of VM on hyperv used to equate with the memory specified in service offering - Key: CLOUDSTACK-8117 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8117 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 Increase the allowed margin (+/-) for memory of VM on hyperv used to equate with the memory specified in service offering. Large component of memory is consumed by the Ui component, hence the memory for VM is listed lesser than that is specified in the service offering. Increase the range from 20 to 200 for hyperv because of the difference in template used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8116) Move ldap config data to configurableData section in test_data.py and make related changes in the test case
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14257989#comment-14257989 ] ASF subversion and git services commented on CLOUDSTACK-8116: - Commit 0ed40140a67737c91a8e2ab15b3d55073c8eedf7 in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0ed4014 ] CLOUDSTACK-8116: Moved ldap data to configurableData section in test_data.py and made related changes in the test case Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org Move ldap config data to configurableData section in test_data.py and make related changes in the test case --- Key: CLOUDSTACK-8116 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8116 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8120) Propagate error message to UI for attach/detach volume failure operations.
Likitha Shetty created CLOUDSTACK-8120:
--
Summary: Propagate error message to UI for attach/detach volume
failure operations.
Key: CLOUDSTACK-8120
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8120
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
Steps:
1. Have a VMware setup.
2. Deploy Windows XP instance with one Datadisk.
3. Try to attach a volume to the running Win XP instance - Fails.
4. Try to detach the additional datadisk attached to the running Win XP
instance - Fails.
Reason for the above failures is that in case of VMware a Windows XP instance
need to be in powered off state to be able to perform attach/detach on the
instance. But the UI failure reads - 'Unexpected Exception'. CS should instead
throw the right error message.
Logs -
{noformat}
2014-11-26 11:02:49,663 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-27:ctx-19c52bfe job-84/job-85) Done executing
com.cloud.vm.VmWorkAttachVolume for job-85
2014-11-26 11:02:49,666 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl]
(Work-Job-Executor-27:ctx-19c52bfe job-84/job-85) Sync queue (5) is currently
empty
2014-11-26 11:02:49,667 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Work-Job-Executor-27:ctx-19c52bfe job-84/job-85) Remove job-85 from job
monitoring
2014-11-26 11:02:49,671 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-40:ctx-15db2b48 job-84) Unexpected exception while executing
org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin
java.lang.RuntimeException: Unexpected exception
at
com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1386)
at
com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1168)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy185.attachVolumeToVM(Unknown Source)
at
org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin.execute(AttachVolumeCmdByAdmin.java:40)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:536)
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
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:493)
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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: com.cloud.utils.exception.CloudRuntimeException: Failed to attach
volume DATA-3 to VM win16GBinst1; AttachVolumeCommand failed due to Exception:
java.lang.Exception
Message: Adding a virtual disk over IDE controller is not supported while VM is
running in VMware hypervisor. Please re-try when VM is not running.
at
com.cloud.storage.VolumeApiServiceImpl.sendAttachVolumeCommand(VolumeApiServiceImpl.java:2304)
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1237)
at
[jira] [Commented] (CLOUDSTACK-8119) [VMware] Attaching multiple volumes to a VM is failing.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258008#comment-14258008
]
ASF subversion and git services commented on CLOUDSTACK-8119:
-
Commit 4d7ede535df568c6aab4a228ac794ec11d433e1e in cloudstack's branch
refs/heads/master from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4d7ede5 ]
CLOUDSTACK-8119. Propagate error message to UI for attach/detach volume failure
operations.
For AttachVolume/DetachVolume API command, improve user error message in case
of RuntimeException by throwing the exception instead of 'Unexpected Exception'.
[VMware] Attaching multiple volumes to a VM is failing.
---
Key: CLOUDSTACK-8119
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8119
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Deploy a VM using default template.
2. Creat 13 volumes.
3. Attach 8 volumes to the VM.
4. Attach 9th volume to the VM, it will fail with following exception:
{noformat}
2014-11-24 12:15:05,301 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-73:ctx-eea7360f job-612/job-613 ctx-455626cf) Seq
5-6870804181507113057: Executing: { Cmd , MgmtId: 6662467354709, via:
5(10.147.40.14), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.AttachCommand:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:7a3ae3ed-42dc-4b39-aa49-f247ccb5b20d,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:f159abf3-a686-3ff1-ad6a-24d59100bdb9,id:3,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/manasa/primaryVMw2,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/manasa/primaryVMw2/?ROLE=PrimarySTOREUUID=f159abf3-a686-3ff1-ad6a-24d59100bdb9}},name:vol10,size:5368709120,path:f43757595f63473eb2e49643f76b63f1,volumeId:89,accountId:2,format:OVA,provisioningType:THIN,id:89,hypervisorType:VMware}},diskSeq:9,path:f43757595f63473eb2e49643f76b63f1,type:DATADISK,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:5368709120}},vmName:i-2-25-VM,inSeq:false,diskController:scsi,wait:0}}]
}
2014-11-24 12:15:05,301 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-97:ctx-11cd0d9d) Seq 5-6870804181507113057: Executing request
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) find VM i-2-25-VM on host
2014-11-24 12:15:05,388 INFO [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) VM i-2-25-VM not found in
host cache
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) load VM cache on host
2014-11-24 12:15:05,536 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Folder test2 exists on datastore
2014-11-24 12:15:05,541 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,562 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1.vmdk does not exist on datastore
2014-11-24 12:15:05,567 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9] test2
2014-11-24 12:15:05,591 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
test2/f43757595f63473eb2e49643f76b63f1.vmdk exists on datastore
2014-11-24 12:15:05,597 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1-flat.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,622 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-flat.vmdk does not exist on datastore
2014-11-24 12:15:05,630 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search
[jira] [Commented] (CLOUDSTACK-8120) Propagate error message to UI for attach/detach volume failure operations.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258012#comment-14258012
]
Likitha Shetty commented on CLOUDSTACK-8120:
Commit 4d7ede535df568c6aab4a228ac794ec11d433e1e in cloudstack's branch
refs/heads/master from Likitha Shetty
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4d7ede5 ]
CLOUDSTACK-8119. Propagate error message to UI for attach/detach volume failure
operations.
For AttachVolume/DetachVolume API command, improve user error message in case
of RuntimeException by throwing the exception instead of 'Unexpected Exception'.
Propagate error message to UI for attach/detach volume failure operations.
--
Key: CLOUDSTACK-8120
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8120
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
Steps:
1. Have a VMware setup.
2. Deploy Windows XP instance with one Datadisk.
3. Try to attach a volume to the running Win XP instance - Fails.
4. Try to detach the additional datadisk attached to the running Win XP
instance - Fails.
Reason for the above failures is that in case of VMware a Windows XP instance
need to be in powered off state to be able to perform attach/detach on the
instance. But the UI failure reads - 'Unexpected Exception'. CS should
instead throw the right error message.
Logs -
{noformat}
2014-11-26 11:02:49,663 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-27:ctx-19c52bfe job-84/job-85) Done executing
com.cloud.vm.VmWorkAttachVolume for job-85
2014-11-26 11:02:49,666 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl]
(Work-Job-Executor-27:ctx-19c52bfe job-84/job-85) Sync queue (5) is currently
empty
2014-11-26 11:02:49,667 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Work-Job-Executor-27:ctx-19c52bfe job-84/job-85) Remove job-85 from job
monitoring
2014-11-26 11:02:49,671 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-40:ctx-15db2b48 job-84) Unexpected exception while
executing
org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin
java.lang.RuntimeException: Unexpected exception
at
com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1386)
at
com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1168)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy185.attachVolumeToVM(Unknown Source)
at
org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin.execute(AttachVolumeCmdByAdmin.java:40)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:536)
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
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:493)
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
[jira] [Resolved] (CLOUDSTACK-8120) Propagate error message to UI for attach/detach volume failure operations.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty resolved CLOUDSTACK-8120.
Resolution: Fixed
Windows XP instance need to be powered off to perform detach/attach of
additional data disks. Hence an appropriate error message is thrown back by the
Resource layer. But this error is not handled at the Server layer.
Propagate error message to UI for attach/detach volume failure operations.
--
Key: CLOUDSTACK-8120
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8120
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
Steps:
1. Have a VMware setup.
2. Deploy Windows XP instance with one Datadisk.
3. Try to attach a volume to the running Win XP instance - Fails.
4. Try to detach the additional datadisk attached to the running Win XP
instance - Fails.
Reason for the above failures is that in case of VMware a Windows XP instance
need to be in powered off state to be able to perform attach/detach on the
instance. But the UI failure reads - 'Unexpected Exception'. CS should
instead throw the right error message.
Logs -
{noformat}
2014-11-26 11:02:49,663 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-27:ctx-19c52bfe job-84/job-85) Done executing
com.cloud.vm.VmWorkAttachVolume for job-85
2014-11-26 11:02:49,666 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl]
(Work-Job-Executor-27:ctx-19c52bfe job-84/job-85) Sync queue (5) is currently
empty
2014-11-26 11:02:49,667 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Work-Job-Executor-27:ctx-19c52bfe job-84/job-85) Remove job-85 from job
monitoring
2014-11-26 11:02:49,671 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-40:ctx-15db2b48 job-84) Unexpected exception while
executing
org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin
java.lang.RuntimeException: Unexpected exception
at
com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1386)
at
com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1168)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy185.attachVolumeToVM(Unknown Source)
at
org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin.execute(AttachVolumeCmdByAdmin.java:40)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:536)
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
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:493)
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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by:
[jira] [Commented] (CLOUDSTACK-8119) [VMware] Attaching multiple volumes to a VM is failing.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258024#comment-14258024
]
ASF subversion and git services commented on CLOUDSTACK-8119:
-
Commit b1bca2a2c02d0f0f5e3435fe2587334ae107495d in cloudstack's branch
refs/heads/master from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b1bca2a ]
CLOUDSTACK-8119. [VMware] Cannot attach more than 8 volumes to a VM.
[VMware] Attaching multiple volumes to a VM is failing.
---
Key: CLOUDSTACK-8119
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8119
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Deploy a VM using default template.
2. Creat 13 volumes.
3. Attach 8 volumes to the VM.
4. Attach 9th volume to the VM, it will fail with following exception:
{noformat}
2014-11-24 12:15:05,301 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-73:ctx-eea7360f job-612/job-613 ctx-455626cf) Seq
5-6870804181507113057: Executing: { Cmd , MgmtId: 6662467354709, via:
5(10.147.40.14), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.AttachCommand:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:7a3ae3ed-42dc-4b39-aa49-f247ccb5b20d,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:f159abf3-a686-3ff1-ad6a-24d59100bdb9,id:3,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/manasa/primaryVMw2,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/manasa/primaryVMw2/?ROLE=PrimarySTOREUUID=f159abf3-a686-3ff1-ad6a-24d59100bdb9}},name:vol10,size:5368709120,path:f43757595f63473eb2e49643f76b63f1,volumeId:89,accountId:2,format:OVA,provisioningType:THIN,id:89,hypervisorType:VMware}},diskSeq:9,path:f43757595f63473eb2e49643f76b63f1,type:DATADISK,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:5368709120}},vmName:i-2-25-VM,inSeq:false,diskController:scsi,wait:0}}]
}
2014-11-24 12:15:05,301 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-97:ctx-11cd0d9d) Seq 5-6870804181507113057: Executing request
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) find VM i-2-25-VM on host
2014-11-24 12:15:05,388 INFO [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) VM i-2-25-VM not found in
host cache
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) load VM cache on host
2014-11-24 12:15:05,536 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Folder test2 exists on datastore
2014-11-24 12:15:05,541 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,562 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1.vmdk does not exist on datastore
2014-11-24 12:15:05,567 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9] test2
2014-11-24 12:15:05,591 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
test2/f43757595f63473eb2e49643f76b63f1.vmdk exists on datastore
2014-11-24 12:15:05,597 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1-flat.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,622 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-flat.vmdk does not exist on datastore
2014-11-24 12:15:05,630 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1-delta.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,655 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d
[jira] [Issue Comment Deleted] (CLOUDSTACK-8119) [VMware] Attaching multiple volumes to a VM is failing.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty updated CLOUDSTACK-8119:
---
Comment: was deleted
(was: Please ignore, this commit was meant to resolve CLOUDSTACK-8120.)
[VMware] Attaching multiple volumes to a VM is failing.
---
Key: CLOUDSTACK-8119
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8119
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Deploy a VM using default template.
2. Creat 13 volumes.
3. Attach 8 volumes to the VM.
4. Attach 9th volume to the VM, it will fail with following exception:
{noformat}
2014-11-24 12:15:05,301 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-73:ctx-eea7360f job-612/job-613 ctx-455626cf) Seq
5-6870804181507113057: Executing: { Cmd , MgmtId: 6662467354709, via:
5(10.147.40.14), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.AttachCommand:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:7a3ae3ed-42dc-4b39-aa49-f247ccb5b20d,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:f159abf3-a686-3ff1-ad6a-24d59100bdb9,id:3,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/manasa/primaryVMw2,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/manasa/primaryVMw2/?ROLE=PrimarySTOREUUID=f159abf3-a686-3ff1-ad6a-24d59100bdb9}},name:vol10,size:5368709120,path:f43757595f63473eb2e49643f76b63f1,volumeId:89,accountId:2,format:OVA,provisioningType:THIN,id:89,hypervisorType:VMware}},diskSeq:9,path:f43757595f63473eb2e49643f76b63f1,type:DATADISK,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:5368709120}},vmName:i-2-25-VM,inSeq:false,diskController:scsi,wait:0}}]
}
2014-11-24 12:15:05,301 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-97:ctx-11cd0d9d) Seq 5-6870804181507113057: Executing request
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) find VM i-2-25-VM on host
2014-11-24 12:15:05,388 INFO [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) VM i-2-25-VM not found in
host cache
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) load VM cache on host
2014-11-24 12:15:05,536 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Folder test2 exists on datastore
2014-11-24 12:15:05,541 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,562 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1.vmdk does not exist on datastore
2014-11-24 12:15:05,567 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9] test2
2014-11-24 12:15:05,591 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
test2/f43757595f63473eb2e49643f76b63f1.vmdk exists on datastore
2014-11-24 12:15:05,597 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1-flat.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,622 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-flat.vmdk does not exist on datastore
2014-11-24 12:15:05,630 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1-delta.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,655 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-delta.vmdk does not exist on datastore
2014-11-24 12:15:05,660 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d
[jira] [Commented] (CLOUDSTACK-8119) [VMware] Attaching multiple volumes to a VM is failing.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258026#comment-14258026
]
Likitha Shetty commented on CLOUDSTACK-8119:
Please ignore, this commit was meant to resolve CLOUDSTACK-8120.
[VMware] Attaching multiple volumes to a VM is failing.
---
Key: CLOUDSTACK-8119
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8119
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Deploy a VM using default template.
2. Creat 13 volumes.
3. Attach 8 volumes to the VM.
4. Attach 9th volume to the VM, it will fail with following exception:
{noformat}
2014-11-24 12:15:05,301 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-73:ctx-eea7360f job-612/job-613 ctx-455626cf) Seq
5-6870804181507113057: Executing: { Cmd , MgmtId: 6662467354709, via:
5(10.147.40.14), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.AttachCommand:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:7a3ae3ed-42dc-4b39-aa49-f247ccb5b20d,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:f159abf3-a686-3ff1-ad6a-24d59100bdb9,id:3,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/manasa/primaryVMw2,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/manasa/primaryVMw2/?ROLE=PrimarySTOREUUID=f159abf3-a686-3ff1-ad6a-24d59100bdb9}},name:vol10,size:5368709120,path:f43757595f63473eb2e49643f76b63f1,volumeId:89,accountId:2,format:OVA,provisioningType:THIN,id:89,hypervisorType:VMware}},diskSeq:9,path:f43757595f63473eb2e49643f76b63f1,type:DATADISK,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:5368709120}},vmName:i-2-25-VM,inSeq:false,diskController:scsi,wait:0}}]
}
2014-11-24 12:15:05,301 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-97:ctx-11cd0d9d) Seq 5-6870804181507113057: Executing request
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) find VM i-2-25-VM on host
2014-11-24 12:15:05,388 INFO [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) VM i-2-25-VM not found in
host cache
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) load VM cache on host
2014-11-24 12:15:05,536 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Folder test2 exists on datastore
2014-11-24 12:15:05,541 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,562 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1.vmdk does not exist on datastore
2014-11-24 12:15:05,567 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9] test2
2014-11-24 12:15:05,591 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
test2/f43757595f63473eb2e49643f76b63f1.vmdk exists on datastore
2014-11-24 12:15:05,597 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1-flat.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,622 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-flat.vmdk does not exist on datastore
2014-11-24 12:15:05,630 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1-delta.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,655 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-delta.vmdk does not exist on datastore
2014-11-24 12:15:05,660 INFO [c.c.h.v.m.DatastoreMO]
[jira] [Commented] (CLOUDSTACK-8119) [VMware] Attaching multiple volumes to a VM is failing.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258027#comment-14258027
]
Likitha Shetty commented on CLOUDSTACK-8119:
Please ignore, this commit was meant to resolve CLOUDSTACK-8120.
[VMware] Attaching multiple volumes to a VM is failing.
---
Key: CLOUDSTACK-8119
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8119
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: Future
+Steps to reproduce+
1. Deploy a VM using default template.
2. Creat 13 volumes.
3. Attach 8 volumes to the VM.
4. Attach 9th volume to the VM, it will fail with following exception:
{noformat}
2014-11-24 12:15:05,301 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-73:ctx-eea7360f job-612/job-613 ctx-455626cf) Seq
5-6870804181507113057: Executing: { Cmd , MgmtId: 6662467354709, via:
5(10.147.40.14), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.AttachCommand:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:7a3ae3ed-42dc-4b39-aa49-f247ccb5b20d,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:f159abf3-a686-3ff1-ad6a-24d59100bdb9,id:3,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/manasa/primaryVMw2,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/manasa/primaryVMw2/?ROLE=PrimarySTOREUUID=f159abf3-a686-3ff1-ad6a-24d59100bdb9}},name:vol10,size:5368709120,path:f43757595f63473eb2e49643f76b63f1,volumeId:89,accountId:2,format:OVA,provisioningType:THIN,id:89,hypervisorType:VMware}},diskSeq:9,path:f43757595f63473eb2e49643f76b63f1,type:DATADISK,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:5368709120}},vmName:i-2-25-VM,inSeq:false,diskController:scsi,wait:0}}]
}
2014-11-24 12:15:05,301 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-97:ctx-11cd0d9d) Seq 5-6870804181507113057: Executing request
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) find VM i-2-25-VM on host
2014-11-24 12:15:05,388 INFO [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) VM i-2-25-VM not found in
host cache
2014-11-24 12:15:05,388 DEBUG [c.c.h.v.m.HostMO] (DirectAgent-97:ctx-11cd0d9d
10.147.40.14, job-612/job-613, cmd: AttachCommand) load VM cache on host
2014-11-24 12:15:05,536 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Folder test2 exists on datastore
2014-11-24 12:15:05,541 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,562 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1.vmdk does not exist on datastore
2014-11-24 12:15:05,567 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9] test2
2014-11-24 12:15:05,591 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
test2/f43757595f63473eb2e49643f76b63f1.vmdk exists on datastore
2014-11-24 12:15:05,597 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1-flat.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,622 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-flat.vmdk does not exist on datastore
2014-11-24 12:15:05,630 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) Search file f43757595f63473eb2e49643f76b63f1-delta.vmdk on
[f159abf3a6863ff1ad6a24d59100bdb9]
2014-11-24 12:15:05,655 INFO [c.c.h.v.m.DatastoreMO]
(DirectAgent-97:ctx-11cd0d9d 10.147.40.14, job-612/job-613, cmd:
AttachCommand) File [f159abf3a6863ff1ad6a24d59100bdb9]
f43757595f63473eb2e49643f76b63f1-delta.vmdk does not exist on datastore
2014-11-24 12:15:05,660 INFO [c.c.h.v.m.DatastoreMO]
[jira] [Commented] (CLOUDSTACK-6463) password is not set for VMs created from password enabled template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258061#comment-14258061 ] Andrija Panic commented on CLOUDSTACK-6463: --- Interesting stuff here - for me, when this happens, it was enough just to reboot VM, and it will fetch the password that was obviously generated in the meantime, and there was a coresponding line in the /var/cache/cloud/password (first VM start - no line in VR, reboot VM, and the line was created in the meantime...) password is not set for VMs created from password enabled template -- Key: CLOUDSTACK-6463 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6463 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.4.0 Repro steps: 1.Create a password enabled template 2. Create a VM from password enabled template 3. Login to VM using the provided password Bug: Unable to login to VM using provided password . Neither able to login to VM using standard password =password Expected result: Password should be set . Additional information.. Cannot find password entry at router vm at following location /var/cache/cloud/password Resetting password for VM is working fine. i.e if we try to reset Password for this VM .and the password we get now will work and we will be able to login to VM with the provided password. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8121) Creating/Deleting VM snapshots for a VM doesn't update the path and size of Data disks.
Likitha Shetty created CLOUDSTACK-8121: -- Summary: Creating/Deleting VM snapshots for a VM doesn't update the path and size of Data disks. Key: CLOUDSTACK-8121 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8121 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: Future +Steps to reproduce+ 1. Deploy VM with Datadisk. 2. Take a VM snapshot. 3. Check the path and size of the ROOT and Data volume in the DB. Properties of only the ROOT disk will be correctly updated and not Datadisk. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8121) Creating/Deleting VM snapshots for a VM doesn't update the path and size of Data disks.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14258081#comment-14258081 ] ASF subversion and git services commented on CLOUDSTACK-8121: - Commit ac491c96075d65e35157380fe7d28fdd917c0e90 in cloudstack's branch refs/heads/master from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ac491c9 ] CLOUDSTACK-8121. Data disk properties are not updated upon Creation/Deletion of VM snapshots. Update the path and size of data volumes after snapshot creation/deletion by correctly trimming only the snapshot postfix of a disk. Creating/Deleting VM snapshots for a VM doesn't update the path and size of Data disks. --- Key: CLOUDSTACK-8121 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8121 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: Future +Steps to reproduce+ 1. Deploy VM with Datadisk. 2. Take a VM snapshot. 3. Check the path and size of the ROOT and Data volume in the DB. Properties of only the ROOT disk will be correctly updated and not Datadisk. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8121) Creating/Deleting VM snapshots for a VM doesn't update the path and size of Data disks.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty resolved CLOUDSTACK-8121. Resolution: Fixed Creating/Deleting VM snapshots for a VM doesn't update the path and size of Data disks. --- Key: CLOUDSTACK-8121 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8121 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Priority: Critical Fix For: Future +Steps to reproduce+ 1. Deploy VM with Datadisk. 2. Take a VM snapshot. 3. Check the path and size of the ROOT and Data volume in the DB. Properties of only the ROOT disk will be correctly updated and not Datadisk. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
