[jira] [Closed] (CLOUDSTACK-7325) bug in iSCSI disconnectPhysicalDiskByPath
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi closed CLOUDSTACK-7325.
Fix Version/s: 4.12
Resolution: Fixed
Fixed in
[https://github.com/apache/cloudstack/commit/bf209405e7d60b6a5abf87677d368c429359d98a#diff-0c33aaec8a8fe2523c316f5e34485a87R352]
PR - [https://github.com/apache/cloudstack/pull/2997]
> bug in iSCSI disconnectPhysicalDiskByPath
> -
>
> Key: CLOUDSTACK-7325
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7325
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.4.0
>Reporter: Brian Angus
>Priority: Major
> Fix For: 4.12
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> in
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/IscsiAdmStorageAdaptor.java
> disconnectPhysicalDiskByPath
> If the disk does not have {noformat}-iscsi-{noformat} in its path then this
> code is ran:{code}
> // this volume doesn't below to this adaptor, so just return true
> return true;
> {code}
> It should return false. This way if the disk belongs to another storage
> adapter that adapter can disconnect the disk in the
> disconnectPhysicalDiskByPath function in KVMStoragePoolManager.java
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CLOUDSTACK-9616) KVM iSCSI adaptor: alllow other adaptors to disconnect disks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036629#comment-17036629 ] Sateesh Chodapuneedi edited comment on CLOUDSTACK-9616 at 2/14/20 1:34 AM: --- Fixed in https://github.com/apache/cloudstack/commit/bf209405e7d60b6a5abf87677d368c429359d98a#diff-0c33aaec8a8fe2523c316f5e34485a87R352 PR - [https://github.com/apache/cloudstack/pull/2997] was (Author: sateeshc): Fixed in [https://github.com/apache/cloudstack/commit/bf209405e7d60b6a5abf87677d368c429359d98a] PR - https://github.com/apache/cloudstack/pull/2997 > KVM iSCSI adaptor: alllow other adaptors to disconnect disks > > > Key: CLOUDSTACK-9616 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9616 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM > Environment: KVM hypervisor, more than one storage adaptor >Reporter: Peter Pentchev >Priority: Major > Labels: patch > Fix For: 4.12 > > > Hi, > Thanks for developing CloudStack! > If the following conditions are met: > - more than one storage adaptor is defined for a KVM storage pool > - a disconnectPhysicalDiskByPath() request comes in for the pool (the > KVMStoragePoolManager.disconnectPhysicalDiskByPath() method is invoked) > - the loop in that method finds the iSCSI adaptor first > - the disk being disconnected is *not* managed by the iSCSI adaptor > then the IscsiAdmStorageAdaptor.disconnectPhysicalDiskByPath() will > return a "true" value, signalling that the request has been handled, while it > has actually been silently ignored. > A patch making the iSCSI storage adaptor return "false" (thus allowing other > storage adaptors to process the request and actually disconnect the disk) is > available as a GitHub pull request at > https://github.com/apache/cloudstack/pull/1780 > Thanks in advance for your time and consideration! > Best regards, > Peter -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CLOUDSTACK-9616) KVM iSCSI adaptor: alllow other adaptors to disconnect disks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi closed CLOUDSTACK-9616. Fix Version/s: 4.12 Resolution: Fixed Fixed in [https://github.com/apache/cloudstack/commit/bf209405e7d60b6a5abf87677d368c429359d98a] PR - https://github.com/apache/cloudstack/pull/2997 > KVM iSCSI adaptor: alllow other adaptors to disconnect disks > > > Key: CLOUDSTACK-9616 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9616 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM > Environment: KVM hypervisor, more than one storage adaptor >Reporter: Peter Pentchev >Priority: Major > Labels: patch > Fix For: 4.12 > > > Hi, > Thanks for developing CloudStack! > If the following conditions are met: > - more than one storage adaptor is defined for a KVM storage pool > - a disconnectPhysicalDiskByPath() request comes in for the pool (the > KVMStoragePoolManager.disconnectPhysicalDiskByPath() method is invoked) > - the loop in that method finds the iSCSI adaptor first > - the disk being disconnected is *not* managed by the iSCSI adaptor > then the IscsiAdmStorageAdaptor.disconnectPhysicalDiskByPath() will > return a "true" value, signalling that the request has been handled, while it > has actually been silently ignored. > A patch making the iSCSI storage adaptor return "false" (thus allowing other > storage adaptors to process the request and actually disconnect the disk) is > available as a GitHub pull request at > https://github.com/apache/cloudstack/pull/1780 > Thanks in advance for your time and consideration! > Best regards, > Peter -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CLOUDSTACK-4390) Using full-clone by default for VMware deployment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-4390: - Fix Version/s: 4.2.0 > Using full-clone by default for VMware deployment > - > > Key: CLOUDSTACK-4390 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4390 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kelven Yang >Assignee: Kelven Yang >Priority: Critical > Fix For: 4.2.0 > > > To better integrate with VMware features like storage live migration, fully > utilize third-party integrations from vSphere eco-system, deploy VM in > full-clone mode by default -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9849) Cannot migrate VMware VM to host in different cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15972336#comment-15972336 ] Sateesh Chodapuneedi commented on CLOUDSTACK-9849: -- [~rajanik] Could not reproduce this issue with vSphere 5.1, vSphere 5.5, and vSphere 6.0. Live VM migration along with volumes is working fine where both source and destination hosts are having ESXi versions 5.1 or 5.5 or 6.0. We may need to check more details from the setup where failure was reported from. There are no code changes done between 4.9 and 4.10/master in case of storage migration of VM along with volumes for VMware. So this one could probably be a case we did not observe before, or environment issue. Need to confirm the issue though. Also, I see there exists integration tests for storage migration in test/integration/component/maint/testpath_vMotion_vmware.py which seems to be covering this scenario as well. Probably we can trigger these tests and see results to confirm any failures. > Cannot migrate VMware VM to host in different cluster > - > > Key: CLOUDSTACK-9849 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9849 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.10.0.0 > Environment: VMware 5.5 >Reporter: Mike Tutkowski >Assignee: Sateesh Chodapuneedi >Priority: Blocker > Fix For: 4.10.0.0 > > > I have two VMware clusters in the same VMware datacenter. Each cluster has a > single ESXi 5.5 host in it. > I have a shared primary storage in each cluster (I have tried this scenario > with both NFS and iSCSI shared primary storage and the results are the same). > I have a VM with its root disk running on primary storage from a host in the > one cluster and I cannot migrate this VM and its root disk to the host in the > other cluster (both primary storages even make use of the same storage tag). > The source host has access to the source datastore, but it does not have > access to the target datastore. > The target host has access to the target datastore, but it does not have > access to the source datastore. > When I try to perform the migration, it fails with the following error > message: > Required property datastore is missing from data object of type > VirtualMachineRelocateSpecDiskLocator > while parsing serialized DataObject of type vim.vm.RelocateSpec.DiskLocator > at line 1, column 327 > while parsing property "disk" of static type > ArrayOfVirtualMachineRelocateSpecDiskLocator > while parsing serialized DataObject of type vim.vm.RelocateSpec > at line 1, column 187 > while parsing call information for method RelocateVM_Task > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method relocate > on object of type vim.VirtualMachine > at line 1, column 0 > When I run the test in the debugger and look at the > VirtualMachineRelocateSpec instance passed to > VirtualMachineMO.changeDatastore, I see the target datastore is populated, > but not the source datastore: > http://imgur.com/a/vtKcq datastore-66 is the target datastore > Based on an e-mail chain on dev@, it sounds like my scenario should work. > Thanks! -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (CLOUDSTACK-9849) Cannot migrate VMware VM to host in different cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi reassigned CLOUDSTACK-9849: Assignee: Sateesh Chodapuneedi > Cannot migrate VMware VM to host in different cluster > - > > Key: CLOUDSTACK-9849 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9849 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.10.0.0 > Environment: VMware 5.5 >Reporter: Mike Tutkowski >Assignee: Sateesh Chodapuneedi >Priority: Blocker > Fix For: 4.10.0.0 > > > I have two VMware clusters in the same VMware datacenter. Each cluster has a > single ESXi 5.5 host in it. > I have a shared primary storage in each cluster (I have tried this scenario > with both NFS and iSCSI shared primary storage and the results are the same). > I have a VM with its root disk running on primary storage from a host in the > one cluster and I cannot migrate this VM and its root disk to the host in the > other cluster (both primary storages even make use of the same storage tag). > The source host has access to the source datastore, but it does not have > access to the target datastore. > The target host has access to the target datastore, but it does not have > access to the source datastore. > When I try to perform the migration, it fails with the following error > message: > Required property datastore is missing from data object of type > VirtualMachineRelocateSpecDiskLocator > while parsing serialized DataObject of type vim.vm.RelocateSpec.DiskLocator > at line 1, column 327 > while parsing property "disk" of static type > ArrayOfVirtualMachineRelocateSpecDiskLocator > while parsing serialized DataObject of type vim.vm.RelocateSpec > at line 1, column 187 > while parsing call information for method RelocateVM_Task > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method relocate > on object of type vim.VirtualMachine > at line 1, column 0 > When I run the test in the debugger and look at the > VirtualMachineRelocateSpec instance passed to > VirtualMachineMO.changeDatastore, I see the target datastore is populated, > but not the source datastore: > http://imgur.com/a/vtKcq datastore-66 is the target datastore > Based on an e-mail chain on dev@, it sounds like my scenario should work. > Thanks! -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CLOUDSTACK-3223) Exception observed while creating CPVM in VMware Setup with DVS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-3223: - Summary: Exception observed while creating CPVM in VMware Setup with DVS (was: Exception occured while creating the CPVM in the VmWare Setup using the latest SystemVM template.) > Exception observed while creating CPVM in VMware Setup with DVS > --- > > Key: CLOUDSTACK-3223 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3223 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 >Reporter: Kiran Koneti >Assignee: Sateesh Chodapuneedi > Fix For: 4.9.2.0 > > Attachments: IssuewithPublicportgroupupdate.png, > management-server.log.2013-06-26 > > > Exception occured while creating the CPVM in the VmWare Setup using *VMware > dvSwitches* using the latest SystemVM template, below are the steps followed. > 1)Tried to create a VMware Advanced Zone setup using the latest system VM > template. > 2)while creating the CPVM the below error message is observed: > 2013-06-26 16:30:57,826 WARN [vmware.resource.VmwareResource] > (DirectAgent-3:10.147.40.18) StartCommand failed due to Exception: > com.vmware.vim25.AlreadyExists > message: [] > com.vmware.vim25.AlreadyExistsFaultMsg: The specified key, name, or > identifier already exists. > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:532) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:130) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at $Proxy90.addPortGroup(Unknown Source) > at > com.cloud.hypervisor.vmware.mo.HostNetworkSystemMO.addPortGroup(HostNetworkSystemMO.java:38) > at > com.cloud.hypervisor.vmware.mo.HostMO.createPortGroup(HostMO.java:382) > at > com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:866) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:2853) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2617) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:474) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)" > 3)The same error message is also observed in the Vcenter also for both 4.1 > and 5.0 setups. > Note:This error message does not prevent the creation of CPVM or any other > functionality of CS,but this would create a panic while creating the setup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-3223) Exception occured while creating the CPVM in the VmWare Setup using the latest SystemVM template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15780787#comment-15780787 ] Sateesh Chodapuneedi commented on CLOUDSTACK-3223: -- Attachment https://issues.apache.org/jira/secure/attachment/12590594/IssuewithPublicportgroupupdate.png depicts the issue correctly. > Exception occured while creating the CPVM in the VmWare Setup using the > latest SystemVM template. > - > > Key: CLOUDSTACK-3223 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3223 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 >Reporter: Kiran Koneti >Assignee: Sateesh Chodapuneedi > Fix For: 4.9.2.0 > > Attachments: IssuewithPublicportgroupupdate.png, > management-server.log.2013-06-26 > > > Exception occured while creating the CPVM in the VmWare Setup using *VMware > dvSwitches* using the latest SystemVM template, below are the steps followed. > 1)Tried to create a VMware Advanced Zone setup using the latest system VM > template. > 2)while creating the CPVM the below error message is observed: > 2013-06-26 16:30:57,826 WARN [vmware.resource.VmwareResource] > (DirectAgent-3:10.147.40.18) StartCommand failed due to Exception: > com.vmware.vim25.AlreadyExists > message: [] > com.vmware.vim25.AlreadyExistsFaultMsg: The specified key, name, or > identifier already exists. > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:532) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:130) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at $Proxy90.addPortGroup(Unknown Source) > at > com.cloud.hypervisor.vmware.mo.HostNetworkSystemMO.addPortGroup(HostNetworkSystemMO.java:38) > at > com.cloud.hypervisor.vmware.mo.HostMO.createPortGroup(HostMO.java:382) > at > com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:866) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:2853) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2617) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:474) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)" > 3)The same error message is also observed in the Vcenter also for both 4.1 > and 5.0 setups. > Note:This error message does not prevent the creation of CPVM or any other > functionality of CS,but this would create a panic while creating the setup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3223) Exception occured while creating the CPVM in the VmWare Setup using the latest SystemVM template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-3223: - Description: Exception occured while creating the CPVM in the VmWare Setup using *VMware dvSwitches* using the latest SystemVM template, below are the steps followed. 1)Tried to create a VMware Advanced Zone setup using the latest system VM template. 2)while creating the CPVM the below error message is observed: 2013-06-26 16:30:57,826 WARN [vmware.resource.VmwareResource] (DirectAgent-3:10.147.40.18) StartCommand failed due to Exception: com.vmware.vim25.AlreadyExists message: [] com.vmware.vim25.AlreadyExistsFaultMsg: The specified key, name, or identifier already exists. at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:130) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) at $Proxy90.addPortGroup(Unknown Source) at com.cloud.hypervisor.vmware.mo.HostNetworkSystemMO.addPortGroup(HostNetworkSystemMO.java:38) at com.cloud.hypervisor.vmware.mo.HostMO.createPortGroup(HostMO.java:382) at com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:866) at com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:2853) at com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2617) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:474) at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)" 3)The same error message is also observed in the Vcenter also for both 4.1 and 5.0 setups. Note:This error message does not prevent the creation of CPVM or any other functionality of CS,but this would create a panic while creating the setup. was: Exception occured while creating the CPVM in the VmWare Setup using the latest SystemVM template, below are the steps followed. 1)Tried to create a VMware Advanced Zone setup using the latest system VM templates for VH7. 2)while creating the CPVM the below error message is observed: "2013-06-26 16:30:57,550 INFO [vmware.resource.VmwareResource] (DirectAgent-3:10.147.40.18) Prepare network on vmwaresvs P[vSwitch0:untagged] with name prefix: cloud.public 2013-06-26 16:30:57,826 WARN [vmware.resource.VmwareResource] (DirectAgent-3:10.147.40.18) StartCommand failed due to Exception: com.vmware.vim25.AlreadyExists message: [] com.vmware.vim25.AlreadyExistsFaultMsg: The specified key, name, or identifier already exists. at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:130) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) at $Proxy90.addPortGroup(Unknown Source) at com.cloud.hypervisor.vmware.mo.HostNetworkSystemMO.addPortGroup(HostNetworkSystemMO.java:38) at com.cloud.hypervisor.vmware.mo.HostMO.createPortGroup(HostMO.java:382) at
[jira] [Updated] (CLOUDSTACK-3223) Exception occured while creating the CPVM in the VmWare Setup using the latest SystemVM template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-3223: - Fix Version/s: (was: 4.2.1) 4.9.2.0 > Exception occured while creating the CPVM in the VmWare Setup using the > latest SystemVM template. > - > > Key: CLOUDSTACK-3223 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3223 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 >Reporter: Kiran Koneti >Assignee: Sateesh Chodapuneedi > Fix For: 4.9.2.0 > > Attachments: IssuewithPublicportgroupupdate.png, > management-server.log.2013-06-26 > > > Exception occured while creating the CPVM in the VmWare Setup using the > latest SystemVM template, below are the steps followed. > 1)Tried to create a VMware Advanced Zone setup using the latest system VM > templates for VH7. > 2)while creating the CPVM the below error message is observed: > "2013-06-26 16:30:57,550 INFO [vmware.resource.VmwareResource] > (DirectAgent-3:10.147.40.18) Prepare network on vmwaresvs > P[vSwitch0:untagged] with name prefix: cloud.public > 2013-06-26 16:30:57,826 WARN [vmware.resource.VmwareResource] > (DirectAgent-3:10.147.40.18) StartCommand failed due to Exception: > com.vmware.vim25.AlreadyExists > message: [] > com.vmware.vim25.AlreadyExistsFaultMsg: The specified key, name, or > identifier already exists. > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:532) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:130) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at $Proxy90.addPortGroup(Unknown Source) > at > com.cloud.hypervisor.vmware.mo.HostNetworkSystemMO.addPortGroup(HostNetworkSystemMO.java:38) > at > com.cloud.hypervisor.vmware.mo.HostMO.createPortGroup(HostMO.java:382) > at > com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:866) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:2853) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2617) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:474) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)" > 3)The same error message is also observed in the Vcenter also for both 4.1 > and 5.0 setups. > Note:This error message does not prevent the creation of CPVM or any other > functionality of CS,but this would create a panic while creating the setup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-3223) Exception occured while creating the CPVM in the VmWare Setup using the latest SystemVM template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi reopened CLOUDSTACK-3223: -- Able to reproduce when both SSVM and CPVM are created simultaneously. > Exception occured while creating the CPVM in the VmWare Setup using the > latest SystemVM template. > - > > Key: CLOUDSTACK-3223 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3223 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 >Reporter: Kiran Koneti >Assignee: Sateesh Chodapuneedi > Fix For: 4.9.2.0 > > Attachments: IssuewithPublicportgroupupdate.png, > management-server.log.2013-06-26 > > > Exception occured while creating the CPVM in the VmWare Setup using the > latest SystemVM template, below are the steps followed. > 1)Tried to create a VMware Advanced Zone setup using the latest system VM > templates for VH7. > 2)while creating the CPVM the below error message is observed: > "2013-06-26 16:30:57,550 INFO [vmware.resource.VmwareResource] > (DirectAgent-3:10.147.40.18) Prepare network on vmwaresvs > P[vSwitch0:untagged] with name prefix: cloud.public > 2013-06-26 16:30:57,826 WARN [vmware.resource.VmwareResource] > (DirectAgent-3:10.147.40.18) StartCommand failed due to Exception: > com.vmware.vim25.AlreadyExists > message: [] > com.vmware.vim25.AlreadyExistsFaultMsg: The specified key, name, or > identifier already exists. > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:532) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:130) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at $Proxy90.addPortGroup(Unknown Source) > at > com.cloud.hypervisor.vmware.mo.HostNetworkSystemMO.addPortGroup(HostNetworkSystemMO.java:38) > at > com.cloud.hypervisor.vmware.mo.HostMO.createPortGroup(HostMO.java:382) > at > com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:866) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:2853) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2617) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:474) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)" > 3)The same error message is also observed in the Vcenter also for both 4.1 > and 5.0 setups. > Note:This error message does not prevent the creation of CPVM or any other > functionality of CS,but this would create a panic while creating the setup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9704) Remove dependency on VmwareContext object to fetch system VM key file
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9704:
-
Description:
While remote executing commands/scripts in VR, ACS uses system vm keyfile. ACS
is fetching this key file using following code
{code:java|borderStyle=solid}
VmwareManager mgr =
getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);
File systemVmKeyFile = mgr.getSystemVMKeyFile();
{code}
This is inefficient because dependency on getServiceContext() in above code
means a vCenter connection handle which is not required just to fetch a file in
name space in management server.
was:
While remote executing commands/scripts in VR, ACS uses system vm keyfile. ACS
is fetching this key file using following code
{code:java|title=Fetching keyfile|borderStyle=solid}
VmwareManager mgr =
getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);
File systemVmKeyFile = mgr.getSystemVMKeyFile();
{code}
This is inefficient because dependency on getServiceContext() in above code
means a vCenter connection handle which is not required just to fetch a file in
name space in management server.
> Remove dependency on VmwareContext object to fetch system VM key file
> -
>
> Key: CLOUDSTACK-9704
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9704
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
>
> While remote executing commands/scripts in VR, ACS uses system vm keyfile.
> ACS is fetching this key file using following code
> {code:java|borderStyle=solid}
> VmwareManager mgr =
> getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);
> File systemVmKeyFile = mgr.getSystemVMKeyFile();
> {code}
> This is inefficient because dependency on getServiceContext() in above code
> means a vCenter connection handle which is not required just to fetch a file
> in name space in management server.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9704) Remove dependency on VmwareContext object to fetch system VM key file
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9704:
-
Description:
While remote executing commands/scripts in VR, ACS uses system vm keyfile. ACS
is fetching this key file using following code
{code:java}
VmwareManager mgr =
getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);
File systemVmKeyFile = mgr.getSystemVMKeyFile();
{code}
This is inefficient because dependency on getServiceContext() in above code
means a vCenter connection handle which is not required just to fetch a file in
name space in management server.
was:
While remote executing commands/scripts in VR, ACS uses system vm keyfile. ACS
is fetching this key file using following code
{code:java|borderStyle=solid}
VmwareManager mgr =
getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);
File systemVmKeyFile = mgr.getSystemVMKeyFile();
{code}
This is inefficient because dependency on getServiceContext() in above code
means a vCenter connection handle which is not required just to fetch a file in
name space in management server.
> Remove dependency on VmwareContext object to fetch system VM key file
> -
>
> Key: CLOUDSTACK-9704
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9704
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
>
> While remote executing commands/scripts in VR, ACS uses system vm keyfile.
> ACS is fetching this key file using following code
> {code:java}
> VmwareManager mgr =
> getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);
> File systemVmKeyFile = mgr.getSystemVMKeyFile();
> {code}
> This is inefficient because dependency on getServiceContext() in above code
> means a vCenter connection handle which is not required just to fetch a file
> in name space in management server.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9704) Remove dependency on VmwareContext object to fetch system VM key file
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9704:
-
Description:
While remote executing commands/scripts in VR, ACS uses system vm keyfile. ACS
is fetching this key file using following code
{code:java|title=Fetching keyfile|borderStyle=solid}
VmwareManager mgr =
getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);
File systemVmKeyFile = mgr.getSystemVMKeyFile();
{code}
This is inefficient because dependency on getServiceContext() in above code
means a vCenter connection handle which is not required just to fetch a file in
name space in management server.
was:
While remote executing commands/scripts in VR, ACS uses system vm keyfile. ACS
is fetching this key file using following code
{code:title=Fetching keyfile|borderStyle=solid}
VmwareManager mgr =
getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);
File systemVmKeyFile = mgr.getSystemVMKeyFile();
{code}
This is inefficient because dependency on getServiceContext() in above code
means a vCenter connection handle which is not required just to fetch a file in
name space in management server.
> Remove dependency on VmwareContext object to fetch system VM key file
> -
>
> Key: CLOUDSTACK-9704
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9704
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
>
> While remote executing commands/scripts in VR, ACS uses system vm keyfile.
> ACS is fetching this key file using following code
> {code:java|title=Fetching keyfile|borderStyle=solid}
> VmwareManager mgr =
> getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);
> File systemVmKeyFile = mgr.getSystemVMKeyFile();
> {code}
> This is inefficient because dependency on getServiceContext() in above code
> means a vCenter connection handle which is not required just to fetch a file
> in name space in management server.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-9676) Start instance fails after reverting to a VM snapshot, when there are child VM snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi resolved CLOUDSTACK-9676.
--
Resolution: Fixed
> Start instance fails after reverting to a VM snapshot, when there are child
> VM snapshots
>
>
> Key: CLOUDSTACK-9676
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9676
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0.1
> Environment: vSphere 5.5
> ACS master commit 17653a86fad67447a4f13e455e336694ad5c1735
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.10.0.0
>
>
> Start instance fails after reverting to a VM snapshot, when there is 1 or
> more child VM snapshots in the snapshot tree of the VM.
> Per the code that detects the presence of a snapshot, we are checking for
> only current snapshot instead of checking presence of any snapshot in the
> snapshot tree. The failure to detect all snapshots means ACP reconfigures the
> VM in wrong way assuming there are no snapshots for the VM. This results in
> start failure.
> {code:borderStyle=solid}
> public boolean hasSnapshot() throws Exception {
> VirtualMachineSnapshotInfo info = getSnapshotInfo();
> if (info != null) {
> return info.getCurrentSnapshot() != null;
> }
> return false;
> }
> {code}
> Steps to reproduce
> ===
> # Prepare setup with esxi5.5
> # Deploy a vm and create three snapshot i1,i2,i3.
> # Delete i2. and stop vm
> # Revert vm to i1
> # Delete i1
> # Start vm
> Start vm is failing with error,
> {noformat}
> StartCommand failed due to Exception: java.lang.RuntimeException Message:
> Invalid configuration for device '0'.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9704) Remove dependency on VmwareContext object to fetch system VM key file
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi reassigned CLOUDSTACK-9704:
Assignee: Sateesh Chodapuneedi
> Remove dependency on VmwareContext object to fetch system VM key file
> -
>
> Key: CLOUDSTACK-9704
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9704
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
>
> While remote executing commands/scripts in VR, ACS uses system vm keyfile.
> ACS is fetching this key file using following code
> {code:title=Fetching keyfile|borderStyle=solid}
> VmwareManager mgr =
> getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);
> File systemVmKeyFile = mgr.getSystemVMKeyFile();
> {code}
> This is inefficient because dependency on getServiceContext() in above code
> means a vCenter connection handle which is not required just to fetch a file
> in name space in management server.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-9673) Exception occured while creating the CPVM in the VmWare Setup over standard vSwitches
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi resolved CLOUDSTACK-9673.
--
Resolution: Fixed
> Exception occured while creating the CPVM in the VmWare Setup over standard
> vSwitches
> --
>
> Key: CLOUDSTACK-9673
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9673
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.9.0.1
> Environment: ACS master commit
> 17653a86fad67447a4f13e455e336694ad5c1735
> ESXi 5.5
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.10.0.0
>
>
> Exception occured while creating the CPVM in the VmWare Setup using standard
> vswitches, below are the steps followed.
> 1) Tried to create a VMware Advanced Zone setup
> 2) while creating the console proxy vm the below error message is observed
> {noformat}
> StartCommand failed due to Exception: com.vmware.vim25.AlreadyExists
> message: []
> com.vmware.vim25.AlreadyExistsFaultMsg: The specified key, name, or
> identifier already exists.
> {noformat}
> 3)The same error message is also observed in the Vcenter also for both 5.5
> and 5.0 setups.
> Note:This error message does not prevent the creation of CPVM or any other
> functionality of ACS, but this would create a panic while creating the setup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9704) Remove dependency on VmwareContext object to fetch system VM key file
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9704:
-
Description:
While remote executing commands/scripts in VR, ACS uses system vm keyfile. ACS
is fetching this key file using following code
{code:title=Fetching keyfile|borderStyle=solid}
VmwareManager mgr =
getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);
File systemVmKeyFile = mgr.getSystemVMKeyFile();
{code}
This is inefficient because dependency on getServiceContext() in above code
means a vCenter connection handle which is not required just to fetch a file in
name space in management server.
was:
While remote executing commands/scripts in VR, ACS uses system vm keyfile. ACS
is fetching this key file using following code
```
VmwareManager mgr =
getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);
File systemVmKeyFile = mgr.getSystemVMKeyFile();
```
This is inefficient because dependency on getServiceContext() in above code
means a vCenter connection handle which is not required just to fetch a file in
name space in management server.
> Remove dependency on VmwareContext object to fetch system VM key file
> -
>
> Key: CLOUDSTACK-9704
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9704
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Sateesh Chodapuneedi
>
> While remote executing commands/scripts in VR, ACS uses system vm keyfile.
> ACS is fetching this key file using following code
> {code:title=Fetching keyfile|borderStyle=solid}
> VmwareManager mgr =
> getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME);
> File systemVmKeyFile = mgr.getSystemVMKeyFile();
> {code}
> This is inefficient because dependency on getServiceContext() in above code
> means a vCenter connection handle which is not required just to fetch a file
> in name space in management server.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9704) Remove dependency on VmwareContext object to fetch system VM key file
Sateesh Chodapuneedi created CLOUDSTACK-9704: Summary: Remove dependency on VmwareContext object to fetch system VM key file Key: CLOUDSTACK-9704 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9704 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sateesh Chodapuneedi While remote executing commands/scripts in VR, ACS uses system vm keyfile. ACS is fetching this key file using following code ``` VmwareManager mgr = getServiceContext().getStockObject(VmwareManager.CONTEXT_STOCK_NAME); File systemVmKeyFile = mgr.getSystemVMKeyFile(); ``` This is inefficient because dependency on getServiceContext() in above code means a vCenter connection handle which is not required just to fetch a file in name space in management server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8672) NCC Integration with CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-8672: - Priority: Critical (was: Major) > NCC Integration with CloudStack > --- > > Key: CLOUDSTACK-8672 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala >Priority: Critical > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9698) Make the wait timeout for NIC adapter hotplug as configurable
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-9698: - Description: Currently ACS waits for 15 seconds (*hard coded*) for hot-plugged NIC in VR to get detected by guest OS. The time taken to detect hot plugged NIC in guest OS depends on type of NIC adapter like (E1000, VMXNET3, E1000e etc.) and guest OS itself. In uncommon scenarios the NIC detection may take longer time than 15 seconds, in such cases NIC hotplug would be treated as failure which results in VPC tier configuration failure. Making the wait timeout for NIC adapter hotplug as configurable will be helpful for admins in such scenarios. Also in future if VMware introduces new NIC adapter types which may take time to get detected by guest OS, it is good to have flexibility of configuring the wait timeout. was:Making the wait time for NIC adapter hotplug as configurable will be helpful for admins so that ACS does not wait for for NIC adapter to be detected by guest OS, which ensures more flexibility to customers. In future if VMware introduces new NIC adapter types which may take time (like VMXNET3 in this case, which takes few more seconds than other NIC adapter types like E1000) to get detected by guest OS, this fix will ensure flexibility of configuring the wait time. > Make the wait timeout for NIC adapter hotplug as configurable > - > > Key: CLOUDSTACK-9698 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9698 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.9.0.1 > Environment: ACS 4.9 branch commit > a0e36b73aebe43bfe6bec3ef8f53e8cb99ecbc32 > vSphere 5.5 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.9.1.0 > > > Currently ACS waits for 15 seconds (*hard coded*) for hot-plugged NIC in VR > to get detected by guest OS. The time taken to detect hot plugged NIC in > guest OS depends on type of NIC adapter like (E1000, VMXNET3, E1000e etc.) > and guest OS itself. In uncommon scenarios the NIC detection may take longer > time than 15 seconds, in such cases NIC hotplug would be treated as failure > which results in VPC tier configuration failure. Making the wait timeout for > NIC adapter hotplug as configurable will be helpful for admins in such > scenarios. > Also in future if VMware introduces new NIC adapter types which may take time > to get detected by guest OS, it is good to have flexibility of configuring > the wait timeout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9698) Make the wait time for NIC adapter hotplug as configurable
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-9698: - Description: Making the wait time for NIC adapter hotplug as configurable will be helpful for admins so that ACS does not wait for for NIC adapter to be detected by guest OS, which ensures more flexibility to customers. In future if VMware introduces new NIC adapter types which may take time (like VMXNET3 in this case, which takes few more seconds than other NIC adapter types like E1000) to get detected by guest OS, this fix will ensure flexibility of configuring the wait time. (was: It will be helpful roviding configurable wait time for NIC adapter to be detected by guest OS, which ensures more flexibility to customers. In future if VMware introduces new NIC adapter types which may take time (like VMXNET3 in this case, which takes few more seconds than other NIC adapter types like E1000) to get detected by guest OS, this fix will ensure flexibility of configuring the wait time.) > Make the wait time for NIC adapter hotplug as configurable > -- > > Key: CLOUDSTACK-9698 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9698 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.9.0.1 > Environment: ACS 4.9 branch commit > a0e36b73aebe43bfe6bec3ef8f53e8cb99ecbc32 > vSphere 5.5 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.9.1.0 > > > Making the wait time for NIC adapter hotplug as configurable will be helpful > for admins so that ACS does not wait for for NIC adapter to be detected by > guest OS, which ensures more flexibility to customers. In future if VMware > introduces new NIC adapter types which may take time (like VMXNET3 in this > case, which takes few more seconds than other NIC adapter types like E1000) > to get detected by guest OS, this fix will ensure flexibility of configuring > the wait time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9698) Make the wait timeout for NIC adapter hotplug as configurable
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-9698: - Summary: Make the wait timeout for NIC adapter hotplug as configurable (was: Make the wait time for NIC adapter hotplug as configurable) > Make the wait timeout for NIC adapter hotplug as configurable > - > > Key: CLOUDSTACK-9698 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9698 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.9.0.1 > Environment: ACS 4.9 branch commit > a0e36b73aebe43bfe6bec3ef8f53e8cb99ecbc32 > vSphere 5.5 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.9.1.0 > > > Making the wait time for NIC adapter hotplug as configurable will be helpful > for admins so that ACS does not wait for for NIC adapter to be detected by > guest OS, which ensures more flexibility to customers. In future if VMware > introduces new NIC adapter types which may take time (like VMXNET3 in this > case, which takes few more seconds than other NIC adapter types like E1000) > to get detected by guest OS, this fix will ensure flexibility of configuring > the wait time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9698) Make the wait time for NIC adapter hotplug as configurable
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-9698: - Summary: Make the wait time for NIC adapter hotplug as configurable (was: Attaching and Detaching volume over the time degrades performance of storage operations) > Make the wait time for NIC adapter hotplug as configurable > -- > > Key: CLOUDSTACK-9698 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9698 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.9.0.1 > Environment: ACS 4.9 branch commit > a0e36b73aebe43bfe6bec3ef8f53e8cb99ecbc32 > vSphere 5.5 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.9.1.0 > > > Issue > > Observed significant performance degradation for volume attach/detach > operations and other storage operations. > In the storage operations that were slow, keen observation shows that maximum > time was spent searching for volume on datastore, in that case the attempted > storage operation was volume deletion. The time taken for search was shot up > due to large number of empty folder accumulated over time due to a bug in > detach volume logic. We should ensure avoid leaking empty folder while > detaching volume. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9698) Make the wait time for NIC adapter hotplug as configurable
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-9698: - Description: It will be helpful roviding configurable wait time for NIC adapter to be detected by guest OS, which ensures more flexibility to customers. In future if VMware introduces new NIC adapter types which may take time (like VMXNET3 in this case, which takes few more seconds than other NIC adapter types like E1000) to get detected by guest OS, this fix will ensure flexibility of configuring the wait time. (was: Issue Observed significant performance degradation for volume attach/detach operations and other storage operations. In the storage operations that were slow, keen observation shows that maximum time was spent searching for volume on datastore, in that case the attempted storage operation was volume deletion. The time taken for search was shot up due to large number of empty folder accumulated over time due to a bug in detach volume logic. We should ensure avoid leaking empty folder while detaching volume. ) > Make the wait time for NIC adapter hotplug as configurable > -- > > Key: CLOUDSTACK-9698 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9698 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.9.0.1 > Environment: ACS 4.9 branch commit > a0e36b73aebe43bfe6bec3ef8f53e8cb99ecbc32 > vSphere 5.5 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.9.1.0 > > > It will be helpful roviding configurable wait time for NIC adapter to be > detected by guest OS, which ensures more flexibility to customers. In future > if VMware introduces new NIC adapter types which may take time (like VMXNET3 > in this case, which takes few more seconds than other NIC adapter types like > E1000) to get detected by guest OS, this fix will ensure flexibility of > configuring the wait time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9684) Invalid zone id error while listing vmware zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-9684: - Summary: Invalid zone id error while listing vmware zone (was: Invalid zone id error while listing vmware zones) > Invalid zone id error while listing vmware zone > --- > > Key: CLOUDSTACK-9684 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9684 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.9.0.1 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.10.0.0 > > > When we select a VMware zone in the UI, listvmwaredcs API gets called. > But if the zone is a legacy zone then upon clicking the zone in ACS UI, it > throws error 'Invalid zone id' as pop-up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9684) Invalid zone id error while listing vmware zones
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-9684: - Description: When we select a VMware zone in the UI, listvmwaredcs API gets called. But if the zone is a legacy zone then upon clicking the zone in ACS UI, it throws error 'Invalid zone id' as pop-up. was:When we select a VMware zone in the UI, listvmwaredcs API gets called and for a legacy zone it throws a 'Invalid zone id error while listing VMware zones'. > Invalid zone id error while listing vmware zones > > > Key: CLOUDSTACK-9684 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9684 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.9.0.1 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.10.0.0 > > > When we select a VMware zone in the UI, listvmwaredcs API gets called. > But if the zone is a legacy zone then upon clicking the zone in ACS UI, it > throws error 'Invalid zone id' as pop-up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9684) Invalid zone id error while listing vmware zones
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi reassigned CLOUDSTACK-9684: Assignee: Sateesh Chodapuneedi > Invalid zone id error while listing vmware zones > > > Key: CLOUDSTACK-9684 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9684 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.9.0.1 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.10.0.0 > > > When we select a VMware zone in the UI, listvmwaredcs API gets called and for > a legacy zone it throws a 'Invalid zone id error while listing VMware zones'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9684) Invalid zone id error while listing vmware zones
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-9684: - Fix Version/s: 4.10.0.0 > Invalid zone id error while listing vmware zones > > > Key: CLOUDSTACK-9684 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9684 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.9.0.1 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.10.0.0 > > > When we select a VMware zone in the UI, listvmwaredcs API gets called and for > a legacy zone it throws a 'Invalid zone id error while listing VMware zones'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9684) Invalid zone id error while listing vmware zones
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-9684: - Affects Version/s: 4.9.0.1 > Invalid zone id error while listing vmware zones > > > Key: CLOUDSTACK-9684 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9684 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.9.0.1 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.10.0.0 > > > When we select a VMware zone in the UI, listvmwaredcs API gets called and for > a legacy zone it throws a 'Invalid zone id error while listing VMware zones'. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9676) Start instance fails after reverting to a VM snapshot, when there are child VM snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9676:
-
Description:
Start instance fails after reverting to a VM snapshot, when there is 1 or more
child VM snapshots in the snapshot tree of the VM.
Per the code that detects the presence of a snapshot, we are checking for only
current snapshot instead of checking presence of any snapshot in the snapshot
tree. The failure to detect all snapshots means ACP reconfigures the VM in
wrong way assuming there are no snapshots for the VM. This results in start
failure.
{code:borderStyle=solid}
public boolean hasSnapshot() throws Exception {
VirtualMachineSnapshotInfo info = getSnapshotInfo();
if (info != null) {
return info.getCurrentSnapshot() != null;
}
return false;
}
{code}
Steps to reproduce
===
# Prepare setup with esxi5.5
# Deploy a vm and create three snapshot i1,i2,i3.
# Delete i2. and stop vm
# Revert vm to i1
# Delete i1
# Start vm
Start vm is failing with error,
{noformat}
StartCommand failed due to Exception: java.lang.RuntimeException Message:
Invalid configuration for device '0'.
{noformat}
was:
Start instance fails after reverting to a VM snapshot, when there is 1 or more
child VM snapshots in the snapshot tree of the VM.
Per the code that detects the presence of a snapshot, we are checking for only
current snapshot instead of checking presence of any snapshot in the snapshot
tree.
{code:borderStyle=solid}
public boolean hasSnapshot() throws Exception {
VirtualMachineSnapshotInfo info = getSnapshotInfo();
if (info != null) {
return info.getCurrentSnapshot() != null;
}
return false;
}
{code}
Steps to reproduce
===
# Prepare setup with esxi5.5
# Deploy a vm and create three snapshot i1,i2,i3.
# Delete i2. and stop vm
# Revert vm to i1
# Delete i1
# Start vm
Start vm is failing with error,
{noformat}
StartCommand failed due to Exception: java.lang.RuntimeException Message:
Invalid configuration for device '0'.
{noformat}
> Start instance fails after reverting to a VM snapshot, when there are child
> VM snapshots
>
>
> Key: CLOUDSTACK-9676
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9676
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0.1
> Environment: vSphere 5.5
> ACS master commit 17653a86fad67447a4f13e455e336694ad5c1735
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.10.0.0
>
>
> Start instance fails after reverting to a VM snapshot, when there is 1 or
> more child VM snapshots in the snapshot tree of the VM.
> Per the code that detects the presence of a snapshot, we are checking for
> only current snapshot instead of checking presence of any snapshot in the
> snapshot tree. The failure to detect all snapshots means ACP reconfigures the
> VM in wrong way assuming there are no snapshots for the VM. This results in
> start failure.
> {code:borderStyle=solid}
> public boolean hasSnapshot() throws Exception {
> VirtualMachineSnapshotInfo info = getSnapshotInfo();
> if (info != null) {
> return info.getCurrentSnapshot() != null;
> }
> return false;
> }
> {code}
> Steps to reproduce
> ===
> # Prepare setup with esxi5.5
> # Deploy a vm and create three snapshot i1,i2,i3.
> # Delete i2. and stop vm
> # Revert vm to i1
> # Delete i1
> # Start vm
> Start vm is failing with error,
> {noformat}
> StartCommand failed due to Exception: java.lang.RuntimeException Message:
> Invalid configuration for device '0'.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9676) Start instance fails after reverting to a VM snapshot, when there are child VM snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9676:
-
Description:
Start instance fails after reverting to a VM snapshot, when there is 1 or more
child VM snapshots in the snapshot tree of the VM.
Per the code that detects the presence of a snapshot, we are checking for only
current snapshot instead of checking presence of any snapshot in the snapshot
tree.
{code:borderStyle=solid}
public boolean hasSnapshot() throws Exception {
VirtualMachineSnapshotInfo info = getSnapshotInfo();
if (info != null) {
return info.getCurrentSnapshot() != null;
}
}
{code}
Steps to reproduce
===
# Prepare setup with esxi5.5
# Deploy a vm and create three snapshot i1,i2,i3.
# Delete i2. and stop vm
# Revert vm to i1
# Delete i1
# Start vm
Start vm is failing with error,
{noformat}
StartCommand failed due to Exception: java.lang.RuntimeException Message:
Invalid configuration for device '0'.
{noformat}
was:
Start instance fails after reverting to a VM snapshot, when there is 1 or more
child VM snapshots in the snapshot tree of the VM.
{code:borderStyle=solid}
public boolean hasSnapshot() throws Exception {
VirtualMachineSnapshotInfo info = getSnapshotInfo();
if (info != null) {
return info.getCurrentSnapshot() != null;
{code}
Steps to reproduce
===
# Prepare setup with esxi5.5
# Deploy a vm and create three snapshot i1,i2,i3.
# Delete i2. and stop vm
# Revert vm to i1
# Delete i1
# Start vm
Start vm is failing with error,
{noformat}
StartCommand failed due to Exception: java.lang.RuntimeException Message:
Invalid configuration for device '0'.
{noformat}
> Start instance fails after reverting to a VM snapshot, when there are child
> VM snapshots
>
>
> Key: CLOUDSTACK-9676
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9676
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0.1
> Environment: vSphere 5.5
> ACS master commit 17653a86fad67447a4f13e455e336694ad5c1735
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.10.0.0
>
>
> Start instance fails after reverting to a VM snapshot, when there is 1 or
> more child VM snapshots in the snapshot tree of the VM.
> Per the code that detects the presence of a snapshot, we are checking for
> only current snapshot instead of checking presence of any snapshot in the
> snapshot tree.
> {code:borderStyle=solid}
> public boolean hasSnapshot() throws Exception {
> VirtualMachineSnapshotInfo info = getSnapshotInfo();
> if (info != null) {
> return info.getCurrentSnapshot() != null;
> }
> }
> {code}
> Steps to reproduce
> ===
> # Prepare setup with esxi5.5
> # Deploy a vm and create three snapshot i1,i2,i3.
> # Delete i2. and stop vm
> # Revert vm to i1
> # Delete i1
> # Start vm
> Start vm is failing with error,
> {noformat}
> StartCommand failed due to Exception: java.lang.RuntimeException Message:
> Invalid configuration for device '0'.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9676) Start instance fails after reverting to a VM snapshot, when there are child VM snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9676:
-
Description:
Start instance fails after reverting to a VM snapshot, when there is 1 or more
child VM snapshots in the snapshot tree of the VM.
{code:borderStyle=solid}
public boolean hasSnapshot() throws Exception {
VirtualMachineSnapshotInfo info = getSnapshotInfo();
if (info != null) {
return info.getCurrentSnapshot() != null;
{code}
Steps to reproduce
===
# Prepare setup with esxi5.5
# Deploy a vm and create three snapshot i1,i2,i3.
# Delete i2. and stop vm
# Revert vm to i1
# Delete i1
# Start vm
Start vm is failing with error,
{noformat}
StartCommand failed due to Exception: java.lang.RuntimeException Message:
Invalid configuration for device '0'.
{noformat}
was:
Start instance fails after reverting to a VM snapshot, when there is 1 or more
child VM snapshots in the snapshot tree of the VM.
```java
public boolean hasSnapshot() throws Exception {
VirtualMachineSnapshotInfo info = getSnapshotInfo();
if (info != null) {
return info.getCurrentSnapshot() != null;
```
Steps to reproduce
===
# Prepare setup with esxi5.5
# Deploy a vm and create three snapshot i1,i2,i3.
# Delete i2. and stop vm
# Revert vm to i1
# Delete i1
# Start vm
Start vm is failing with error,
{noformat}
StartCommand failed due to Exception: java.lang.RuntimeException Message:
Invalid configuration for device '0'.
{noformat}
> Start instance fails after reverting to a VM snapshot, when there are child
> VM snapshots
>
>
> Key: CLOUDSTACK-9676
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9676
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0.1
> Environment: vSphere 5.5
> ACS master commit 17653a86fad67447a4f13e455e336694ad5c1735
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.10.0.0
>
>
> Start instance fails after reverting to a VM snapshot, when there is 1 or
> more child VM snapshots in the snapshot tree of the VM.
> {code:borderStyle=solid}
> public boolean hasSnapshot() throws Exception {
> VirtualMachineSnapshotInfo info = getSnapshotInfo();
> if (info != null) {
> return info.getCurrentSnapshot() != null;
> {code}
> Steps to reproduce
> ===
> # Prepare setup with esxi5.5
> # Deploy a vm and create three snapshot i1,i2,i3.
> # Delete i2. and stop vm
> # Revert vm to i1
> # Delete i1
> # Start vm
> Start vm is failing with error,
> {noformat}
> StartCommand failed due to Exception: java.lang.RuntimeException Message:
> Invalid configuration for device '0'.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9676) Start instance fails after reverting to a VM snapshot, when there are child VM snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9676:
-
Description:
Start instance fails after reverting to a VM snapshot, when there is 1 or more
child VM snapshots in the snapshot tree of the VM.
```java
public boolean hasSnapshot() throws Exception {
VirtualMachineSnapshotInfo info = getSnapshotInfo();
if (info != null) {
return info.getCurrentSnapshot() != null;
```
Steps to reproduce
===
# Prepare setup with esxi5.5
# Deploy a vm and create three snapshot i1,i2,i3.
# Delete i2. and stop vm
# Revert vm to i1
# Delete i1
# Start vm
Start vm is failing with error,
{noformat}
StartCommand failed due to Exception: java.lang.RuntimeException Message:
Invalid configuration for device '0'.
{noformat}
was:
Steps to reproduce
===
# Prepare setup with esxi5.5
# Deploy a vm and create three snapshot i1,i2,i3.
# Delete i2. and stop vm
# Revert vm to i1
# Delete i1
# Start vm
Start vm is failing with error,
{noformat}
StartCommand failed due to Exception: java.lang.RuntimeException Message:
Invalid configuration for device '0'.
{noformat}
> Start instance fails after reverting to a VM snapshot, when there are child
> VM snapshots
>
>
> Key: CLOUDSTACK-9676
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9676
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0.1
> Environment: vSphere 5.5
> ACS master commit 17653a86fad67447a4f13e455e336694ad5c1735
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.10.0.0
>
>
> Start instance fails after reverting to a VM snapshot, when there is 1 or
> more child VM snapshots in the snapshot tree of the VM.
> ```java
> public boolean hasSnapshot() throws Exception {
> VirtualMachineSnapshotInfo info = getSnapshotInfo();
> if (info != null) {
> return info.getCurrentSnapshot() != null;
> ```
> Steps to reproduce
> ===
> # Prepare setup with esxi5.5
> # Deploy a vm and create three snapshot i1,i2,i3.
> # Delete i2. and stop vm
> # Revert vm to i1
> # Delete i1
> # Start vm
> Start vm is failing with error,
> {noformat}
> StartCommand failed due to Exception: java.lang.RuntimeException Message:
> Invalid configuration for device '0'.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9676) Start instance fails after reverting to a VM snapshot, when there are child VM snapshots
Sateesh Chodapuneedi created CLOUDSTACK-9676:
Summary: Start instance fails after reverting to a VM snapshot,
when there are child VM snapshots
Key: CLOUDSTACK-9676
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9676
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: VMware
Affects Versions: 4.9.0.1
Environment: vSphere 5.5
ACS master commit 17653a86fad67447a4f13e455e336694ad5c1735
Reporter: Sateesh Chodapuneedi
Assignee: Sateesh Chodapuneedi
Priority: Critical
Fix For: 4.10.0.0
Steps to reproduce
===
# Prepare setup with esxi5.5
# Deploy a vm and create three snapshot i1,i2,i3.
# Delete i2. and stop vm
# Revert vm to i1
# Delete i1
# Start vm
Start vm is failing with error,
{noformat}
StartCommand failed due to Exception: java.lang.RuntimeException Message:
Invalid configuration for device '0'.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9673) Exception occured while creating the CPVM in the VmWare Setup over standard vSwitches
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9673:
-
Priority: Critical (was: Major)
> Exception occured while creating the CPVM in the VmWare Setup over standard
> vSwitches
> --
>
> Key: CLOUDSTACK-9673
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9673
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.9.0.1
> Environment: ACS master commit
> 17653a86fad67447a4f13e455e336694ad5c1735
> ESXi 5.5
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.10.0.0
>
>
> Exception occured while creating the CPVM in the VmWare Setup using standard
> vswitches, below are the steps followed.
> 1) Tried to create a VMware Advanced Zone setup
> 2) while creating the console proxy vm the below error message is observed
> {noformat}
> StartCommand failed due to Exception: com.vmware.vim25.AlreadyExists
> message: []
> com.vmware.vim25.AlreadyExistsFaultMsg: The specified key, name, or
> identifier already exists.
> {noformat}
> 3)The same error message is also observed in the Vcenter also for both 5.5
> and 5.0 setups.
> Note:This error message does not prevent the creation of CPVM or any other
> functionality of ACS, but this would create a panic while creating the setup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9673) Exception occured while creating the CPVM in the VmWare Setup over standard vSwitches
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9673:
-
Fix Version/s: 4.10.0.0
> Exception occured while creating the CPVM in the VmWare Setup over standard
> vSwitches
> --
>
> Key: CLOUDSTACK-9673
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9673
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.9.0.1
> Environment: ACS master commit
> 17653a86fad67447a4f13e455e336694ad5c1735
> ESXi 5.5
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.10.0.0
>
>
> Exception occured while creating the CPVM in the VmWare Setup using standard
> vswitches, below are the steps followed.
> 1) Tried to create a VMware Advanced Zone setup
> 2) while creating the console proxy vm the below error message is observed
> {noformat}
> StartCommand failed due to Exception: com.vmware.vim25.AlreadyExists
> message: []
> com.vmware.vim25.AlreadyExistsFaultMsg: The specified key, name, or
> identifier already exists.
> {noformat}
> 3)The same error message is also observed in the Vcenter also for both 5.5
> and 5.0 setups.
> Note:This error message does not prevent the creation of CPVM or any other
> functionality of ACS, but this would create a panic while creating the setup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9673) Exception occured while creating the CPVM in the VmWare Setup over standard vSwitches
Sateesh Chodapuneedi created CLOUDSTACK-9673:
Summary: Exception occured while creating the CPVM in the VmWare
Setup over standard vSwitches
Key: CLOUDSTACK-9673
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9673
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Environment: ACS master commit 17653a86fad67447a4f13e455e336694ad5c1735
ESXi 5.5
Reporter: Sateesh Chodapuneedi
Exception occured while creating the CPVM in the VmWare Setup using standard
vswitches, below are the steps followed.
1) Tried to create a VMware Advanced Zone setup
2) while creating the console proxy vm the below error message is observed
{noformat}
StartCommand failed due to Exception: com.vmware.vim25.AlreadyExists
message: []
com.vmware.vim25.AlreadyExistsFaultMsg: The specified key, name, or identifier
already exists.
{noformat}
3)The same error message is also observed in the Vcenter also for both 5.5 and
5.0 setups.
Note:This error message does not prevent the creation of CPVM or any other
functionality of ACS, but this would create a panic while creating the setup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9673) Exception occured while creating the CPVM in the VmWare Setup over standard vSwitches
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9673:
-
Affects Version/s: 4.9.0.1
> Exception occured while creating the CPVM in the VmWare Setup over standard
> vSwitches
> --
>
> Key: CLOUDSTACK-9673
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9673
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.9.0.1
> Environment: ACS master commit
> 17653a86fad67447a4f13e455e336694ad5c1735
> ESXi 5.5
>Reporter: Sateesh Chodapuneedi
> Fix For: 4.10.0.0
>
>
> Exception occured while creating the CPVM in the VmWare Setup using standard
> vswitches, below are the steps followed.
> 1) Tried to create a VMware Advanced Zone setup
> 2) while creating the console proxy vm the below error message is observed
> {noformat}
> StartCommand failed due to Exception: com.vmware.vim25.AlreadyExists
> message: []
> com.vmware.vim25.AlreadyExistsFaultMsg: The specified key, name, or
> identifier already exists.
> {noformat}
> 3)The same error message is also observed in the Vcenter also for both 5.5
> and 5.0 setups.
> Note:This error message does not prevent the creation of CPVM or any other
> functionality of ACS, but this would create a panic while creating the setup.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-9654) Missing hypervisor mapping of various SUSE Linux guest os versions on VMware 6.0
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi resolved CLOUDSTACK-9654.
--
Resolution: Fixed
> Missing hypervisor mapping of various SUSE Linux guest os versions on VMware
> 6.0
>
>
> Key: CLOUDSTACK-9654
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9654
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.9.0
> Environment: ACS 4.9
> VMware 5.1
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.9.1.0
>
>
> Currently many versions of SUSE Linux does not have any hypervisor mapping
> entry in guest_os_hypervisor table in cloud database for VMware 6.0. Also
> observed that the guest_os_name field is incorrect for some SUSE Linux
> variants, which results in deployed instance (with SUSE Linux) set to guest
> OS type as "Other (64-bit)" on vCenter, which would not represent the guest
> OS accurately on hypervisor.
> The current (4.9) list of SUSE Linux guest os in database looks as below,
> {noformat}
> mysql> select id,display_name from guest_os where display_name like '%suse%';
> +-+--+
> | id | display_name |
> +-+--+
> | 40 | SUSE Linux Enterprise Server 9 SP4 (32-bit) |
> | 41 | SUSE Linux Enterprise Server 10 SP1 (32-bit) |
> | 42 | SUSE Linux Enterprise Server 10 SP1 (64-bit) |
> | 43 | SUSE Linux Enterprise Server 10 SP2 (32-bit) |
> | 44 | SUSE Linux Enterprise Server 10 SP2 (64-bit) |
> | 45 | SUSE Linux Enterprise Server 10 SP3 (64-bit) |
> | 46 | SUSE Linux Enterprise Server 11 (32-bit) |
> | 47 | SUSE Linux Enterprise Server 11 (64-bit) |
> | 96 | SUSE Linux Enterprise 8(32-bit) |
> | 97 | SUSE Linux Enterprise 8(64-bit) |
> | 107 | SUSE Linux Enterprise 9(32-bit) |
> | 108 | SUSE Linux Enterprise 9(64-bit) |
> | 109 | SUSE Linux Enterprise 10(32-bit) |
> | 110 | SUSE Linux Enterprise 10(64-bit) |
> | 151 | SUSE Linux Enterprise Server 10 SP3 (32-bit) |
> | 152 | SUSE Linux Enterprise Server 10 SP4 (64-bit) |
> | 153 | SUSE Linux Enterprise Server 10 SP4 (32-bit) |
> | 154 | SUSE Linux Enterprise Server 11 SP1 (64-bit) |
> | 155 | SUSE Linux Enterprise Server 11 SP1 (32-bit) |
> | 185 | SUSE Linux Enterprise Server 11 SP2 (64-bit) |
> | 186 | SUSE Linux Enterprise Server 11 SP2 (32-bit) |
> | 187 | SUSE Linux Enterprise Server 11 SP3 (64-bit) |
> | 188 | SUSE Linux Enterprise Server 11 SP3 (32-bit) |
> | 202 | Other SUSE Linux(32-bit) |
> | 203 | Other SUSE Linux(64-bit) |
> | 244 | SUSE Linux Enterprise Server 12 (64-bit) |
> +-+--+
> 26 rows in set (0.00 sec)
> {noformat}
> The current (4.9) hypervisor mappings for SUSE Linux guest os over VMware 6.0
> in database looks as below. We can observe in the below query result, which
> lists all hypervisor mappings for SUSE Linux guest OS over VMware 6.0, many
> guest os listed in above query result are missing their mappings for VMware
> 6.0. Hence the need to add the missing hypervisor mappings.
> {noformat}
> mysql> select o.id,o.display_name, h.guest_os_name, h.hypervisor_version from
> guest_os as o, guest_os_hypervisor as h where o.id=h.guest_os_id and
> h.hypervisor_version='6.0' and h.hypervisor_type='vmware' and o.display_name
> like '%SUSE%';
> +-+--+---++
> | id | display_name | guest_os_name | hypervisor_version
> |
> +-+--+---++
> | 96 | SUSE Linux Enterprise 8(32-bit) | suseGuest | 6.0
> |
> | 97 | SUSE Linux Enterprise 8(64-bit) | suse64Guest | 6.0
> |
> | 107 | SUSE Linux Enterprise 9(32-bit) | suseGuest | 6.0
> |
> | 108 | SUSE Linux Enterprise 9(64-bit) | suse64Guest | 6.0
> |
> | 109 | SUSE Linux Enterprise 10(32-bit) | suseGuest | 6.0
> |
> | 110 | SUSE Linux Enterprise 10(64-bit) | suse64Guest | 6.0
> |
> | 202 | Other SUSE Linux(32-bit) | suseGuest | 6.0
> |
> | 203 | Other SUSE Linux(64-bit) | suse64Guest | 6.0
> |
> +-+--+---++
> 8 rows in set (0.00 sec)
> {noformat}
--
This message was sent by Atlassian JIRA
[jira] [Updated] (CLOUDSTACK-9654) Missing hypervisor mapping of various SUSE Linux guest os versions on VMware 6.0
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9654:
-
Summary: Missing hypervisor mapping of various SUSE Linux guest os versions
on VMware 6.0 (was: Incorrect & missing hypervisor mapping of various SUSE
Linux guest os versions on VMware 6.0)
> Missing hypervisor mapping of various SUSE Linux guest os versions on VMware
> 6.0
>
>
> Key: CLOUDSTACK-9654
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9654
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.9.0
> Environment: ACS 4.9
> VMware 5.1
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.9.1.0
>
>
> Currently many versions of SUSE Linux does not have any hypervisor mapping
> entry in guest_os_hypervisor table in cloud database for VMware 6.0. Also
> observed that the guest_os_name field is incorrect for some SUSE Linux
> variants, which results in deployed instance (with SUSE Linux) set to guest
> OS type as "Other (64-bit)" on vCenter, which would not represent the guest
> OS accurately on hypervisor.
> The current (4.9) list of SUSE Linux guest os in database looks as below,
> {noformat}
> mysql> select id,display_name from guest_os where display_name like '%suse%';
> +-+--+
> | id | display_name |
> +-+--+
> | 40 | SUSE Linux Enterprise Server 9 SP4 (32-bit) |
> | 41 | SUSE Linux Enterprise Server 10 SP1 (32-bit) |
> | 42 | SUSE Linux Enterprise Server 10 SP1 (64-bit) |
> | 43 | SUSE Linux Enterprise Server 10 SP2 (32-bit) |
> | 44 | SUSE Linux Enterprise Server 10 SP2 (64-bit) |
> | 45 | SUSE Linux Enterprise Server 10 SP3 (64-bit) |
> | 46 | SUSE Linux Enterprise Server 11 (32-bit) |
> | 47 | SUSE Linux Enterprise Server 11 (64-bit) |
> | 96 | SUSE Linux Enterprise 8(32-bit) |
> | 97 | SUSE Linux Enterprise 8(64-bit) |
> | 107 | SUSE Linux Enterprise 9(32-bit) |
> | 108 | SUSE Linux Enterprise 9(64-bit) |
> | 109 | SUSE Linux Enterprise 10(32-bit) |
> | 110 | SUSE Linux Enterprise 10(64-bit) |
> | 151 | SUSE Linux Enterprise Server 10 SP3 (32-bit) |
> | 152 | SUSE Linux Enterprise Server 10 SP4 (64-bit) |
> | 153 | SUSE Linux Enterprise Server 10 SP4 (32-bit) |
> | 154 | SUSE Linux Enterprise Server 11 SP1 (64-bit) |
> | 155 | SUSE Linux Enterprise Server 11 SP1 (32-bit) |
> | 185 | SUSE Linux Enterprise Server 11 SP2 (64-bit) |
> | 186 | SUSE Linux Enterprise Server 11 SP2 (32-bit) |
> | 187 | SUSE Linux Enterprise Server 11 SP3 (64-bit) |
> | 188 | SUSE Linux Enterprise Server 11 SP3 (32-bit) |
> | 202 | Other SUSE Linux(32-bit) |
> | 203 | Other SUSE Linux(64-bit) |
> | 244 | SUSE Linux Enterprise Server 12 (64-bit) |
> +-+--+
> 26 rows in set (0.00 sec)
> {noformat}
> The current (4.9) hypervisor mappings for SUSE Linux guest os over VMware 6.0
> in database looks as below. We can observe in the below query result, which
> lists all hypervisor mappings for SUSE Linux guest OS over VMware 6.0, many
> guest os listed in above query result are missing their mappings for VMware
> 6.0. Hence the need to add the missing hypervisor mappings.
> {noformat}
> mysql> select o.id,o.display_name, h.guest_os_name, h.hypervisor_version from
> guest_os as o, guest_os_hypervisor as h where o.id=h.guest_os_id and
> h.hypervisor_version='6.0' and h.hypervisor_type='vmware' and o.display_name
> like '%SUSE%';
> +-+--+---++
> | id | display_name | guest_os_name | hypervisor_version
> |
> +-+--+---++
> | 96 | SUSE Linux Enterprise 8(32-bit) | suseGuest | 6.0
> |
> | 97 | SUSE Linux Enterprise 8(64-bit) | suse64Guest | 6.0
> |
> | 107 | SUSE Linux Enterprise 9(32-bit) | suseGuest | 6.0
> |
> | 108 | SUSE Linux Enterprise 9(64-bit) | suse64Guest | 6.0
> |
> | 109 | SUSE Linux Enterprise 10(32-bit) | suseGuest | 6.0
> |
> | 110 | SUSE Linux Enterprise 10(64-bit) | suse64Guest | 6.0
> |
> | 202 | Other SUSE Linux(32-bit) | suseGuest | 6.0
> |
> | 203 | Other SUSE Linux(64-bit) | suse64Guest | 6.0
[jira] [Updated] (CLOUDSTACK-9654) Incorrect & missing hypervisor mapping of various SUSE Linux guest os versions on VMware 6.0
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9654:
-
Summary: Incorrect & missing hypervisor mapping of various SUSE Linux guest
os versions on VMware 6.0 (was: Incorrect hypervisor mapping of various SUSE
Linux guest os versions on VMware)
> Incorrect & missing hypervisor mapping of various SUSE Linux guest os
> versions on VMware 6.0
>
>
> Key: CLOUDSTACK-9654
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9654
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.9.0
> Environment: ACS 4.9
> VMware 5.1
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.9.1.0
>
>
> Currently many versions of SUSE Linux does not have any hypervisor mapping
> entry in guest_os_hypervisor table in cloud database for VMware 6.0. Also
> observed that the guest_os_name field is incorrect for some SUSE Linux
> variants, which results in deployed instance (with SUSE Linux) set to guest
> OS type as "Other (64-bit)" on vCenter, which would not represent the guest
> OS accurately on hypervisor.
> The current (4.9) list of SUSE Linux guest os in database looks as below,
> {noformat}
> mysql> select id,display_name from guest_os where display_name like '%suse%';
> +-+--+
> | id | display_name |
> +-+--+
> | 40 | SUSE Linux Enterprise Server 9 SP4 (32-bit) |
> | 41 | SUSE Linux Enterprise Server 10 SP1 (32-bit) |
> | 42 | SUSE Linux Enterprise Server 10 SP1 (64-bit) |
> | 43 | SUSE Linux Enterprise Server 10 SP2 (32-bit) |
> | 44 | SUSE Linux Enterprise Server 10 SP2 (64-bit) |
> | 45 | SUSE Linux Enterprise Server 10 SP3 (64-bit) |
> | 46 | SUSE Linux Enterprise Server 11 (32-bit) |
> | 47 | SUSE Linux Enterprise Server 11 (64-bit) |
> | 96 | SUSE Linux Enterprise 8(32-bit) |
> | 97 | SUSE Linux Enterprise 8(64-bit) |
> | 107 | SUSE Linux Enterprise 9(32-bit) |
> | 108 | SUSE Linux Enterprise 9(64-bit) |
> | 109 | SUSE Linux Enterprise 10(32-bit) |
> | 110 | SUSE Linux Enterprise 10(64-bit) |
> | 151 | SUSE Linux Enterprise Server 10 SP3 (32-bit) |
> | 152 | SUSE Linux Enterprise Server 10 SP4 (64-bit) |
> | 153 | SUSE Linux Enterprise Server 10 SP4 (32-bit) |
> | 154 | SUSE Linux Enterprise Server 11 SP1 (64-bit) |
> | 155 | SUSE Linux Enterprise Server 11 SP1 (32-bit) |
> | 185 | SUSE Linux Enterprise Server 11 SP2 (64-bit) |
> | 186 | SUSE Linux Enterprise Server 11 SP2 (32-bit) |
> | 187 | SUSE Linux Enterprise Server 11 SP3 (64-bit) |
> | 188 | SUSE Linux Enterprise Server 11 SP3 (32-bit) |
> | 202 | Other SUSE Linux(32-bit) |
> | 203 | Other SUSE Linux(64-bit) |
> | 244 | SUSE Linux Enterprise Server 12 (64-bit) |
> +-+--+
> 26 rows in set (0.00 sec)
> {noformat}
> The current (4.9) hypervisor mappings for SUSE Linux guest os over VMware 6.0
> in database looks as below. We can observe in the below query result, which
> lists all hypervisor mappings for SUSE Linux guest OS over VMware 6.0, many
> guest os listed in above query result are missing their mappings for VMware
> 6.0. Hence the need to add the missing hypervisor mappings.
> {noformat}
> mysql> select o.id,o.display_name, h.guest_os_name, h.hypervisor_version from
> guest_os as o, guest_os_hypervisor as h where o.id=h.guest_os_id and
> h.hypervisor_version='6.0' and h.hypervisor_type='vmware' and o.display_name
> like '%SUSE%';
> +-+--+---++
> | id | display_name | guest_os_name | hypervisor_version
> |
> +-+--+---++
> | 96 | SUSE Linux Enterprise 8(32-bit) | suseGuest | 6.0
> |
> | 97 | SUSE Linux Enterprise 8(64-bit) | suse64Guest | 6.0
> |
> | 107 | SUSE Linux Enterprise 9(32-bit) | suseGuest | 6.0
> |
> | 108 | SUSE Linux Enterprise 9(64-bit) | suse64Guest | 6.0
> |
> | 109 | SUSE Linux Enterprise 10(32-bit) | suseGuest | 6.0
> |
> | 110 | SUSE Linux Enterprise 10(64-bit) | suse64Guest | 6.0
> |
> | 202 | Other SUSE Linux(32-bit) | suseGuest | 6.0
> |
> | 203 | Other SUSE Linux(64-bit) | suse64Guest
[jira] [Updated] (CLOUDSTACK-9654) Incorrect hypervisor mapping of various SUSE Linux guest os versions on VMware
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9654:
-
Description:
Currently many versions of SUSE Linux does not have any hypervisor mapping
entry in guest_os_hypervisor table in cloud database for VMware 6.0. Also
observed that the guest_os_name field is incorrect for some SUSE Linux
variants, which results in deployed instance (with SUSE Linux) set to guest OS
type as "Other (64-bit)" on vCenter, which would not represent the guest OS
accurately on hypervisor.
The current (4.9) list of SUSE Linux guest os in database looks as below,
{noformat}
mysql> select id,display_name from guest_os where display_name like '%suse%';
+-+--+
| id | display_name |
+-+--+
| 40 | SUSE Linux Enterprise Server 9 SP4 (32-bit) |
| 41 | SUSE Linux Enterprise Server 10 SP1 (32-bit) |
| 42 | SUSE Linux Enterprise Server 10 SP1 (64-bit) |
| 43 | SUSE Linux Enterprise Server 10 SP2 (32-bit) |
| 44 | SUSE Linux Enterprise Server 10 SP2 (64-bit) |
| 45 | SUSE Linux Enterprise Server 10 SP3 (64-bit) |
| 46 | SUSE Linux Enterprise Server 11 (32-bit) |
| 47 | SUSE Linux Enterprise Server 11 (64-bit) |
| 96 | SUSE Linux Enterprise 8(32-bit) |
| 97 | SUSE Linux Enterprise 8(64-bit) |
| 107 | SUSE Linux Enterprise 9(32-bit) |
| 108 | SUSE Linux Enterprise 9(64-bit) |
| 109 | SUSE Linux Enterprise 10(32-bit) |
| 110 | SUSE Linux Enterprise 10(64-bit) |
| 151 | SUSE Linux Enterprise Server 10 SP3 (32-bit) |
| 152 | SUSE Linux Enterprise Server 10 SP4 (64-bit) |
| 153 | SUSE Linux Enterprise Server 10 SP4 (32-bit) |
| 154 | SUSE Linux Enterprise Server 11 SP1 (64-bit) |
| 155 | SUSE Linux Enterprise Server 11 SP1 (32-bit) |
| 185 | SUSE Linux Enterprise Server 11 SP2 (64-bit) |
| 186 | SUSE Linux Enterprise Server 11 SP2 (32-bit) |
| 187 | SUSE Linux Enterprise Server 11 SP3 (64-bit) |
| 188 | SUSE Linux Enterprise Server 11 SP3 (32-bit) |
| 202 | Other SUSE Linux(32-bit) |
| 203 | Other SUSE Linux(64-bit) |
| 244 | SUSE Linux Enterprise Server 12 (64-bit) |
+-+--+
26 rows in set (0.00 sec)
{noformat}
The current (4.9) hypervisor mappings for SUSE Linux guest os over VMware 6.0
in database looks as below. We can observe in the below query result, which
lists all hypervisor mappings for SUSE Linux guest OS over VMware 6.0, many
guest os listed in above query result are missing their mappings for VMware
6.0. Hence the need to add the missing hypervisor mappings.
{noformat}
mysql> select o.id,o.display_name, h.guest_os_name, h.hypervisor_version from
guest_os as o, guest_os_hypervisor as h where o.id=h.guest_os_id and
h.hypervisor_version='6.0' and h.hypervisor_type='vmware' and o.display_name
like '%SUSE%';
+-+--+---++
| id | display_name | guest_os_name | hypervisor_version |
+-+--+---++
| 96 | SUSE Linux Enterprise 8(32-bit) | suseGuest | 6.0|
| 97 | SUSE Linux Enterprise 8(64-bit) | suse64Guest | 6.0|
| 107 | SUSE Linux Enterprise 9(32-bit) | suseGuest | 6.0|
| 108 | SUSE Linux Enterprise 9(64-bit) | suse64Guest | 6.0|
| 109 | SUSE Linux Enterprise 10(32-bit) | suseGuest | 6.0|
| 110 | SUSE Linux Enterprise 10(64-bit) | suse64Guest | 6.0|
| 202 | Other SUSE Linux(32-bit) | suseGuest | 6.0|
| 203 | Other SUSE Linux(64-bit) | suse64Guest | 6.0|
+-+--+---++
8 rows in set (0.00 sec)
{noformat}
was:
Currently many versions of SUSE Linux does not have any hypervisor mapping
entry in guest_os_hypervisor table in cloud database for VMware 6.0. Also
observed that the guest_os_name field is incorrect for some SUSE Linux
variants, which results in deployed instance (with SUSE Linux) set to guest OS
type as "Other (64-bit)" on vCenter, which would not represent the guest OS
accurately on hypervisor.
The current (4.9) list of SUSE Linux guest os in database looks as below,
{noformat}
mysql> select id,display_name from guest_os where display_name like '%suse%';
+-+--+
| id | display_name |
+-+--+
| 40 | SUSE Linux Enterprise Server 9 SP4 (32-bit) |
| 41 | SUSE Linux Enterprise Server 10 SP1 (32-bit) |
| 42 | SUSE Linux
[jira] [Updated] (CLOUDSTACK-9654) Incorrect hypervisor mapping of various SUSE Linux guest os versions on VMware
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9654:
-
Description:
Currently many versions of SUSE Linux does not have any hypervisor mapping
entry in guest_os_hypervisor table in cloud database for VMware 6.0. Also
observed that the guest_os_name field is incorrect for some SUSE Linux
variants, which results in deployed instance (with SUSE Linux) set to guest OS
type as "Other (64-bit)" on vCenter, which would not represent the guest OS
accurately on hypervisor.
The current (4.9) list of SUSE Linux guest os in database looks as below,
{noformat}
mysql> select id,display_name from guest_os where display_name like '%suse%';
+-+--+
| id | display_name |
+-+--+
| 40 | SUSE Linux Enterprise Server 9 SP4 (32-bit) |
| 41 | SUSE Linux Enterprise Server 10 SP1 (32-bit) |
| 42 | SUSE Linux Enterprise Server 10 SP1 (64-bit) |
| 43 | SUSE Linux Enterprise Server 10 SP2 (32-bit) |
| 44 | SUSE Linux Enterprise Server 10 SP2 (64-bit) |
| 45 | SUSE Linux Enterprise Server 10 SP3 (64-bit) |
| 46 | SUSE Linux Enterprise Server 11 (32-bit) |
| 47 | SUSE Linux Enterprise Server 11 (64-bit) |
| 96 | SUSE Linux Enterprise 8(32-bit) |
| 97 | SUSE Linux Enterprise 8(64-bit) |
| 107 | SUSE Linux Enterprise 9(32-bit) |
| 108 | SUSE Linux Enterprise 9(64-bit) |
| 109 | SUSE Linux Enterprise 10(32-bit) |
| 110 | SUSE Linux Enterprise 10(64-bit) |
| 151 | SUSE Linux Enterprise Server 10 SP3 (32-bit) |
| 152 | SUSE Linux Enterprise Server 10 SP4 (64-bit) |
| 153 | SUSE Linux Enterprise Server 10 SP4 (32-bit) |
| 154 | SUSE Linux Enterprise Server 11 SP1 (64-bit) |
| 155 | SUSE Linux Enterprise Server 11 SP1 (32-bit) |
| 185 | SUSE Linux Enterprise Server 11 SP2 (64-bit) |
| 186 | SUSE Linux Enterprise Server 11 SP2 (32-bit) |
| 187 | SUSE Linux Enterprise Server 11 SP3 (64-bit) |
| 188 | SUSE Linux Enterprise Server 11 SP3 (32-bit) |
| 202 | Other SUSE Linux(32-bit) |
| 203 | Other SUSE Linux(64-bit) |
| 244 | SUSE Linux Enterprise Server 12 (64-bit) |
+-+--+
26 rows in set (0.00 sec)
{noformat}
The current (4.9) hypervisor mappings for SUSE Linux guest os over VMware 6.0
in database looks as below. We can observe in the below query result, which
lists all hypervisor mappings for SUSE Linux many guest OS over VMware 6.0,
many guest os listed in above query result are missing. Hence the need to add
the missing hypervisor mappings.
{noformat}
mysql> select o.id,o.display_name, h.guest_os_name, h.hypervisor_version from
guest_os as o, guest_os_hypervisor as h where o.id=h.guest_os_id and
h.hypervisor_version='6.0' and h.hypervisor_type='vmware' and o.display_name
like '%SUSE%';
+-+--+---++
| id | display_name | guest_os_name | hypervisor_version |
+-+--+---++
| 96 | SUSE Linux Enterprise 8(32-bit) | suseGuest | 6.0|
| 97 | SUSE Linux Enterprise 8(64-bit) | suse64Guest | 6.0|
| 107 | SUSE Linux Enterprise 9(32-bit) | suseGuest | 6.0|
| 108 | SUSE Linux Enterprise 9(64-bit) | suse64Guest | 6.0|
| 109 | SUSE Linux Enterprise 10(32-bit) | suseGuest | 6.0|
| 110 | SUSE Linux Enterprise 10(64-bit) | suse64Guest | 6.0|
| 202 | Other SUSE Linux(32-bit) | suseGuest | 6.0|
| 203 | Other SUSE Linux(64-bit) | suse64Guest | 6.0|
+-+--+---++
8 rows in set (0.00 sec)
{noformat}
was:
Currently many versions of SUSE Linux does not have any hypervisor mapping
entry in guest_os_hypervisor table in cloud database for VMware 6.0. Also
observed that the guest_os_name field is incorrect for some SUSE Linux
variants, which results in deployed instance (with SUSE Linux) set to guest OS
type as "Other (64-bit)" on vCenter, which would not represent the guest OS
accurately on hypervisor.
The current (4.9) mappings in database looks as below,
{noformat}
mysql> select id,display_name from guest_os where display_name like '%suse%';
+-+--+
| id | display_name |
+-+--+
| 40 | SUSE Linux Enterprise Server 9 SP4 (32-bit) |
| 41 | SUSE Linux Enterprise Server 10 SP1 (32-bit) |
| 42 | SUSE Linux Enterprise Server 10 SP1 (64-bit) |
| 43 | SUSE
[jira] [Created] (CLOUDSTACK-9654) Incorrect hypervisor mapping of various SUSE Linux guest os versions on VMware
Sateesh Chodapuneedi created CLOUDSTACK-9654:
Summary: Incorrect hypervisor mapping of various SUSE Linux guest
os versions on VMware
Key: CLOUDSTACK-9654
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9654
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.9.0
Environment: ACS 4.9
VMware 5.1
Reporter: Sateesh Chodapuneedi
Assignee: Sateesh Chodapuneedi
Fix For: 4.9.1.0
Currently many versions of SUSE Linux does not have any hypervisor mapping
entry in guest_os_hypervisor table in cloud database for VMware 6.0. Also
observed that the guest_os_name field is incorrect for some SUSE Linux
variants, which results in deployed instance (with SUSE Linux) set to guest OS
type as "Other (64-bit)" on vCenter, which would not represent the guest OS
accurately on hypervisor.
The current (4.9) mappings in database looks as below,
{noformat}
mysql> select id,display_name from guest_os where display_name like '%suse%';
+-+--+
| id | display_name |
+-+--+
| 40 | SUSE Linux Enterprise Server 9 SP4 (32-bit) |
| 41 | SUSE Linux Enterprise Server 10 SP1 (32-bit) |
| 42 | SUSE Linux Enterprise Server 10 SP1 (64-bit) |
| 43 | SUSE Linux Enterprise Server 10 SP2 (32-bit) |
| 44 | SUSE Linux Enterprise Server 10 SP2 (64-bit) |
| 45 | SUSE Linux Enterprise Server 10 SP3 (64-bit) |
| 46 | SUSE Linux Enterprise Server 11 (32-bit) |
| 47 | SUSE Linux Enterprise Server 11 (64-bit) |
| 96 | SUSE Linux Enterprise 8(32-bit) |
| 97 | SUSE Linux Enterprise 8(64-bit) |
| 107 | SUSE Linux Enterprise 9(32-bit) |
| 108 | SUSE Linux Enterprise 9(64-bit) |
| 109 | SUSE Linux Enterprise 10(32-bit) |
| 110 | SUSE Linux Enterprise 10(64-bit) |
| 151 | SUSE Linux Enterprise Server 10 SP3 (32-bit) |
| 152 | SUSE Linux Enterprise Server 10 SP4 (64-bit) |
| 153 | SUSE Linux Enterprise Server 10 SP4 (32-bit) |
| 154 | SUSE Linux Enterprise Server 11 SP1 (64-bit) |
| 155 | SUSE Linux Enterprise Server 11 SP1 (32-bit) |
| 185 | SUSE Linux Enterprise Server 11 SP2 (64-bit) |
| 186 | SUSE Linux Enterprise Server 11 SP2 (32-bit) |
| 187 | SUSE Linux Enterprise Server 11 SP3 (64-bit) |
| 188 | SUSE Linux Enterprise Server 11 SP3 (32-bit) |
| 202 | Other SUSE Linux(32-bit) |
| 203 | Other SUSE Linux(64-bit) |
| 244 | SUSE Linux Enterprise Server 12 (64-bit) |
+-+--+
26 rows in set (0.00 sec)
mysql> select o.id,o.display_name, h.guest_os_name from guest_os as o,
guest_os_hypervisor as h where o.id=h.guest_os_id and
h.hypervisor_version='6.0' and h.hypervisor_type='vmware' and o.display_name
like '%SUSE%';
+-+--+---+
| id | display_name | guest_os_name |
+-+--+---+
| 96 | SUSE Linux Enterprise 8(32-bit) | suseGuest |
| 97 | SUSE Linux Enterprise 8(64-bit) | suse64Guest |
| 107 | SUSE Linux Enterprise 9(32-bit) | suseGuest |
| 108 | SUSE Linux Enterprise 9(64-bit) | suse64Guest |
| 109 | SUSE Linux Enterprise 10(32-bit) | suseGuest |
| 110 | SUSE Linux Enterprise 10(64-bit) | suse64Guest |
| 202 | Other SUSE Linux(32-bit) | suseGuest |
| 203 | Other SUSE Linux(64-bit) | suse64Guest |
+-+--+---+
8 rows in set (0.00 sec)
mysql> select * from version;
++-+-+--+
| id | version | updated | step |
++-+-+--+
| 1 | 4.0.0 | 2016-12-05 17:35:27 | Complete |
| 2 | 4.1.0 | 2016-12-05 12:05:57 | Complete |
| 3 | 4.2.0 | 2016-12-05 12:05:58 | Complete |
| 4 | 4.2.1 | 2016-12-05 12:05:58 | Complete |
| 5 | 4.3.0 | 2016-12-05 12:05:58 | Complete |
| 6 | 4.4.0 | 2016-12-05 12:05:58 | Complete |
| 7 | 4.4.1 | 2016-12-05 12:05:58 | Complete |
| 8 | 4.4.2 | 2016-12-05 12:05:58 | Complete |
| 9 | 4.5.0 | 2016-12-05 12:05:58 | Complete |
| 10 | 4.5.1 | 2016-12-05 12:05:58 | Complete |
| 11 | 4.5.2 | 2016-12-05 12:05:58 | Complete |
| 12 | 4.6.0 | 2016-12-05 12:05:58 | Complete |
| 13 | 4.6.1 | 2016-12-05 12:05:58 | Complete |
| 14 | 4.7.0 | 2016-12-05 12:05:58 | Complete |
| 15 | 4.7.1 | 2016-12-05 12:05:58 | Complete |
| 16 | 4.8.0 | 2016-12-05 12:05:58 | Complete |
| 17 | 4.8.1 | 2016-12-05 12:05:58 | Complete |
| 18 | 4.9.0 | 2016-12-05 12:05:58 | Complete |
| 19 | 4.9.1.0 | 2016-12-05 12:05:58 | Complete |
[jira] [Resolved] (CLOUDSTACK-9624) Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on VMware
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi resolved CLOUDSTACK-9624.
--
Resolution: Fixed
> Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on
> VMware
> --
>
> Key: CLOUDSTACK-9624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9624
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.9.0
> Environment: VMware 6.0,
> ACS master commit c6bb8c6f415edae8073f5d28b3a81a2eef372fed
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.9.1.0
>
>
> Guest OS Windows Server 2008 R2 (64-bit) is being mapped to incorrect guest
> os at hypervisor, which is winLonghorn64Guest, same as that of Windows Server
> 2008 (64-bit). Due to this the VM's guest os type was set to "Other
> (64-bit)", which would not represent the guest OS accurately on hypervisor.
> The current (4.9) mappings in database looks as below,
> {noformat}
> mysql> select * from guest_os where display_name like 'windows%2008%r2%64%';
> ++-+--+--+-+-+-+-+
> | id | category_id | name | uuid |
> display_name| created | removed |
> is_user_defined |
> ++-+--+--+-+-+-+-+
> | 54 | 6 | NULL | 94b8ab90-b271-11e6-b56b-4e61adb7c6b1 | Windows
> Server 2008 R2 (64-bit) | 2016-11-24 23:42:43 | NULL| 0 |
> ++-+--+--+-+-+-+-+
> 1 row in set (0.00 sec)
> mysql> select * from guest_os_hypervisor where guest_os_id in (select id from
> guest_os where display_name like 'windows%2008%r2%64%') and hypervisor_type =
> 'VMware' and hypervisor_version != 'default';
> +--+-++-++--+-+-+-+
> | id | hypervisor_type | guest_os_name | guest_os_id |
> hypervisor_version | uuid | created
> | removed | is_user_defined |
> +--+-++-++--+-+-+-+
> | 1307 | VMware | winLonghorn64Guest | 54 | 4.0
>| 98fce372-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:44 | NULL|
> 0 |
> | 1448 | VMware | winLonghorn64Guest | 54 | 4.1
>| 990abdcc-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
> 0 |
> | 1589 | VMware | winLonghorn64Guest | 54 | 5.0
>| 99166f75-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
> 0 |
> | 1730 | VMware | winLonghorn64Guest | 54 | 5.1
>| 9930ff30-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
> 0 |
> | 1871 | VMware | winLonghorn64Guest | 54 | 5.5
>| 993acb18-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
> 0 |
> | 2381 | VMware | winLonghorn64Guest | 54 | 6.0
>| 9cb53675-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 18:12:51 | NULL|
> 0 |
> +--+-++-++--+-+-+-+
> 6 rows in set (0.01 sec)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9624) Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on VMware
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9624:
-
Fix Version/s: (was: 4.10.0.0)
4.9.1.0
> Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on
> VMware
> --
>
> Key: CLOUDSTACK-9624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9624
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.9.0
> Environment: VMware 6.0,
> ACS master commit c6bb8c6f415edae8073f5d28b3a81a2eef372fed
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.9.1.0
>
>
> Guest OS Windows Server 2008 R2 (64-bit) is being mapped to incorrect guest
> os at hypervisor, which is winLonghorn64Guest, same as that of Windows Server
> 2008 (64-bit). Due to this the VM's guest os type was set to "Other
> (64-bit)", which would not represent the guest OS accurately on hypervisor.
> The current (4.9) mappings in database looks as below,
> {noformat}
> mysql> select * from guest_os where display_name like 'windows%2008%r2%64%';
> ++-+--+--+-+-+-+-+
> | id | category_id | name | uuid |
> display_name| created | removed |
> is_user_defined |
> ++-+--+--+-+-+-+-+
> | 54 | 6 | NULL | 94b8ab90-b271-11e6-b56b-4e61adb7c6b1 | Windows
> Server 2008 R2 (64-bit) | 2016-11-24 23:42:43 | NULL| 0 |
> ++-+--+--+-+-+-+-+
> 1 row in set (0.00 sec)
> mysql> select * from guest_os_hypervisor where guest_os_id in (select id from
> guest_os where display_name like 'windows%2008%r2%64%') and hypervisor_type =
> 'VMware' and hypervisor_version != 'default';
> +--+-++-++--+-+-+-+
> | id | hypervisor_type | guest_os_name | guest_os_id |
> hypervisor_version | uuid | created
> | removed | is_user_defined |
> +--+-++-++--+-+-+-+
> | 1307 | VMware | winLonghorn64Guest | 54 | 4.0
>| 98fce372-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:44 | NULL|
> 0 |
> | 1448 | VMware | winLonghorn64Guest | 54 | 4.1
>| 990abdcc-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
> 0 |
> | 1589 | VMware | winLonghorn64Guest | 54 | 5.0
>| 99166f75-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
> 0 |
> | 1730 | VMware | winLonghorn64Guest | 54 | 5.1
>| 9930ff30-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
> 0 |
> | 1871 | VMware | winLonghorn64Guest | 54 | 5.5
>| 993acb18-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
> 0 |
> | 2381 | VMware | winLonghorn64Guest | 54 | 6.0
>| 9cb53675-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 18:12:51 | NULL|
> 0 |
> +--+-++-++--+-+-+-+
> 6 rows in set (0.01 sec)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9624) Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on VMware
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15701193#comment-15701193
]
Sateesh Chodapuneedi commented on CLOUDSTACK-9624:
--
*+Solution+*
Fix is to update incorrect guest_os_name field value in DB table
cloud.guest_os_hypervisor.
Query is
{noformat}
UPDATE IGNORE `cloud`.`guest_os_hypervisor` SET guest_os_name =
'windows7Server64Guest' WHERE guest_os_id IN (SELECT id FROM guest_os WHERE
display_name LIKE 'windows%2008%r2%64%') AND hypervisor_type = 'VMware' AND
hypervisor_version != 'default';
{noformat}
After running above query, the 6 updated rows looks like
{noformat}
UPDATE IGNORE `cloud`.`guest_os_hypervisor` SET guest_os_name =
'windows7Server64Guest' WHERE guest_os_id IN (SELECT id FROM guest_os WHERE
display_name LIKE 'windows%2008%r2%64%') AND hypervisor_type = 'VMware' AND
hypervisor_version != 'default';
Query OK, 6 rows affected (0.01 sec)
Rows matched: 6 Changed: 6 Warnings: 0
mysql> select * from guest_os_hypervisor where guest_os_id in (select id from
guest_os where display_name like 'windows%2008%r2%64%') and hypervisor_type =
'VMware' and hypervisor_version != 'default';
+--+-+---+-++--+-+-+-+
| id | hypervisor_type | guest_os_name | guest_os_id |
hypervisor_version | uuid | created
| removed | is_user_defined |
+--+-+---+-++--+-+-+-+
| 1307 | VMware | windows7Server64Guest | 54 | 4.0
| 98fce372-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:44 | NULL|
0 |
| 1448 | VMware | windows7Server64Guest | 54 | 4.1
| 990abdcc-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
0 |
| 1589 | VMware | windows7Server64Guest | 54 | 5.0
| 99166f75-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
0 |
| 1730 | VMware | windows7Server64Guest | 54 | 5.1
| 9930ff30-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
0 |
| 1871 | VMware | windows7Server64Guest | 54 | 5.5
| 993acb18-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
0 |
| 2381 | VMware | windows7Server64Guest | 54 | 6.0
| 9cb53675-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 18:12:51 | NULL|
0 |
+--+-+---+-++--+-+-+-+
6 rows in set (0.01 sec)
{noformat}
> Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on
> VMware
> --
>
> Key: CLOUDSTACK-9624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9624
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.9.0
> Environment: VMware 6.0,
> ACS master commit c6bb8c6f415edae8073f5d28b3a81a2eef372fed
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.10.0.0
>
>
> Guest OS Windows Server 2008 R2 (64-bit) is being mapped to incorrect guest
> os at hypervisor, which is winLonghorn64Guest, same as that of Windows Server
> 2008 (64-bit). Due to this the VM's guest os type was set to "Other
> (64-bit)", which would not represent the guest OS accurately on hypervisor.
> The current (4.9) mappings in database looks as below,
> {noformat}
> mysql> select * from guest_os where display_name like 'windows%2008%r2%64%';
> ++-+--+--+-+-+-+-+
> | id | category_id | name | uuid |
> display_name| created | removed |
> is_user_defined |
> ++-+--+--+-+-+-+-+
> | 54 | 6 | NULL | 94b8ab90-b271-11e6-b56b-4e61adb7c6b1 | Windows
> Server 2008 R2 (64-bit) | 2016-11-24 23:42:43 | NULL| 0 |
>
[jira] [Updated] (CLOUDSTACK-9624) Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on VMware
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-9624:
-
Description:
Guest OS Windows Server 2008 R2 (64-bit) is being mapped to incorrect guest os
at hypervisor, which is winLonghorn64Guest, same as that of Windows Server 2008
(64-bit). Due to this the VM's guest os type was set to "Other (64-bit)", which
would not represent the guest OS accurately on hypervisor.
The current (4.9) mappings in database looks as below,
{noformat}
mysql> select * from guest_os where display_name like 'windows%2008%r2%64%';
++-+--+--+-+-+-+-+
| id | category_id | name | uuid | display_name
| created | removed | is_user_defined |
++-+--+--+-+-+-+-+
| 54 | 6 | NULL | 94b8ab90-b271-11e6-b56b-4e61adb7c6b1 | Windows
Server 2008 R2 (64-bit) | 2016-11-24 23:42:43 | NULL| 0 |
++-+--+--+-+-+-+-+
1 row in set (0.00 sec)
mysql> select * from guest_os_hypervisor where guest_os_id in (select id from
guest_os where display_name like 'windows%2008%r2%64%') and hypervisor_type =
'VMware' and hypervisor_version != 'default';
+--+-++-++--+-+-+-+
| id | hypervisor_type | guest_os_name | guest_os_id |
hypervisor_version | uuid | created
| removed | is_user_defined |
+--+-++-++--+-+-+-+
| 1307 | VMware | winLonghorn64Guest | 54 | 4.0
| 98fce372-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:44 | NULL|
0 |
| 1448 | VMware | winLonghorn64Guest | 54 | 4.1
| 990abdcc-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
0 |
| 1589 | VMware | winLonghorn64Guest | 54 | 5.0
| 99166f75-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
0 |
| 1730 | VMware | winLonghorn64Guest | 54 | 5.1
| 9930ff30-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
0 |
| 1871 | VMware | winLonghorn64Guest | 54 | 5.5
| 993acb18-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 23:42:45 | NULL|
0 |
| 2381 | VMware | winLonghorn64Guest | 54 | 6.0
| 9cb53675-b271-11e6-b56b-4e61adb7c6b1 | 2016-11-24 18:12:51 | NULL|
0 |
+--+-++-++--+-+-+-+
6 rows in set (0.01 sec)
{noformat}
was:
Guest OS Windows Server 2008 R2 (64-bit) is being mapped to incorrect guest os
at hypervisor, which is winLonghorn64Guest, same as that of Windows Server 2008
(64-bit). Due to this the VM's guest os type was set to "Other (64-bit)", which
would not represent the guest OS accurately on hypervisor.
> Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on
> VMware
> --
>
> Key: CLOUDSTACK-9624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9624
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.9.0
> Environment: VMware 6.0,
> ACS master commit c6bb8c6f415edae8073f5d28b3a81a2eef372fed
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.10.0.0
>
>
> Guest OS Windows Server 2008 R2 (64-bit) is being mapped to incorrect guest
> os at hypervisor, which is winLonghorn64Guest, same as that of Windows Server
> 2008 (64-bit). Due to this the VM's guest os type was set to "Other
> (64-bit)", which would not represent the guest OS accurately on hypervisor.
> The current (4.9) mappings in database looks as below,
> {noformat}
> mysql> select * from guest_os where display_name like 'windows%2008%r2%64%';
>
[jira] [Created] (CLOUDSTACK-9624) Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on VMware
Sateesh Chodapuneedi created CLOUDSTACK-9624: Summary: Incorrect hypervisor mapping of guest os Windows 2008 Server R2 (64-bit) on VMware Key: CLOUDSTACK-9624 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9624 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.9.0 Environment: VMware 6.0, ACS master commit c6bb8c6f415edae8073f5d28b3a81a2eef372fed Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.10.0.0 Guest OS Windows Server 2008 R2 (64-bit) is being mapped to incorrect guest os at hypervisor, which is winLonghorn64Guest, same as that of Windows Server 2008 (64-bit). Due to this the VM's guest os type was set to "Other (64-bit)", which would not represent the guest OS accurately on hypervisor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8676) Deploy user instance from vm snapshot for VMware hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15268297#comment-15268297 ] Sateesh Chodapuneedi commented on CLOUDSTACK-8676: -- [~prashantkm] I have not yet sent PR for this feature, will be able to send in 2 weeks. Will update you once it's ready. Thanks. > Deploy user instance from vm snapshot for VMware hypervisor > --- > > Key: CLOUDSTACK-8676 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8676 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, VMware >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: Future > > > Currently, ACS provides the ability to deploy a VM from a template or ISO. > However, ACS does not provide the ability to deploy a VM(s) directly from a > VM snapshot. > VM snapshots are stored in the primary storage and have a hierarchical or > parent/child relationship. The requirement would be to provide the ability to > deploy user instances from selected VM snapshots. Additionally, any VM > snapshot in the hierarchy can be deployed concurrently. > Even though this can be supported and applicable to all hypervisors, to > start with this feature is supported only for VMware hypervisor. > Feature specification is at > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Deploy+instance+from+VM+snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8600) Clean up VM folders in storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi resolved CLOUDSTACK-8600. -- Resolution: Fixed Assignee: Likitha Shetty > Clean up VM folders in storage > -- > > Key: CLOUDSTACK-8600 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8600 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Likitha Shetty >Assignee: Likitha Shetty >Priority: Minor > > In case of VMware. when all volumes of a VM are migrated to a different > primary storage, the empty VM folder is left behind on the old primary > storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15029926#comment-15029926 ] Sateesh Chodapuneedi commented on CLOUDSTACK-4787: -- [~bhaisaab] What is the fix you are mentioning? Earlier I've successfully tested the following branch with feature implementation. I did not merge the branch into master as is because my branch doesn't have any marvin/unit tests pointed rightly by [~dahn] and you. Commit a4cc987a6f66f20c434942956fffe5951df09e43 in cloudstack's branch refs/heads/vmware-disk-controllers from Sateesh Chodapuneedi [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a4cc987 ] Currently I am writing the tests and expecting to finish it by next week. Also I've found some issues while testing in the while, which I've fixed in my test branch, yet to be proposed for PR. Could you please wait till next week for my PR which will have additional fixes and tests for this feature. Anyway the PR #1132/#1131 doesn't have tests. Please let me know, I'll be able to send PR for this feature next week. > Allow selection of scsi controller type in vSphere > -- > > Key: CLOUDSTACK-4787 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI, VMware >Affects Versions: 4.2.0, 4.3.0 > Environment: vSphere 5.1 >Reporter: Chris Sciarrino >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.5.3, 4.7.0, 4.6.1 > > Attachments: screenshot-1.png > > > When adding an OVA template for a vSphere environment allow the selection of > the scsi controller type. > Currently the instances are deployed with the the LSI Parallel controller > type. This results in a blue screen on boot when attempting to deploy > templates that use the LSI SAS controller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15029927#comment-15029927 ] Sateesh Chodapuneedi commented on CLOUDSTACK-4787: -- [~bhaisaab] What is the fix you are mentioning? Earlier I've successfully tested the following branch with feature implementation. I did not merge the branch into master as is because my branch doesn't have any marvin/unit tests pointed rightly by [~dahn] and you. Commit a4cc987a6f66f20c434942956fffe5951df09e43 in cloudstack's branch refs/heads/vmware-disk-controllers from Sateesh Chodapuneedi [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a4cc987 ] Currently I am writing the tests and expecting to finish it by next week. Also I've found some issues while testing in the while, which I've fixed in my test branch, yet to be proposed for PR. Could you please wait till next week for my PR which will have additional fixes and tests for this feature. Anyway the PR #1132/#1131 doesn't have tests. Please let me know, I'll be able to send PR for this feature next week. > Allow selection of scsi controller type in vSphere > -- > > Key: CLOUDSTACK-4787 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, UI, VMware >Affects Versions: 4.2.0, 4.3.0 > Environment: vSphere 5.1 >Reporter: Chris Sciarrino >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.5.3, 4.7.0, 4.6.1 > > Attachments: screenshot-1.png > > > When adding an OVA template for a vSphere environment allow the selection of > the scsi controller type. > Currently the instances are deployed with the the LSI Parallel controller > type. This results in a blue screen on boot when attempting to deploy > templates that use the LSI SAS controller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7151) vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14069886#comment-14069886 ] Sateesh Chodapuneedi edited comment on CLOUDSTACK-7151 at 8/19/15 5:45 AM: --- Commit 7c4831df9292115466fb9e01fcba952a5dad31c (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7c4831d) changes logic to pick vswitch type from zone level physical traffic label ignoring the vmware traffic label information persisted per cluster. This breaks existing functionality to support a choice of vswitch type on cluster basis, which was introduced in 4.2. In 4.2, CloudStack allows admins to, 1) Choose zone level vswitch name/type through physical network traffic label. 2) Choose specific cluster level vswitch name/type through optional parameters to addCluster API and through add cluster wizard UI where user is given a list box to choose type of vSwitch and name of vSwitch. These details would be persisted to database for further reference while implementing virtual networks in any of the hosts in that cluster. This option of specific cluster level choice would help users who have a zone where some legacy clusters were based on vSwitch and they want to move to advance switch options for their guest/public traffic like vmware dvSwitch or Cisco Nexus 1000v for their remaining clusters. This option also protects existing virtual network implemented on a particular type of vswitch from modification of physical network traffic label to accommodate/flip to other type of vswitch if user want to move to another type of vswitch in this zone. Due to changes done in 4.3 (7c4831df9292115466fb9e01fcba952a5dad31c - https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7c4831d) existing customers who have chosen option (2) above in 4.2 deployment and upgraded to 4.3 will see this bug. Because in 4.2 CloudStack honours the cluster level vswitch type/name settings but in 4.3 we defaulted only to zone level physical network traffic label unless the zone level traffic label itself is defined. was (Author: sateeshc): Commit 7c4831df9292115466fb9e01fcba952a5dad31c changes logic to pick vswitch type from zone level physical traffic label ignoring the vmware traffic label information persisted per cluster. This breaks existing functionality to support a choice of vswitch type on cluster basis, which was introduced in 4.2. In 4.2, CloudStack allows admins to, 1) Choose zone level vswitch name/type through physical network traffic label. 2) Choose specific cluster level vswitch name/type through optional parameters to addCluster API and through add cluster wizard UI where user is given a list box to choose type of vSwitch and name of vSwitch. These details would be persisted to database for further reference while implementing virtual networks in any of the hosts in that cluster. This option of specific cluster level choice would help users who have a zone where some legacy clusters were based on vSwitch and they want to move to advance switch options for their guest/public traffic like vmware dvSwitch or Cisco Nexus 1000v for their remaining clusters. This option also protects existing virtual network implemented on a particular type of vswitch from modification of physical network traffic label to accommodate/flip to other type of vswitch if user want to move to another type of vswitch in this zone. Due to changes done in 4.3 (7c4831df9292115466fb9e01fcba952a5dad31c ) existing customers who have chosen option (2) above in 4.2 deployment and upgraded to 4.3 will see this bug. Because in 4.2 CloudStack honours the cluster level vswitch type/name settings but in 4.3 we defaulted only to zone level physical network traffic label unless the zone level traffic label itself is defined. vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks Key: CLOUDSTACK-7151 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7151 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0, 4.3.1 Environment: VMware ESXi 5.0 ACS 4.3.0 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 After upgrade to 4.3.0 from 4.2.0 system vms are not able to start. 2014-07-18 07:14:16,732 INFO [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Prepare network on vmwaresvs Public_Guest_Net with name prefix: cloud.public 2014-07-18 07:14:16,778 ERROR [c.c.h.v.m.HypervisorHostHelper] (DirectAgent-348:ctx-7cf2f084
[jira] [Commented] (CLOUDSTACK-8676) Deploy user instance from vm snapshot for VMware hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14647697#comment-14647697 ] Sateesh Chodapuneedi commented on CLOUDSTACK-8676: -- Currently feature is under development at github branch - https://github.com/sateesh-chodapuneedi/cloudstack/tree/deploy-from-snapshot Deploy user instance from vm snapshot for VMware hypervisor --- Key: CLOUDSTACK-8676 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8676 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, VMware Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 Currently, ACS provides the ability to deploy a VM from a template or ISO. However, ACS does not provide the ability to deploy a VM(s) directly from a VM snapshot. VM snapshots are stored in the primary storage and have a hierarchical or parent/child relationship. The requirement would be to provide the ability to deploy user instances from selected VM snapshots. Additionally, any VM snapshot in the hierarchy can be deployed concurrently. Even though this can be supported and applicable to all hypervisors, to start with this feature is supported only for VMware hypervisor. Feature specification is at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Deploy+instance+from+VM+snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8676) Deploy user instance from vm snapshot for VMware hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-8676: - Description: Currently, ACS provides the ability to deploy a VM from a template or ISO. However, ACS does not provide the ability to deploy a VM(s) directly from a VM snapshot. VM snapshots are stored in the primary storage and have a hierarchical or parent/child relationship. The requirement would be to provide the ability to deploy user instances from selected VM snapshots. Additionally, any VM snapshot in the hierarchy can be deployed concurrently. Even though this can be supported and applicable to all hypervisors, to start with this feature is supported only for VMware hypervisor. Feature specification is at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Deploy+instance+from+VM+snapshot was: Currently, ACS provides the ability to deploy a VM from a template or ISO. However, ACS does not provide the ability to deploy a VM(s) directly from a VM snapshot. VM snapshots are stored in the primary storage and have a hierarchical or parent/child relationship. The requirement would be to provide the ability to deploy user instances from selected VM snapshots. Additionally, any VM snapshot in the hierarchy can be deployed concurrently. Even though this can be supported and applicable to all hypervisors, to start with this feature is supported only for VMware hypervisor. Deploy user instance from vm snapshot for VMware hypervisor --- Key: CLOUDSTACK-8676 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8676 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, VMware Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 Currently, ACS provides the ability to deploy a VM from a template or ISO. However, ACS does not provide the ability to deploy a VM(s) directly from a VM snapshot. VM snapshots are stored in the primary storage and have a hierarchical or parent/child relationship. The requirement would be to provide the ability to deploy user instances from selected VM snapshots. Additionally, any VM snapshot in the hierarchy can be deployed concurrently. Even though this can be supported and applicable to all hypervisors, to start with this feature is supported only for VMware hypervisor. Feature specification is at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Deploy+instance+from+VM+snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8676) Deploy user instance from vm snapshot for VMware hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-8676: - Description: Currently, ACS provides the ability to deploy a VM from a template or ISO. However, ACS does not provide the ability to deploy a VM(s) directly from a VM snapshot. VM snapshots are stored in the primary storage and have a hierarchical or parent/child relationship. The requirement would be to provide the ability to deploy user instances from selected VM snapshots. Additionally, any VM snapshot in the hierarchy can be deployed concurrently. Even though this can be supported and applicable to all hypervisors, to start with this feature is supported only for VMware hypervisor. was: Currently, ACS provides the ability to deploy a VM from a template or ISO. However, ACS does not provide the ability to deploy a VM(s) directly from a VM snapshot. VM snapshots are stored in the primary storage and have a hierarchical or parent/child relationship. The requirement would be to provide the ability to deploy user instances from selected VM snapshots. Additionally, any VM snapshot in the hierarchy can be deployed concurrently. Deploy user instance from vm snapshot for VMware hypervisor --- Key: CLOUDSTACK-8676 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8676 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, VMware Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 Currently, ACS provides the ability to deploy a VM from a template or ISO. However, ACS does not provide the ability to deploy a VM(s) directly from a VM snapshot. VM snapshots are stored in the primary storage and have a hierarchical or parent/child relationship. The requirement would be to provide the ability to deploy user instances from selected VM snapshots. Additionally, any VM snapshot in the hierarchy can be deployed concurrently. Even though this can be supported and applicable to all hypervisors, to start with this feature is supported only for VMware hypervisor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8676) Deploy user instance from vm snapshot for VMware hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-8676: - Summary: Deploy user instance from vm snapshot for VMware hypervisor (was: Deploy user instance from vm snapshot) Deploy user instance from vm snapshot for VMware hypervisor --- Key: CLOUDSTACK-8676 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8676 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, VMware Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 Currently, ACS provides the ability to deploy a VM from a template or ISO. However, ACS does not provide the ability to deploy a VM(s) directly from a VM snapshot. VM snapshots are stored in the primary storage and have a hierarchical or parent/child relationship. The requirement would be to provide the ability to deploy user instances from selected VM snapshots. Additionally, any VM snapshot in the hierarchy can be deployed concurrently. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8676) Deploy user instance from vm snapshot
Sateesh Chodapuneedi created CLOUDSTACK-8676: Summary: Deploy user instance from vm snapshot Key: CLOUDSTACK-8676 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8676 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, VMware Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 Currently, ACS provides the ability to deploy a VM from a template or ISO. However, ACS does not provide the ability to deploy a VM(s) directly from a VM snapshot. VM snapshots are stored in the primary storage and have a hierarchical or parent/child relationship. The requirement would be to provide the ability to deploy user instances from selected VM snapshots. Additionally, any VM snapshot in the hierarchy can be deployed concurrently. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-3317) DVS does not support management\storage network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi resolved CLOUDSTACK-3317. -- Resolution: Fixed Fix Version/s: (was: Future) 4.6.0 DVS does not support management\storage network --- Key: CLOUDSTACK-3317 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3317 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0 Reporter: Ram Ganesh Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 The need for this was discussed long time back but looks like no one filed a bug to track this much needed change. Here is the link to the email discussion - http://markmail.org/message/sz7xudwqod44awlf#query:+page:1+mid:7t2quwaxzycatfey+state:results -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265743#comment-14265743 ] Sateesh Chodapuneedi commented on CLOUDSTACK-4787: -- Using branch *vmware-disk-controllers* for code changes of this feature. Allow selection of scsi controller type in vSphere -- Key: CLOUDSTACK-4787 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI, VMware Affects Versions: 4.2.0, 4.3.0 Environment: vSphere 5.1 Reporter: Chris Sciarrino Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: 4.6.0 When adding an OVA template for a vSphere environment allow the selection of the scsi controller type. Currently the instances are deployed with the the LSI Parallel controller type. This results in a blue screen on boot when attempting to deploy templates that use the LSI SAS controller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4139) [VMWARE]Failed to resize the volumes which are created from snapshot of root volume with controller type IDE.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241059#comment-14241059
]
Sateesh Chodapuneedi commented on CLOUDSTACK-4139:
--
Moving this bug to 4.6 as this is not critical bug and 4.5 is in RC phase. Also
as noted in previous comments this is a corner case and there exists work
around (detach the volume, resize and attach again).
[VMWARE]Failed to resize the volumes which are created from snapshot of root
volume with controller type IDE.
-
Key: CLOUDSTACK-4139
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4139
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller, VMware
Affects Versions: 4.2.0
Reporter: Sailaja Mada
Assignee: Sateesh Chodapuneedi
Fix For: 4.6.0, 4.4.3
Attachments: apilog.log, management-server.log, newdb.sql
Steps:
1. Configure Adv zone with VMWARE cluster with Zone wide primary storage
2. Deploy instance
3. Create snapshot from ROOT volume
4. Attach the volume to an instance
5. Tried to resize the volume from 2 GB to 5 GB .
Observation:
1. It Failed to resize the volumes which are created from snapshot .
2. Task notification says resize is completed from UI but it failed and no
resize happened for this volume
3. I could resize the DATA volumes which are added by using the disk offering
and attached to the instance.
2013-08-07 16:37:31,370 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-6:null) SeqA 3-785: Sending Seq 3-785: { Ans: ,
MgmtId: 187767034175903, via: 3, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2013-08-07 16:37:33,253 DEBUG [cloud.api.ApiServlet] (catalina-exec-21:null)
===START=== 10.144.6.19 -- GET
command=resizeVolumeid=480c853c-e70a-46a0-a6d6-ae74b416f318shrinkok=falsediskofferingid=34443d4d-f29c-4d3f-8bb6-f6ae76e34b0dresponse=jsonsessionkey=nmiUJgTgEEYHRt8hx5StkuJr5tA%3D_=1375873540089
2013-08-07 16:37:33,296 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-21:null) submit async job-49 = [
40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ], details: AsyncJobVO {id:49, userId:
3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: null,
cmd: org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd,
cmdOriginator: null, cmdInfo:
{id:480c853c-e70a-46a0-a6d6-ae74b416f318,response:json,sessionkey:nmiUJgTgEEYHRt8hx5StkuJr5tA\u003d,shrinkok:false,cmdEventType:VOLUME.RESIZE,ctxUserId:3,httpmethod:GET,_:1375873540089,ctxAccountId:3,diskofferingid:34443d4d-f29c-4d3f-8bb6-f6ae76e34b0d,ctxStartEventId:182},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 187767034175903,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-08-07 16:37:33,301 DEBUG [cloud.api.ApiServlet] (catalina-exec-21:null)
===END=== 10.144.6.19 -- GET
command=resizeVolumeid=480c853c-e70a-46a0-a6d6-ae74b416f318shrinkok=falsediskofferingid=34443d4d-f29c-4d3f-8bb6-f6ae76e34b0dresponse=jsonsessionkey=nmiUJgTgEEYHRt8hx5StkuJr5tA%3D_=1375873540089
2013-08-07 16:37:33,342 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Executing
org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd for job-49 = [
40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]
2013-08-07 16:37:33,488 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Access to
Vol[35|vm=16|DATADISK] granted to Acct[3-cdcuser1] by
DomainChecker_EnhancerByCloudStack_ccb7a71
2013-08-07 16:37:33,534 DEBUG [agent.transport.Request]
(Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Seq
2-1287389738: Sending { Cmd , MgmtId: 187767034175903, via: 2, Ver: v1,
Flags: 100011,
[{com.cloud.agent.api.storage.ResizeVolumeCommand:{path:e9166262ee514a398028c04bf21d80b7,pool:{id:2,uuid:004a6f4c-232c-3a09-9013-e47fe47da3fb,host:10.102.192.100,path:/cpg_vol/sailaja/finalps2,port:2049,type:NetworkFilesystem},vmInstance:i-3-16-VM,newSize:5368709120,currentSize:2147483648,shrinkOk:false,wait:0}}]
}
2013-08-07 16:37:33,534 DEBUG [agent.transport.Request]
(Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Seq
2-1287389738: Executing: { Cmd , MgmtId: 187767034175903, via: 2, Ver: v1,
Flags: 100011,
[jira] [Updated] (CLOUDSTACK-4139) [VMWARE]Failed to resize the volumes which are created from snapshot of root volume with controller type IDE.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-4139:
-
Fix Version/s: (was: 4.5.0)
4.6.0
[VMWARE]Failed to resize the volumes which are created from snapshot of root
volume with controller type IDE.
-
Key: CLOUDSTACK-4139
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4139
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller, VMware
Affects Versions: 4.2.0
Reporter: Sailaja Mada
Assignee: Sateesh Chodapuneedi
Fix For: 4.6.0, 4.4.3
Attachments: apilog.log, management-server.log, newdb.sql
Steps:
1. Configure Adv zone with VMWARE cluster with Zone wide primary storage
2. Deploy instance
3. Create snapshot from ROOT volume
4. Attach the volume to an instance
5. Tried to resize the volume from 2 GB to 5 GB .
Observation:
1. It Failed to resize the volumes which are created from snapshot .
2. Task notification says resize is completed from UI but it failed and no
resize happened for this volume
3. I could resize the DATA volumes which are added by using the disk offering
and attached to the instance.
2013-08-07 16:37:31,370 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-6:null) SeqA 3-785: Sending Seq 3-785: { Ans: ,
MgmtId: 187767034175903, via: 3, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2013-08-07 16:37:33,253 DEBUG [cloud.api.ApiServlet] (catalina-exec-21:null)
===START=== 10.144.6.19 -- GET
command=resizeVolumeid=480c853c-e70a-46a0-a6d6-ae74b416f318shrinkok=falsediskofferingid=34443d4d-f29c-4d3f-8bb6-f6ae76e34b0dresponse=jsonsessionkey=nmiUJgTgEEYHRt8hx5StkuJr5tA%3D_=1375873540089
2013-08-07 16:37:33,296 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-21:null) submit async job-49 = [
40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ], details: AsyncJobVO {id:49, userId:
3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: null,
cmd: org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd,
cmdOriginator: null, cmdInfo:
{id:480c853c-e70a-46a0-a6d6-ae74b416f318,response:json,sessionkey:nmiUJgTgEEYHRt8hx5StkuJr5tA\u003d,shrinkok:false,cmdEventType:VOLUME.RESIZE,ctxUserId:3,httpmethod:GET,_:1375873540089,ctxAccountId:3,diskofferingid:34443d4d-f29c-4d3f-8bb6-f6ae76e34b0d,ctxStartEventId:182},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 187767034175903,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-08-07 16:37:33,301 DEBUG [cloud.api.ApiServlet] (catalina-exec-21:null)
===END=== 10.144.6.19 -- GET
command=resizeVolumeid=480c853c-e70a-46a0-a6d6-ae74b416f318shrinkok=falsediskofferingid=34443d4d-f29c-4d3f-8bb6-f6ae76e34b0dresponse=jsonsessionkey=nmiUJgTgEEYHRt8hx5StkuJr5tA%3D_=1375873540089
2013-08-07 16:37:33,342 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Executing
org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd for job-49 = [
40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]
2013-08-07 16:37:33,488 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Access to
Vol[35|vm=16|DATADISK] granted to Acct[3-cdcuser1] by
DomainChecker_EnhancerByCloudStack_ccb7a71
2013-08-07 16:37:33,534 DEBUG [agent.transport.Request]
(Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Seq
2-1287389738: Sending { Cmd , MgmtId: 187767034175903, via: 2, Ver: v1,
Flags: 100011,
[{com.cloud.agent.api.storage.ResizeVolumeCommand:{path:e9166262ee514a398028c04bf21d80b7,pool:{id:2,uuid:004a6f4c-232c-3a09-9013-e47fe47da3fb,host:10.102.192.100,path:/cpg_vol/sailaja/finalps2,port:2049,type:NetworkFilesystem},vmInstance:i-3-16-VM,newSize:5368709120,currentSize:2147483648,shrinkOk:false,wait:0}}]
}
2013-08-07 16:37:33,534 DEBUG [agent.transport.Request]
(Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Seq
2-1287389738: Executing: { Cmd , MgmtId: 187767034175903, via: 2, Ver: v1,
Flags: 100011,
[{com.cloud.agent.api.storage.ResizeVolumeCommand:{path:e9166262ee514a398028c04bf21d80b7,pool:{id:2,uuid:004a6f4c-232c-3a09-9013-e47fe47da3fb,host:10.102.192.100,path:/cpg_vol/sailaja/finalps2,port:2049,type:NetworkFilesystem},vmInstance:i-3-16-VM,newSize:5368709120,currentSize:2147483648,shrinkOk:false,wait:0}}]
}
2013-08-07 16:37:33,557 DEBUG [agent.manager.DirectAgentAttache]
[jira] [Updated] (CLOUDSTACK-7803) Storage live migration of instance may not happen if instance has ISO attached.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-7803: - Fix Version/s: (was: 4.5.0) 4.6.0 Storage live migration of instance may not happen if instance has ISO attached. --- Key: CLOUDSTACK-7803 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7803 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Environment: vSphere 5.1 CloudStack 4.3 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 If user instance has ISO (other than vmware tools ISO) attached, then storage live migration may not happen. Steps:- 1) Create user instance 2) Register ISO, wait till it is installed successfully 3) Attach registered ISO in step(2) 4) Migrate VM to another host which needs storage migration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7803) Storage live migration of instance may not happen if instance has ISO attached.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239242#comment-14239242 ] Sateesh Chodapuneedi edited comment on CLOUDSTACK-7803 at 12/9/14 10:31 AM: Moving this ticket to 4.6 as it is not critical bug to be included in 4.5 release which is in RC phase now. was (Author: sateeshc): Moving this ticket 4.6 as it is not critical bug to be included in 4.5 release which is in RC phase now. Storage live migration of instance may not happen if instance has ISO attached. --- Key: CLOUDSTACK-7803 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7803 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Environment: vSphere 5.1 CloudStack 4.3 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 If user instance has ISO (other than vmware tools ISO) attached, then storage live migration may not happen. Steps:- 1) Create user instance 2) Register ISO, wait till it is installed successfully 3) Attach registered ISO in step(2) 4) Migrate VM to another host which needs storage migration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7803) Storage live migration of instance may not happen if instance has ISO attached.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239242#comment-14239242 ] Sateesh Chodapuneedi commented on CLOUDSTACK-7803: -- Moving this ticket 4.6 as it is not critical bug to be included in 4.5 release which is in RC phase now. Storage live migration of instance may not happen if instance has ISO attached. --- Key: CLOUDSTACK-7803 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7803 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Environment: vSphere 5.1 CloudStack 4.3 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 If user instance has ISO (other than vmware tools ISO) attached, then storage live migration may not happen. Steps:- 1) Create user instance 2) Register ISO, wait till it is installed successfully 3) Attach registered ISO in step(2) 4) Migrate VM to another host which needs storage migration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7803) Storage live migration of instance may not happen if instance has ISO attached.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi resolved CLOUDSTACK-7803. -- Resolution: Fixed Storage live migration of instance may not happen if instance has ISO attached. --- Key: CLOUDSTACK-7803 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7803 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Environment: vSphere 5.1 CloudStack 4.3 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 If user instance has ISO (other than vmware tools ISO) attached, then storage live migration may not happen. Steps:- 1) Create user instance 2) Register ISO, wait till it is installed successfully 3) Attach registered ISO in step(2) 4) Migrate VM to another host which needs storage migration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7151) vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-7151: - Fix Version/s: (was: 4.5.0) 4.6.0 vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks Key: CLOUDSTACK-7151 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7151 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0, 4.3.1 Environment: VMware ESXi 5.0 ACS 4.3.0 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 After upgrade to 4.3.0 from 4.2.0 system vms are not able to start. 2014-07-18 07:14:16,732 INFO [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Prepare network on vmwaresvs Public_Guest_Net with name prefix: cloud.public 2014-07-18 07:14:16,778 ERROR [c.c.h.v.m.HypervisorHostHelper] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Unable to find vSwitchPublic_Guest_Net 2014-07-18 07:14:16,778 WARN [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) StartCommand failed due to Exception: java.lang.Exception Message: Unable to find vSwitchPublic_Guest_Net -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7151) vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239247#comment-14239247 ] Sateesh Chodapuneedi commented on CLOUDSTACK-7151: -- As per comment #1 https://issues.apache.org/jira/browse/CLOUDSTACK-7151?focusedCommentId=14069886page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14069886 this issue is specific to cases where users are looking to have mix of virtual switches within a zone, which is not common. Moving this to 4.6 as this is not critical. vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks Key: CLOUDSTACK-7151 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7151 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0, 4.3.1 Environment: VMware ESXi 5.0 ACS 4.3.0 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 After upgrade to 4.3.0 from 4.2.0 system vms are not able to start. 2014-07-18 07:14:16,732 INFO [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Prepare network on vmwaresvs Public_Guest_Net with name prefix: cloud.public 2014-07-18 07:14:16,778 ERROR [c.c.h.v.m.HypervisorHostHelper] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Unable to find vSwitchPublic_Guest_Net 2014-07-18 07:14:16,778 WARN [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) StartCommand failed due to Exception: java.lang.Exception Message: Unable to find vSwitchPublic_Guest_Net -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7151) vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239248#comment-14239248 ] Sateesh Chodapuneedi commented on CLOUDSTACK-7151: -- Work is in progress to fix it in ACS master for 4.6 vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks Key: CLOUDSTACK-7151 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7151 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0, 4.3.1 Environment: VMware ESXi 5.0 ACS 4.3.0 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 After upgrade to 4.3.0 from 4.2.0 system vms are not able to start. 2014-07-18 07:14:16,732 INFO [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Prepare network on vmwaresvs Public_Guest_Net with name prefix: cloud.public 2014-07-18 07:14:16,778 ERROR [c.c.h.v.m.HypervisorHostHelper] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Unable to find vSwitchPublic_Guest_Net 2014-07-18 07:14:16,778 WARN [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) StartCommand failed due to Exception: java.lang.Exception Message: Unable to find vSwitchPublic_Guest_Net -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5933) Problem with VMware snapshot when datastore has a space in its name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-5933: - Fix Version/s: (was: 4.5.0) 4.6.0 Problem with VMware snapshot when datastore has a space in its name --- Key: CLOUDSTACK-5933 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5933 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0 Environment: Management Server on Ubuntu 12.04.1 ESXi 5.1 Reporter: Mike Tutkowski Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 I have two hosts in my VMware cluster. I elected to have vSphere Client use its default names for the datastore of each host's local storage. These names are the following: datastore1 and datastore1 (1) Note the presence of a space in the second datastore name. This space causes our creation of a VM snapshot to return to the management server an incorrect path field. For example, let's say the path in the DB of our root disk is abcxyz before the VM snapshot. After the VM snapshot, it should be abcxyz-01; however, it is still abcxyz. The problem is in this method in VmwareStorageManagerImpl: extractSnapshotBaseFileName That method is treating the space character as a delimiter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5933) Problem with VMware snapshot when datastore has a space in its name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239336#comment-14239336 ] Sateesh Chodapuneedi commented on CLOUDSTACK-5933: -- Moving to to 4.6 as this is not critical bug and 4.5 is in RC phase. Problem with VMware snapshot when datastore has a space in its name --- Key: CLOUDSTACK-5933 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5933 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0 Environment: Management Server on Ubuntu 12.04.1 ESXi 5.1 Reporter: Mike Tutkowski Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 I have two hosts in my VMware cluster. I elected to have vSphere Client use its default names for the datastore of each host's local storage. These names are the following: datastore1 and datastore1 (1) Note the presence of a space in the second datastore name. This space causes our creation of a VM snapshot to return to the management server an incorrect path field. For example, let's say the path in the DB of our root disk is abcxyz before the VM snapshot. After the VM snapshot, it should be abcxyz-01; however, it is still abcxyz. The problem is in this method in VmwareStorageManagerImpl: extractSnapshotBaseFileName That method is treating the space character as a delimiter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-5933) Problem with VMware snapshot when datastore has a space in its name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239336#comment-14239336 ] Sateesh Chodapuneedi edited comment on CLOUDSTACK-5933 at 12/9/14 12:08 PM: Moving this bug to 4.6 as this is not critical bug and 4.5 is in RC phase. was (Author: sateeshc): Moving to to 4.6 as this is not critical bug and 4.5 is in RC phase. Problem with VMware snapshot when datastore has a space in its name --- Key: CLOUDSTACK-5933 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5933 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0 Environment: Management Server on Ubuntu 12.04.1 ESXi 5.1 Reporter: Mike Tutkowski Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 I have two hosts in my VMware cluster. I elected to have vSphere Client use its default names for the datastore of each host's local storage. These names are the following: datastore1 and datastore1 (1) Note the presence of a space in the second datastore name. This space causes our creation of a VM snapshot to return to the management server an incorrect path field. For example, let's say the path in the DB of our root disk is abcxyz before the VM snapshot. After the VM snapshot, it should be abcxyz-01; however, it is still abcxyz. The problem is in this method in VmwareStorageManagerImpl: extractSnapshotBaseFileName That method is treating the space character as a delimiter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5933) Problem with VMware snapshot when datastore has a space in its name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239353#comment-14239353 ] Sateesh Chodapuneedi commented on CLOUDSTACK-5933: -- Fixed in ACS master (4.6) Problem with VMware snapshot when datastore has a space in its name --- Key: CLOUDSTACK-5933 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5933 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0 Environment: Management Server on Ubuntu 12.04.1 ESXi 5.1 Reporter: Mike Tutkowski Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 I have two hosts in my VMware cluster. I elected to have vSphere Client use its default names for the datastore of each host's local storage. These names are the following: datastore1 and datastore1 (1) Note the presence of a space in the second datastore name. This space causes our creation of a VM snapshot to return to the management server an incorrect path field. For example, let's say the path in the DB of our root disk is abcxyz before the VM snapshot. After the VM snapshot, it should be abcxyz-01; however, it is still abcxyz. The problem is in this method in VmwareStorageManagerImpl: extractSnapshotBaseFileName That method is treating the space character as a delimiter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-5933) Problem with VMware snapshot when datastore has a space in its name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi resolved CLOUDSTACK-5933. -- Resolution: Fixed Problem with VMware snapshot when datastore has a space in its name --- Key: CLOUDSTACK-5933 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5933 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0 Environment: Management Server on Ubuntu 12.04.1 ESXi 5.1 Reporter: Mike Tutkowski Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 I have two hosts in my VMware cluster. I elected to have vSphere Client use its default names for the datastore of each host's local storage. These names are the following: datastore1 and datastore1 (1) Note the presence of a space in the second datastore name. This space causes our creation of a VM snapshot to return to the management server an incorrect path field. For example, let's say the path in the DB of our root disk is abcxyz before the VM snapshot. After the VM snapshot, it should be abcxyz-01; however, it is still abcxyz. The problem is in this method in VmwareStorageManagerImpl: extractSnapshotBaseFileName That method is treating the space character as a delimiter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-4593) [VMWARE] [Upgrade]Livestorage Migration VM Snapshot features are not fully functional after upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-4593: - Fix Version/s: (was: 4.4.3) (was: 4.5.0) Future [VMWARE] [Upgrade]Livestorage Migration VM Snapshot features are not fully functional after upgrade -- Key: CLOUDSTACK-4593 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4593 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller, Upgrade, VMware Affects Versions: 4.2.1 Reporter: Sailaja Mada Assignee: Sateesh Chodapuneedi Fix For: Future Attachments: apilogs.rar, clouddbback.dmp, mgmtlogs.rar Steps: Upgraded setup : 307 Setup with 2 clusters ( Cluster1 – 2 ESXi 5.0 hosts , Cluster2 – Esxi 4.1 host) 1.11 Vm’s deployed with 2 VM’s in stopped state 2.VM’s with ROOT volume, 2 DATA volumes, 3 DATA volumes 3.Snapshots , Template / volumes from this snapshot 4.Detached volumes 5.Empty volumes which are not attached to any instance 6.Cluster with 2 primary storage's Upgraded to 4.2 I got into below failures with VM Snapshot if tried without Stop/Start of the VM Post upgrade : 2013-09-02 21:35:36,733 WARN [vmware.resource.VmwareResource] (DirectAgent-320:10.102.192.23) StartCommand failed due to Exception: java.lang.RuntimeException Message: File unspecified filename was not found java.lang.RuntimeException: File unspecified filename was not found at com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:378) at com.cloud.hypervisor.vmware.mo.VirtualMachineMO.powerOn(VirtualMachineMO.java:188) at com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2966) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:519) at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2013-09-02 21:35:36,742 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-320:null) Seq 6-949618439: Response Received: 2013-09-02 21:35:43,972 INFO [storage.volume.VolumeServiceImpl] (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) Volume 52 is not referred anywhere, remove it from volumes table 2013-09-02 21:35:43,981 ERROR [cloud.storage.VolumeManagerImpl] (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) migrate volume failed:copy volume from primary to secondary failed due to exception: Exception: java.lang.Exception Message: Unable to find related disk device for volume. volume path: ROOT-14-30-04 2013-09-02 21:35:43,990 INFO [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) Unable to contact resource. com.cloud.exception.StorageUnavailableException: Resource [StoragePool:203] is unreachable: migrate volume failed: copy volume from primary to secondary failed due to exception: Exception: java.lang.Exception Message: Unable to find related disk device for volume. volume path: ROOT-14-30-04 at com.cloud.storage.VolumeManagerImpl.migrateVolume(VolumeManagerImpl.java:2254) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2590) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:888) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:237) at
[jira] [Commented] (CLOUDSTACK-4593) [VMWARE] [Upgrade]Livestorage Migration VM Snapshot features are not fully functional after upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14235305#comment-14235305 ] Sateesh Chodapuneedi commented on CLOUDSTACK-4593: -- Targeting this bug to future release as this is involved change. This is tricky one to fix as computing snapshot chain information may not be deterministic in case of out of band changes. For now we have the work around of stopping and starting the instance post upgrade. [VMWARE] [Upgrade]Livestorage Migration VM Snapshot features are not fully functional after upgrade -- Key: CLOUDSTACK-4593 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4593 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller, Upgrade, VMware Affects Versions: 4.2.1 Reporter: Sailaja Mada Assignee: Sateesh Chodapuneedi Fix For: Future Attachments: apilogs.rar, clouddbback.dmp, mgmtlogs.rar Steps: Upgraded setup : 307 Setup with 2 clusters ( Cluster1 – 2 ESXi 5.0 hosts , Cluster2 – Esxi 4.1 host) 1.11 Vm’s deployed with 2 VM’s in stopped state 2.VM’s with ROOT volume, 2 DATA volumes, 3 DATA volumes 3.Snapshots , Template / volumes from this snapshot 4.Detached volumes 5.Empty volumes which are not attached to any instance 6.Cluster with 2 primary storage's Upgraded to 4.2 I got into below failures with VM Snapshot if tried without Stop/Start of the VM Post upgrade : 2013-09-02 21:35:36,733 WARN [vmware.resource.VmwareResource] (DirectAgent-320:10.102.192.23) StartCommand failed due to Exception: java.lang.RuntimeException Message: File unspecified filename was not found java.lang.RuntimeException: File unspecified filename was not found at com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:378) at com.cloud.hypervisor.vmware.mo.VirtualMachineMO.powerOn(VirtualMachineMO.java:188) at com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2966) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:519) at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2013-09-02 21:35:36,742 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-320:null) Seq 6-949618439: Response Received: 2013-09-02 21:35:43,972 INFO [storage.volume.VolumeServiceImpl] (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) Volume 52 is not referred anywhere, remove it from volumes table 2013-09-02 21:35:43,981 ERROR [cloud.storage.VolumeManagerImpl] (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) migrate volume failed:copy volume from primary to secondary failed due to exception: Exception: java.lang.Exception Message: Unable to find related disk device for volume. volume path: ROOT-14-30-04 2013-09-02 21:35:43,990 INFO [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) Unable to contact resource. com.cloud.exception.StorageUnavailableException: Resource [StoragePool:203] is unreachable: migrate volume failed: copy volume from primary to secondary failed due to exception: Exception: java.lang.Exception Message: Unable to find related disk device for volume. volume path: ROOT-14-30-04 at com.cloud.storage.VolumeManagerImpl.migrateVolume(VolumeManagerImpl.java:2254) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2590) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:888) at
[jira] [Updated] (CLOUDSTACK-7599) Virtual Router not staying in Started State
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-7599: - Assignee: Sanjay Tripathi (was: Sateesh Chodapuneedi) Virtual Router not staying in Started State --- Key: CLOUDSTACK-7599 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7599 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.5.0 Environment: VMware ESX 5.1 Ubuntu 12.04 for Management Server Reporter: Mike Tutkowski Assignee: Sanjay Tripathi Fix For: 4.5.0 Most recently, I used this template: http://download.cloud.com/templates/4.5/systemvm64template-4.5-vmware.ova Checksum: 3106a79a4ce66cd7f6a7c50e93f2db57 Before using the above template, I also used this template: http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-vmware.ova They both ended with similar results. They work for SSVM and CPVM, but when the VR is brought up, it eventually gets to a point where it reboots, starts back up, then - at some point - its VM is shut down. If you try to restart the VM from the CS GUI, it auto shuts down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7599) Virtual Router not staying in Started State
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14235383#comment-14235383 ] Sateesh Chodapuneedi commented on CLOUDSTACK-7599: -- Sanjay, This looks like not reproducible with latest system template from Jenkins. Can you please check if you are hitting the issue still? Virtual Router not staying in Started State --- Key: CLOUDSTACK-7599 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7599 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.5.0 Environment: VMware ESX 5.1 Ubuntu 12.04 for Management Server Reporter: Mike Tutkowski Assignee: Sanjay Tripathi Fix For: 4.5.0 Most recently, I used this template: http://download.cloud.com/templates/4.5/systemvm64template-4.5-vmware.ova Checksum: 3106a79a4ce66cd7f6a7c50e93f2db57 Before using the above template, I also used this template: http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-vmware.ova They both ended with similar results. They work for SSVM and CPVM, but when the VR is brought up, it eventually gets to a point where it reboots, starts back up, then - at some point - its VM is shut down. If you try to restart the VM from the CS GUI, it auto shuts down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-4787: - Fix Version/s: (was: Future) 4.6.0 Allow selection of scsi controller type in vSphere -- Key: CLOUDSTACK-4787 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI, VMware Affects Versions: 4.2.0, 4.3.0 Environment: vSphere 5.1 Reporter: Chris Sciarrino Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: 4.6.0 When adding an OVA template for a vSphere environment allow the selection of the scsi controller type. Currently the instances are deployed with the the LSI Parallel controller type. This results in a blue screen on boot when attempting to deploy templates that use the LSI SAS controller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6104) PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213506#comment-14213506 ] Sateesh Chodapuneedi commented on CLOUDSTACK-6104: -- Moved to 4.6 PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment -- Key: CLOUDSTACK-6104 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6104 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller, VMware Affects Versions: 4.5.0 Environment: CloudStack deployed over VMware ESXi hypervisor with Nexus 1000v as distributed virtual switch. Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: Future Currently PVLAN support is available in CloudStack deployment over VMware ESXi hypervisor for VMware dvSwitch only. This needs to be extended to Cisco Nexus 1000v as well. Code changes are required on resource front to ensure PVLAN setup/configuration done over Nexus 1000v switch in the same way as currently being done over VMware dvSwitch. FS - https://cwiki.apache.org/confluence/display/CLOUDSTACK/PVLAN+support+for+CloudStack+deployment+over+Nexus+1000v+in+VMware+environment Background of support of PVLAN in CloudStack :- https://cwiki.apache.org/confluence/display/CLOUDSTACK/Isolation+in+Advanced+Zone+using+PVLANs+-+Functional+Specification+for+VMWare+integration+with+CloudStack https://cwiki.apache.org/confluence/display/CLOUDSTACK/Isolation+in+Advanced+Zone+using+PVLANs https://cwiki.apache.org/confluence/display/CLOUDSTACK/PVLAN+for+isolation+within+a+VLAN -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6104) PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-6104: - Fix Version/s: (was: 4.5.0) Future PVLAN support for CloudStack deployment over Nexus 1000v in VMware environment -- Key: CLOUDSTACK-6104 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6104 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller, VMware Affects Versions: 4.5.0 Environment: CloudStack deployed over VMware ESXi hypervisor with Nexus 1000v as distributed virtual switch. Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: Future Currently PVLAN support is available in CloudStack deployment over VMware ESXi hypervisor for VMware dvSwitch only. This needs to be extended to Cisco Nexus 1000v as well. Code changes are required on resource front to ensure PVLAN setup/configuration done over Nexus 1000v switch in the same way as currently being done over VMware dvSwitch. FS - https://cwiki.apache.org/confluence/display/CLOUDSTACK/PVLAN+support+for+CloudStack+deployment+over+Nexus+1000v+in+VMware+environment Background of support of PVLAN in CloudStack :- https://cwiki.apache.org/confluence/display/CLOUDSTACK/Isolation+in+Advanced+Zone+using+PVLANs+-+Functional+Specification+for+VMWare+integration+with+CloudStack https://cwiki.apache.org/confluence/display/CLOUDSTACK/Isolation+in+Advanced+Zone+using+PVLANs https://cwiki.apache.org/confluence/display/CLOUDSTACK/PVLAN+for+isolation+within+a+VLAN -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7714) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-7714: - Fix Version/s: (was: 4.5.0) 4.6.0 Triage and fix Coverity defects --- Key: CLOUDSTACK-7714 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7714 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Santhosh Kumar Edukulla Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 1. We have Coverity setup available, running as scheduled and individual owners are assigned with analyzed bugs. 2. As part of this bug, please triage and fix the relevant Coverity bugs assigned. It could be a count as small as 25 bugs. 3. First start with high impact in order to others later. 4. We can either triage them accordingly as fix required or false positive or not a bug accordingly. But, triage and fix accordingly wherever relevant and applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7714) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213508#comment-14213508 ] Sateesh Chodapuneedi commented on CLOUDSTACK-7714: -- Most of the coverity issues are minor and could be addressed in 4.6. Triage and fix Coverity defects --- Key: CLOUDSTACK-7714 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7714 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Santhosh Kumar Edukulla Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 1. We have Coverity setup available, running as scheduled and individual owners are assigned with analyzed bugs. 2. As part of this bug, please triage and fix the relevant Coverity bugs assigned. It could be a count as small as 25 bugs. 3. First start with high impact in order to others later. 4. We can either triage them accordingly as fix required or false positive or not a bug accordingly. But, triage and fix accordingly wherever relevant and applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7714) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213508#comment-14213508 ] Sateesh Chodapuneedi edited comment on CLOUDSTACK-7714 at 11/15/14 10:09 AM: - Most of the coverity issues seems minor issues and could be addressed in 4.6. was (Author: sateeshc): Most of the coverity issues are minor and could be addressed in 4.6. Triage and fix Coverity defects --- Key: CLOUDSTACK-7714 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7714 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Santhosh Kumar Edukulla Assignee: Sateesh Chodapuneedi Fix For: 4.6.0 1. We have Coverity setup available, running as scheduled and individual owners are assigned with analyzed bugs. 2. As part of this bug, please triage and fix the relevant Coverity bugs assigned. It could be a count as small as 25 bugs. 3. First start with high impact in order to others later. 4. We can either triage them accordingly as fix required or false positive or not a bug accordingly. But, triage and fix accordingly wherever relevant and applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7803) Storage live migration of instance may not happen if instance has ISO attached.
Sateesh Chodapuneedi created CLOUDSTACK-7803: Summary: Storage live migration of instance may not happen if instance has ISO attached. Key: CLOUDSTACK-7803 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7803 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Environment: vSphere 5.1 CloudStack 4.3 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.5.0 If user instance has ISO (other than vmware tools ISO) attached, then storage live migration may not happen. Steps:- 1) Create user instance 2) Register ISO, wait till it is installed successfully 3) Attach registered ISO in step(2) 4) Migrate VM to another host which needs storage migration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7360) [vmware] Add host to existing cluster fails if the cluster is using Nexus 1000v as backend for atleast one traffic type.
Sateesh Chodapuneedi created CLOUDSTACK-7360: Summary: [vmware] Add host to existing cluster fails if the cluster is using Nexus 1000v as backend for atleast one traffic type. Key: CLOUDSTACK-7360 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7360 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0, 4.3.0, 4.4.0 Environment: vCenter/ESXi 5.0, Nexus 1000v 1.4 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: 4.5.0 Steps to reproduce: 1) Before creating zone, set global params vmware.use.nexus.vswitch vmware.use.dvswitch is to true. 2) Complete zone wizard 3) Using vCenter add ESXi host to a cluster, which is already being managed by CCP 4) Using CCP UI add the same host to that cluster - This fails -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7360) [vmware] Add host to existing cluster fails if the cluster is using Nexus 1000v as backend for atleast one traffic type.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100353#comment-14100353 ] Sateesh Chodapuneedi commented on CLOUDSTACK-7360: -- Following procedure to add host doesn't work if the cluster is using Nexus 1000v as backend for atleast one traffic type. 1) Add ESXi host to a VMware cluster in vCenter 2) Add host using CCP UI. Side effect of the failure is the existing cluster's record in database is being deleted as a result of handling discovery failure while adding host. This should be avoided such that a host add attempt failure should not affect the existing cluster. While adding a VMware cluster (which is using Nexus 1000v as network backend) CCP does validation of Nexus VSM's IP address it's credentials to be used by CCP later for virtual network orchestration. addCluster API does supply meta data related to VSM which is available for validation during discovery of cluster. But in case of addHost the work flow doesn't supply the VSM metadata. This missing information is resulting in failure while validating during discovery process. We need 2 changes, 1) Ensure host discovery / validation failure while adding host should not affect existing cluster in any way. 2) Skip validation of VSM metadata during host addition to cluster. It is admin's responsibility to add ESXi host to the cluster and the associated VSM correctly before trying to add it using CCP UI. [vmware] Add host to existing cluster fails if the cluster is using Nexus 1000v as backend for atleast one traffic type. Key: CLOUDSTACK-7360 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7360 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0, 4.3.0, 4.4.0 Environment: vCenter/ESXi 5.0, Nexus 1000v 1.4 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: 4.5.0 Original Estimate: 72h Remaining Estimate: 72h Steps to reproduce: 1) Before creating zone, set global params vmware.use.nexus.vswitch vmware.use.dvswitch is to true. 2) Complete zone wizard 3) Using vCenter add ESXi host to a cluster, which is already being managed by CCP 4) Using CCP UI add the same host to that cluster - This fails -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7250) [vCenter 5.5] SourceNAT,StaticNAT and Portfowrding is not working with Vmware DVS in vCenter 5.5
Sateesh Chodapuneedi created CLOUDSTACK-7250:
Summary: [vCenter 5.5] SourceNAT,StaticNAT and Portfowrding is not
working with Vmware DVS in vCenter 5.5
Key: CLOUDSTACK-7250
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7250
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: VMware
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.3.1
Environment: vCenter 5.5
CloudStack version 4.2 or later until 4.5
Reporter: Sateesh Chodapuneedi
Assignee: Sateesh Chodapuneedi
Fix For: 4.5.0
Cloudstack is unable to get the VIF information for the VR's and the IPASSOC
commands are failing.
I installed CloudStack 4.3 fresh (no upgrade).
The installation was finished without a problem.
SSVM and CPVM was created.
The first VM was created, but the following problems occurred.
-I can't ping internet site's IP address (for example google.com)
-An error occurs when I set StaticNAT or Portfowrding
The error is Failed to apply port forwarding rule
Also seeing following errors,
2014-08-05 08:42:58,086 INFO [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Executing resource IPAssocCommand:
{ipAddresses:[
{accountId:2,publicIp:10.102.196.147,sourceNat:true,add:true,oneToOneNat:false,firstIP:true,vlanId:100,vlanGateway:10.102.196.1,vlanNetmask:255.255.255.0,vifMacAddress:06:a5:a8:00:00:13,networkRate:200,trafficType:Public,networkName:dvSwitch0,,vmwaredvs}
],accessDetails:
{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:10.102.194.139,router.name:r-4-VM}
,wait:0}
2014-08-05 08:42:58,108 DEBUG [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Use router's private IP for SSH control. IP :
10.102.194.139
2014-08-05 08:42:58,108 DEBUG [vmware.mo.HostMO] (DirectAgent-366:10.102.192.3)
find VM r-4-VM on host
2014-08-05 08:42:58,109 INFO [vmware.mo.HostMO] (DirectAgent-366:10.102.192.3)
VM r-4-VM not found in host cache
2014-08-05 08:42:58,109 DEBUG [vmware.mo.HostMO] (DirectAgent-366:10.102.192.3)
load VM cache on host
2014-08-05 08:42:58,151 DEBUG [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Find public NIC index, public network name:
cloud.public.100, index: -1
2014-08-05 08:42:58,151 DEBUG [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Plug new NIC to associate10.102.194.139 to
10.102.196.147
2014-08-05 08:42:58,199 INFO [vmware.mo.HypervisorHostHelper]
(DirectAgent-366:10.102.192.3) Found distributed vSwitch
com.vmware.vim25.ManagedObjectReference@1d30d21
2014-08-05 08:42:58,210 INFO [vmware.mo.HypervisorHostHelper]
(DirectAgent-366:10.102.192.3) Found Distributed Virtual Port group
cloud.public.100.0.1-dvSwitch0
2014-08-05 08:42:58,233 INFO [vmware.mo.HypervisorHostHelper]
(DirectAgent-366:10.102.192.3) Updating Distributed Virtual Port group
cloud.public.100.0.1-dvSwitch0
2014-08-05 08:42:58,482 DEBUG [vmware.mo.HypervisorHostHelper]
(DirectAgent-366:10.102.192.3) Added custom field : cloud.gc.dvp
2014-08-05 08:42:59,272 DEBUG [cloud.api.ApiServlet]
(20680265@qtp-27965857-15:null) ===START=== 10.140.6.50 – GET
command=queryAsyncJobResultjobId=4434d615-986a-41de-9813-65b2a10e4ea0response=jsonsessionkey=Irg0Tdoo%2Fb0rwRJrBDaHLjdhIXo%3D_=1407228207738
2014-08-05 08:42:59,306 DEBUG [cloud.api.ApiServlet]
(20680265@qtp-27965857-15:null) ===END=== 10.140.6.50 – GET
command=queryAsyncJobResultjobId=4434d615-986a-41de-9813-65b2a10e4ea0response=jsonsessionkey=Irg0Tdoo%2Fb0rwRJrBDaHLjdhIXo%3D_=1407228207738
2014-08-05 08:42:59,317 ERROR [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Failed to find DomR VIF to
associate/disassociate IP with.
2014-08-05 08:42:59,318 ERROR [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Unexpected exception:
com.cloud.exception.InternalErrorException: Failed to find DomR VIF to
associate/disassociate IP with. will shortcut rest of IPAssoc commands
com.cloud.exception.InternalErrorException: Failed to find DomR VIF to
associate/disassociate IP with.
at
com.cloud.hypervisor.vmware.resource.VmwareResource.assignPublicIpAddress(VmwareResource.java:1877)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2059)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:427)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
at
[jira] [Resolved] (CLOUDSTACK-7250) [vCenter 5.5] SourceNAT,StaticNAT and Portfowrding is not working with Vmware DVS in vCenter 5.5
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi resolved CLOUDSTACK-7250.
--
Resolution: Fixed
[vCenter 5.5] SourceNAT,StaticNAT and Portfowrding is not working with Vmware
DVS in vCenter 5.5
Key: CLOUDSTACK-7250
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7250
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: VMware
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.3.1
Environment: vCenter 5.5
CloudStack version 4.2 or later until 4.5
Reporter: Sateesh Chodapuneedi
Assignee: Sateesh Chodapuneedi
Fix For: 4.5.0
Cloudstack is unable to get the VIF information for the VR's and the IPASSOC
commands are failing.
I installed CloudStack 4.3 fresh (no upgrade).
The installation was finished without a problem.
SSVM and CPVM was created.
The first VM was created, but the following problems occurred.
-I can't ping internet site's IP address (for example google.com)
-An error occurs when I set StaticNAT or Portfowrding
The error is Failed to apply port forwarding rule
Also seeing following errors,
2014-08-05 08:42:58,086 INFO [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Executing resource IPAssocCommand:
{ipAddresses:[
{accountId:2,publicIp:10.102.196.147,sourceNat:true,add:true,oneToOneNat:false,firstIP:true,vlanId:100,vlanGateway:10.102.196.1,vlanNetmask:255.255.255.0,vifMacAddress:06:a5:a8:00:00:13,networkRate:200,trafficType:Public,networkName:dvSwitch0,,vmwaredvs}
],accessDetails:
{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:10.102.194.139,router.name:r-4-VM}
,wait:0}
2014-08-05 08:42:58,108 DEBUG [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Use router's private IP for SSH control. IP :
10.102.194.139
2014-08-05 08:42:58,108 DEBUG [vmware.mo.HostMO]
(DirectAgent-366:10.102.192.3) find VM r-4-VM on host
2014-08-05 08:42:58,109 INFO [vmware.mo.HostMO]
(DirectAgent-366:10.102.192.3) VM r-4-VM not found in host cache
2014-08-05 08:42:58,109 DEBUG [vmware.mo.HostMO]
(DirectAgent-366:10.102.192.3) load VM cache on host
2014-08-05 08:42:58,151 DEBUG [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Find public NIC index, public network name:
cloud.public.100, index: -1
2014-08-05 08:42:58,151 DEBUG [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Plug new NIC to associate10.102.194.139 to
10.102.196.147
2014-08-05 08:42:58,199 INFO [vmware.mo.HypervisorHostHelper]
(DirectAgent-366:10.102.192.3) Found distributed vSwitch
com.vmware.vim25.ManagedObjectReference@1d30d21
2014-08-05 08:42:58,210 INFO [vmware.mo.HypervisorHostHelper]
(DirectAgent-366:10.102.192.3) Found Distributed Virtual Port group
cloud.public.100.0.1-dvSwitch0
2014-08-05 08:42:58,233 INFO [vmware.mo.HypervisorHostHelper]
(DirectAgent-366:10.102.192.3) Updating Distributed Virtual Port group
cloud.public.100.0.1-dvSwitch0
2014-08-05 08:42:58,482 DEBUG [vmware.mo.HypervisorHostHelper]
(DirectAgent-366:10.102.192.3) Added custom field : cloud.gc.dvp
2014-08-05 08:42:59,272 DEBUG [cloud.api.ApiServlet]
(20680265@qtp-27965857-15:null) ===START=== 10.140.6.50 – GET
command=queryAsyncJobResultjobId=4434d615-986a-41de-9813-65b2a10e4ea0response=jsonsessionkey=Irg0Tdoo%2Fb0rwRJrBDaHLjdhIXo%3D_=1407228207738
2014-08-05 08:42:59,306 DEBUG [cloud.api.ApiServlet]
(20680265@qtp-27965857-15:null) ===END=== 10.140.6.50 – GET
command=queryAsyncJobResultjobId=4434d615-986a-41de-9813-65b2a10e4ea0response=jsonsessionkey=Irg0Tdoo%2Fb0rwRJrBDaHLjdhIXo%3D_=1407228207738
2014-08-05 08:42:59,317 ERROR [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Failed to find DomR VIF to
associate/disassociate IP with.
2014-08-05 08:42:59,318 ERROR [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Unexpected exception:
com.cloud.exception.InternalErrorException: Failed to find DomR VIF to
associate/disassociate IP with. will shortcut rest of IPAssoc commands
com.cloud.exception.InternalErrorException: Failed to find DomR VIF to
associate/disassociate IP with.
at
com.cloud.hypervisor.vmware.resource.VmwareResource.assignPublicIpAddress(VmwareResource.java:1877)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2059)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:427)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
[jira] [Commented] (CLOUDSTACK-7250) [vCenter 5.5] SourceNAT,StaticNAT and Portfowrding is not working with Vmware DVS in vCenter 5.5
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14086075#comment-14086075
]
Sateesh Chodapuneedi commented on CLOUDSTACK-7250:
--
CLOUDSTACK-7250 [vCenter 5.5] SourceNAT,StaticNAT and Portfowrding is not
working with Vmware DVS in vCenter 5.5
Change in vCenter 5.5 API from prior versions forced code change in CloudStack.
Update property value of property VirtualE1000.deviceInfo.summary is
accommodated now.
Signed-off-by: Sateesh Chodapuneedi sate...@apache.org
Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/dfa607fb
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/dfa607fb
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/dfa607fb
Branch: refs/heads/master
Commit: dfa607fb443cbd0c3f2c264c2abfa9f1844a16ce
Parents: cc725e5
Author: Sateesh Chodapuneedi sate...@apache.org
Authored: Tue Aug 5 10:00:00 2014 +0530
Committer: Sateesh Chodapuneedi sate...@apache.org
Committed: Tue Aug 5 10:00:00 2014 +0530
[vCenter 5.5] SourceNAT,StaticNAT and Portfowrding is not working with Vmware
DVS in vCenter 5.5
Key: CLOUDSTACK-7250
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7250
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: VMware
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.3.1
Environment: vCenter 5.5
CloudStack version 4.2 or later until 4.5
Reporter: Sateesh Chodapuneedi
Assignee: Sateesh Chodapuneedi
Fix For: 4.5.0
Cloudstack is unable to get the VIF information for the VR's and the IPASSOC
commands are failing.
I installed CloudStack 4.3 fresh (no upgrade).
The installation was finished without a problem.
SSVM and CPVM was created.
The first VM was created, but the following problems occurred.
-I can't ping internet site's IP address (for example google.com)
-An error occurs when I set StaticNAT or Portfowrding
The error is Failed to apply port forwarding rule
Also seeing following errors,
2014-08-05 08:42:58,086 INFO [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Executing resource IPAssocCommand:
{ipAddresses:[
{accountId:2,publicIp:10.102.196.147,sourceNat:true,add:true,oneToOneNat:false,firstIP:true,vlanId:100,vlanGateway:10.102.196.1,vlanNetmask:255.255.255.0,vifMacAddress:06:a5:a8:00:00:13,networkRate:200,trafficType:Public,networkName:dvSwitch0,,vmwaredvs}
],accessDetails:
{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:10.102.194.139,router.name:r-4-VM}
,wait:0}
2014-08-05 08:42:58,108 DEBUG [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Use router's private IP for SSH control. IP :
10.102.194.139
2014-08-05 08:42:58,108 DEBUG [vmware.mo.HostMO]
(DirectAgent-366:10.102.192.3) find VM r-4-VM on host
2014-08-05 08:42:58,109 INFO [vmware.mo.HostMO]
(DirectAgent-366:10.102.192.3) VM r-4-VM not found in host cache
2014-08-05 08:42:58,109 DEBUG [vmware.mo.HostMO]
(DirectAgent-366:10.102.192.3) load VM cache on host
2014-08-05 08:42:58,151 DEBUG [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Find public NIC index, public network name:
cloud.public.100, index: -1
2014-08-05 08:42:58,151 DEBUG [vmware.resource.VmwareResource]
(DirectAgent-366:10.102.192.3) Plug new NIC to associate10.102.194.139 to
10.102.196.147
2014-08-05 08:42:58,199 INFO [vmware.mo.HypervisorHostHelper]
(DirectAgent-366:10.102.192.3) Found distributed vSwitch
com.vmware.vim25.ManagedObjectReference@1d30d21
2014-08-05 08:42:58,210 INFO [vmware.mo.HypervisorHostHelper]
(DirectAgent-366:10.102.192.3) Found Distributed Virtual Port group
cloud.public.100.0.1-dvSwitch0
2014-08-05 08:42:58,233 INFO [vmware.mo.HypervisorHostHelper]
(DirectAgent-366:10.102.192.3) Updating Distributed Virtual Port group
cloud.public.100.0.1-dvSwitch0
2014-08-05 08:42:58,482 DEBUG [vmware.mo.HypervisorHostHelper]
(DirectAgent-366:10.102.192.3) Added custom field : cloud.gc.dvp
2014-08-05 08:42:59,272 DEBUG [cloud.api.ApiServlet]
(20680265@qtp-27965857-15:null) ===START=== 10.140.6.50 – GET
command=queryAsyncJobResultjobId=4434d615-986a-41de-9813-65b2a10e4ea0response=jsonsessionkey=Irg0Tdoo%2Fb0rwRJrBDaHLjdhIXo%3D_=1407228207738
2014-08-05 08:42:59,306 DEBUG [cloud.api.ApiServlet]
(20680265@qtp-27965857-15:null) ===END=== 10.140.6.50 – GET
command=queryAsyncJobResultjobId=4434d615-986a-41de-9813-65b2a10e4ea0response=jsonsessionkey=Irg0Tdoo%2Fb0rwRJrBDaHLjdhIXo%3D_=1407228207738
2014-08-05 08:42:59,317 ERROR [vmware.resource.VmwareResource]
[jira] [Updated] (CLOUDSTACK-7078) CLONE - [VMWARE]System VM's are failed to start with Nexus enabled Zone
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-7078:
-
Fix Version/s: (was: 4.4.0)
CLONE - [VMWARE]System VM's are failed to start with Nexus enabled Zone
Key: CLOUDSTACK-7078
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7078
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Devices, VMware
Affects Versions: 4.4.0
Reporter: Sateesh Chodapuneedi
Assignee: Sateesh Chodapuneedi
Priority: Critical
Fix For: 4.5.0
Attachments: issuenexus.rar
Steps:
1. Upgraded from 3.0.7 to 4.2 ( VMWARE Zone with Standard vSwitch)
2. Enable Nexus global config variable
3. Tried to add new Zone with VMWARE Nexus enabled
4. Added two physical networks ( 1 - Mgmt - vSwitch0,,vmwaresvs 2- Public
guest - sailajanewpp,,nexusdvs)
5. Provided VSM details while adding cluster
Observation:
System VM's are failed to start with Nexus enabled Zone saying Nexus details
can not be retrieved from DB.
2013-08-22 00:37:01,732 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
===START=== 10.101.255.30 -- GET
command=queryAsyncJobResultjobId=921f4c19-a655-4234-82c4-66efcbe73933response=jsonsessionkey=CNY1grUrySJwTE%2BpFM3btn1i4Xs%3D_=1377112271133
2013-08-22 00:37:01,782 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
===END=== 10.101.255.30 -- GET
command=queryAsyncJobResultjobId=921f4c19-a655-4234-82c4-66efcbe73933response=jsonsessionkey=CNY1grUrySJwTE%2BpFM3btn1i4Xs%3D_=1377112271133
2013-08-22 00:37:02,170 WARN [vmware.resource.VmwareResource]
(DirectAgent-128:10.102.192.18) StartCommand failed due to Exception:
java.lang.Exception
Message: Failed to retrieve required credentials of Nexus VSM from database.
java.lang.Exception: Failed to retrieve required credentials of Nexus VSM
from database.
at
com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.getValidatedVsmCredentials(HypervisorHostHelper.java:183)
at
com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.createPortProfile(HypervisorHostHelper.java:201)
at
com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:584)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3308)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-08-22 00:37:02,196 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-128:null) Seq 14-773455885: Cancelling because one of the
answers is false and it is stop on error.
2013-08-22 00:37:02,196 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-128:null) Seq 14-773455885: Response Received:
2013-08-22 00:37:02,199 DEBUG [agent.transport.Request]
(DirectAgent-128:null) Seq 14-773455885: Processing: { Ans: , MgmtId:
187767034175903, via: 14, Ver: v1, Flags: 10,
[{com.cloud.agent.api.StartAnswer:{vm:{id:30,name:s-30-VM,bootloader:HVM,type:SecondaryStorageVm,cpus:1,minSpeed:500,maxSpeed:500,minRam:268435456,maxRam:268435456,hostName:s-30-VM,arch:x86_64,os:Debian
GNU/Linux 5.0 (32-bit),bootArgs: template=domP type=secstorage
host=10.102.192.207 port=8250 name=s-30-VM zone=3 pod=3 guid=s-30-VM
resource=com.cloud.storage.resource.PremiumSecondaryStorageResource
instance=SecStorage sslcopy=true role=templateProcessor mtu=1500
eth2ip=10.102.196.220 eth2mask=255.255.255.0 gateway=10.102.196.1
public.network.device=eth2 eth0mask=0.0.0.0 eth0ip=0.0.0.0
eth1ip=10.102.195.150 eth1mask=255.255.252.0 mgmtcidr=10.102.192.0/22
localgw=10.102.192.1 private.network.device=eth1 eth3ip=10.102.195.152
eth3mask=255.255.252.0
[jira] [Resolved] (CLOUDSTACK-7078) CLONE - [VMWARE]System VM's are failed to start with Nexus enabled Zone
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi resolved CLOUDSTACK-7078.
--
Resolution: Fixed
CLONE - [VMWARE]System VM's are failed to start with Nexus enabled Zone
Key: CLOUDSTACK-7078
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7078
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Devices, VMware
Affects Versions: 4.4.0
Reporter: Sateesh Chodapuneedi
Assignee: Sateesh Chodapuneedi
Priority: Critical
Fix For: 4.5.0
Attachments: issuenexus.rar
Steps:
1. Upgraded from 3.0.7 to 4.2 ( VMWARE Zone with Standard vSwitch)
2. Enable Nexus global config variable
3. Tried to add new Zone with VMWARE Nexus enabled
4. Added two physical networks ( 1 - Mgmt - vSwitch0,,vmwaresvs 2- Public
guest - sailajanewpp,,nexusdvs)
5. Provided VSM details while adding cluster
Observation:
System VM's are failed to start with Nexus enabled Zone saying Nexus details
can not be retrieved from DB.
2013-08-22 00:37:01,732 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
===START=== 10.101.255.30 -- GET
command=queryAsyncJobResultjobId=921f4c19-a655-4234-82c4-66efcbe73933response=jsonsessionkey=CNY1grUrySJwTE%2BpFM3btn1i4Xs%3D_=1377112271133
2013-08-22 00:37:01,782 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
===END=== 10.101.255.30 -- GET
command=queryAsyncJobResultjobId=921f4c19-a655-4234-82c4-66efcbe73933response=jsonsessionkey=CNY1grUrySJwTE%2BpFM3btn1i4Xs%3D_=1377112271133
2013-08-22 00:37:02,170 WARN [vmware.resource.VmwareResource]
(DirectAgent-128:10.102.192.18) StartCommand failed due to Exception:
java.lang.Exception
Message: Failed to retrieve required credentials of Nexus VSM from database.
java.lang.Exception: Failed to retrieve required credentials of Nexus VSM
from database.
at
com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.getValidatedVsmCredentials(HypervisorHostHelper.java:183)
at
com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.createPortProfile(HypervisorHostHelper.java:201)
at
com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:584)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3308)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-08-22 00:37:02,196 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-128:null) Seq 14-773455885: Cancelling because one of the
answers is false and it is stop on error.
2013-08-22 00:37:02,196 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-128:null) Seq 14-773455885: Response Received:
2013-08-22 00:37:02,199 DEBUG [agent.transport.Request]
(DirectAgent-128:null) Seq 14-773455885: Processing: { Ans: , MgmtId:
187767034175903, via: 14, Ver: v1, Flags: 10,
[{com.cloud.agent.api.StartAnswer:{vm:{id:30,name:s-30-VM,bootloader:HVM,type:SecondaryStorageVm,cpus:1,minSpeed:500,maxSpeed:500,minRam:268435456,maxRam:268435456,hostName:s-30-VM,arch:x86_64,os:Debian
GNU/Linux 5.0 (32-bit),bootArgs: template=domP type=secstorage
host=10.102.192.207 port=8250 name=s-30-VM zone=3 pod=3 guid=s-30-VM
resource=com.cloud.storage.resource.PremiumSecondaryStorageResource
instance=SecStorage sslcopy=true role=templateProcessor mtu=1500
eth2ip=10.102.196.220 eth2mask=255.255.255.0 gateway=10.102.196.1
public.network.device=eth2 eth0mask=0.0.0.0 eth0ip=0.0.0.0
eth1ip=10.102.195.150 eth1mask=255.255.252.0 mgmtcidr=10.102.192.0/22
localgw=10.102.192.1 private.network.device=eth1 eth3ip=10.102.195.152
eth3mask=255.255.252.0 storageip=10.102.195.152
[jira] [Commented] (CLOUDSTACK-7151) vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14069886#comment-14069886 ] Sateesh Chodapuneedi commented on CLOUDSTACK-7151: -- Commit 7c4831df9292115466fb9e01fcba952a5dad31c changes logic to pick vswitch type from zone level physical traffic label ignoring the vmware traffic label information persisted per cluster. This breaks existing functionality to support a choice of vswitch type on cluster basis, which was introduced in 4.2. In 4.2, CloudStack allows admins to, 1) Choose zone level vswitch name/type through physical network traffic label. 2) Choose specific cluster level vswitch name/type through optional parameters to addCluster API and through add cluster wizard UI where user is given a list box to choose type of vSwitch and name of vSwitch. These details would be persisted to database for further reference while implementing virtual networks in any of the hosts in that cluster. This option of specific cluster level choice would help users who have a zone where some legacy clusters were based on vSwitch and they want to move to advance switch options for their guest/public traffic like vmware dvSwitch or Cisco Nexus 1000v for their remaining clusters. This option also protects existing virtual network implemented on a particular type of vswitch from modification of physical network traffic label to accommodate/flip to other type of vswitch if user want to move to another type of vswitch in this zone. Due to changes done in 4.3 () existing customers who have chosen option (2) above will see this bug. Because in 4.2 CloudStack honours the cluster level vswitch type/name settings but in 4.3 we defaulted only to zone level physical network traffic label unless the zone level traffic label itself is defined. vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks Key: CLOUDSTACK-7151 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7151 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0, 4.3.1 Environment: VMware ESXi 5.0 ACS 4.3.0 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Priority: Blocker Fix For: 4.5.0 After upgrade to 4.3.0 from 4.2.0 system vms are not able to start. 2014-07-18 07:14:16,732 INFO [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Prepare network on vmwaresvs Public_Guest_Net with name prefix: cloud.public 2014-07-18 07:14:16,778 ERROR [c.c.h.v.m.HypervisorHostHelper] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Unable to find vSwitchPublic_Guest_Net 2014-07-18 07:14:16,778 WARN [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) StartCommand failed due to Exception: java.lang.Exception Message: Unable to find vSwitchPublic_Guest_Net -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CLOUDSTACK-7151) vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14069886#comment-14069886 ] Sateesh Chodapuneedi edited comment on CLOUDSTACK-7151 at 7/22/14 6:17 AM: --- Commit 7c4831df9292115466fb9e01fcba952a5dad31c changes logic to pick vswitch type from zone level physical traffic label ignoring the vmware traffic label information persisted per cluster. This breaks existing functionality to support a choice of vswitch type on cluster basis, which was introduced in 4.2. In 4.2, CloudStack allows admins to, 1) Choose zone level vswitch name/type through physical network traffic label. 2) Choose specific cluster level vswitch name/type through optional parameters to addCluster API and through add cluster wizard UI where user is given a list box to choose type of vSwitch and name of vSwitch. These details would be persisted to database for further reference while implementing virtual networks in any of the hosts in that cluster. This option of specific cluster level choice would help users who have a zone where some legacy clusters were based on vSwitch and they want to move to advance switch options for their guest/public traffic like vmware dvSwitch or Cisco Nexus 1000v for their remaining clusters. This option also protects existing virtual network implemented on a particular type of vswitch from modification of physical network traffic label to accommodate/flip to other type of vswitch if user want to move to another type of vswitch in this zone. Due to changes done in 4.3 (7c4831df9292115466fb9e01fcba952a5dad31c ) existing customers who have chosen option (2) above in 4.2 deployment and upgraded to 4.3 will see this bug. Because in 4.2 CloudStack honours the cluster level vswitch type/name settings but in 4.3 we defaulted only to zone level physical network traffic label unless the zone level traffic label itself is defined. was (Author: sateeshc): Commit 7c4831df9292115466fb9e01fcba952a5dad31c changes logic to pick vswitch type from zone level physical traffic label ignoring the vmware traffic label information persisted per cluster. This breaks existing functionality to support a choice of vswitch type on cluster basis, which was introduced in 4.2. In 4.2, CloudStack allows admins to, 1) Choose zone level vswitch name/type through physical network traffic label. 2) Choose specific cluster level vswitch name/type through optional parameters to addCluster API and through add cluster wizard UI where user is given a list box to choose type of vSwitch and name of vSwitch. These details would be persisted to database for further reference while implementing virtual networks in any of the hosts in that cluster. This option of specific cluster level choice would help users who have a zone where some legacy clusters were based on vSwitch and they want to move to advance switch options for their guest/public traffic like vmware dvSwitch or Cisco Nexus 1000v for their remaining clusters. This option also protects existing virtual network implemented on a particular type of vswitch from modification of physical network traffic label to accommodate/flip to other type of vswitch if user want to move to another type of vswitch in this zone. Due to changes done in 4.3 () existing customers who have chosen option (2) above will see this bug. Because in 4.2 CloudStack honours the cluster level vswitch type/name settings but in 4.3 we defaulted only to zone level physical network traffic label unless the zone level traffic label itself is defined. vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks Key: CLOUDSTACK-7151 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7151 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0, 4.3.1 Environment: VMware ESXi 5.0 ACS 4.3.0 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Priority: Blocker Fix For: 4.5.0 After upgrade to 4.3.0 from 4.2.0 system vms are not able to start. 2014-07-18 07:14:16,732 INFO [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Prepare network on vmwaresvs Public_Guest_Net with name prefix: cloud.public 2014-07-18 07:14:16,778 ERROR [c.c.h.v.m.HypervisorHostHelper] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Unable to find vSwitchPublic_Guest_Net 2014-07-18 07:14:16,778 WARN [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net)
[jira] [Updated] (CLOUDSTACK-3968) [VMWAREDVS] Distributed Portgroups are not deleted when guest networks are removed/User Account of this network is removed from cloudstack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-3968: - Fix Version/s: (was: 4.4.0) Future [VMWAREDVS] Distributed Portgroups are not deleted when guest networks are removed/User Account of this network is removed from cloudstack -- Key: CLOUDSTACK-3968 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3968 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Reporter: Sailaja Mada Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: Future Attachments: dvswitchsnap.png Setup: VMWARE with DVSwitch 1. Configure Adv Zone with DVSwitch enabled VMWARE cluster 2. Create an account and deploy VM using default offering guest network. 3. Delete this account. With this all the resources of this account gets removed from cloudstack Observation: But from vCenter dv Switch, the distributed port groups configured for this account guest networks will not get removed. Expected results: All the configurations created by cloudstack should get cleaned up as part of smooth removal. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-4593) [VMWARE] [Upgrade]Livestorage Migration VM Snapshot features are not fully functional after upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14070057#comment-14070057 ] Sateesh Chodapuneedi commented on CLOUDSTACK-4593: -- This is involved change and is critical path at kernel of storage in vmware hypervisor. We have work around that vm (which was created before upgrade) to be stopped and started once to avoid this issue. As we have work around reducing priority to major. [VMWARE] [Upgrade]Livestorage Migration VM Snapshot features are not fully functional after upgrade -- Key: CLOUDSTACK-4593 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4593 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller, Upgrade, VMware Affects Versions: 4.2.1 Reporter: Sailaja Mada Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: 4.4.0 Attachments: apilogs.rar, clouddbback.dmp, mgmtlogs.rar Steps: Upgraded setup : 307 Setup with 2 clusters ( Cluster1 – 2 ESXi 5.0 hosts , Cluster2 – Esxi 4.1 host) 1.11 Vm’s deployed with 2 VM’s in stopped state 2.VM’s with ROOT volume, 2 DATA volumes, 3 DATA volumes 3.Snapshots , Template / volumes from this snapshot 4.Detached volumes 5.Empty volumes which are not attached to any instance 6.Cluster with 2 primary storage's Upgraded to 4.2 I got into below failures with VM Snapshot if tried without Stop/Start of the VM Post upgrade : 2013-09-02 21:35:36,733 WARN [vmware.resource.VmwareResource] (DirectAgent-320:10.102.192.23) StartCommand failed due to Exception: java.lang.RuntimeException Message: File unspecified filename was not found java.lang.RuntimeException: File unspecified filename was not found at com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:378) at com.cloud.hypervisor.vmware.mo.VirtualMachineMO.powerOn(VirtualMachineMO.java:188) at com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2966) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:519) at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2013-09-02 21:35:36,742 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-320:null) Seq 6-949618439: Response Received: 2013-09-02 21:35:43,972 INFO [storage.volume.VolumeServiceImpl] (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) Volume 52 is not referred anywhere, remove it from volumes table 2013-09-02 21:35:43,981 ERROR [cloud.storage.VolumeManagerImpl] (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) migrate volume failed:copy volume from primary to secondary failed due to exception: Exception: java.lang.Exception Message: Unable to find related disk device for volume. volume path: ROOT-14-30-04 2013-09-02 21:35:43,990 INFO [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) Unable to contact resource. com.cloud.exception.StorageUnavailableException: Resource [StoragePool:203] is unreachable: migrate volume failed: copy volume from primary to secondary failed due to exception: Exception: java.lang.Exception Message: Unable to find related disk device for volume. volume path: ROOT-14-30-04 at com.cloud.storage.VolumeManagerImpl.migrateVolume(VolumeManagerImpl.java:2254) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2590) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:888) at
[jira] [Updated] (CLOUDSTACK-4593) [VMWARE] [Upgrade]Livestorage Migration VM Snapshot features are not fully functional after upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-4593: - Priority: Major (was: Critical) [VMWARE] [Upgrade]Livestorage Migration VM Snapshot features are not fully functional after upgrade -- Key: CLOUDSTACK-4593 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4593 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller, Upgrade, VMware Affects Versions: 4.2.1 Reporter: Sailaja Mada Assignee: Sateesh Chodapuneedi Fix For: 4.4.0 Attachments: apilogs.rar, clouddbback.dmp, mgmtlogs.rar Steps: Upgraded setup : 307 Setup with 2 clusters ( Cluster1 – 2 ESXi 5.0 hosts , Cluster2 – Esxi 4.1 host) 1.11 Vm’s deployed with 2 VM’s in stopped state 2.VM’s with ROOT volume, 2 DATA volumes, 3 DATA volumes 3.Snapshots , Template / volumes from this snapshot 4.Detached volumes 5.Empty volumes which are not attached to any instance 6.Cluster with 2 primary storage's Upgraded to 4.2 I got into below failures with VM Snapshot if tried without Stop/Start of the VM Post upgrade : 2013-09-02 21:35:36,733 WARN [vmware.resource.VmwareResource] (DirectAgent-320:10.102.192.23) StartCommand failed due to Exception: java.lang.RuntimeException Message: File unspecified filename was not found java.lang.RuntimeException: File unspecified filename was not found at com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:378) at com.cloud.hypervisor.vmware.mo.VirtualMachineMO.powerOn(VirtualMachineMO.java:188) at com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2966) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:519) at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2013-09-02 21:35:36,742 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-320:null) Seq 6-949618439: Response Received: 2013-09-02 21:35:43,972 INFO [storage.volume.VolumeServiceImpl] (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) Volume 52 is not referred anywhere, remove it from volumes table 2013-09-02 21:35:43,981 ERROR [cloud.storage.VolumeManagerImpl] (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) migrate volume failed:copy volume from primary to secondary failed due to exception: Exception: java.lang.Exception Message: Unable to find related disk device for volume. volume path: ROOT-14-30-04 2013-09-02 21:35:43,990 INFO [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) Unable to contact resource. com.cloud.exception.StorageUnavailableException: Resource [StoragePool:203] is unreachable: migrate volume failed: copy volume from primary to secondary failed due to exception: Exception: java.lang.Exception Message: Unable to find related disk device for volume. volume path: ROOT-14-30-04 at com.cloud.storage.VolumeManagerImpl.migrateVolume(VolumeManagerImpl.java:2254) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2590) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:888) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:237) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at
[jira] [Resolved] (CLOUDSTACK-5012) Bad data inserted into physical network labels for Zone Create Wizard using VMWare
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi resolved CLOUDSTACK-5012. -- Resolution: Duplicate Bad data inserted into physical network labels for Zone Create Wizard using VMWare -- Key: CLOUDSTACK-5012 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5012 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Jim Leary Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: 4.4.0 When using the Zone create wizard and choosing VMWare, the physical network labels contain additional data, rendering any attempt to create a VMWare cluster unsuccessful. The Zone wizard must be cancelled and the physical network labels corrected, then manually create the cluster, primary and secondary storage for the Zone to function correctly. -- This message was sent by Atlassian JIRA (v6.2#6252)
