[jira] [Commented] (CLOUDSTACK-4855) Throttle based on the # of outstanding requests to the directly managed HV host (direct agents)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812699#comment-13812699 ] ASF subversion and git services commented on CLOUDSTACK-4855: - Commit 269a4ef11ee151fa408a7dd1f2e69cd1f7f05191 in branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=269a4ef ] CLOUDSTACK-4855: Throttle based on the # of outstanding requests to the directly managed HV host (direct agents) Cloudstack sends requests to directly managed HV hosts (direct agents) using the direct agent thread pool. The size of the pool is determined by global config direct.agent.pool.size defaulted to 500. Currently there is no restriction on the number of threads a direct agent can use from this shared thread pool to send requests to the host. This is fine as long as the host is responding to requests in a reasonable amount of time. But if there is a considerable delay in getting response, the thread remain blocked for that much time. As more commands are send to the slow host threads keep getting blocked. This can eventually lead to a situation where requests to healthy hosts cannot be processed as there are not enough free threads. The problem being addressed here is to localize the impact of few bad hosts, so that entire management server is not affected. One such way is to throttle based on the # of outstanding requests on per host basis. The outstanding requests to a host will be a % of direct agent pool size. This is configurable based on direct.agent.thread.cap. The default value is 0.1 or 10%, a value of 1 would mean the old behavior where there is no upper cap. This will ensure that the impacted host will be bound by a upper cap on the number of threads it can use to process requests and not the entire pool. Throttle based on the # of outstanding requests to the directly managed HV host (direct agents) --- Key: CLOUDSTACK-4855 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4855 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: pre-4.0.0, 4.1.0, 4.2.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.3.0 Currently requests to all direct managed HV hosts (direct agents) are handled by the direct agent thread pool. The size of the pool is determined by global config direct.agent.pool.size defaulted to 500. Currently there is no restriction on the number of requests that can be sent to a given HV host. The down side is if a lot commands are getting generated for some specific hosts (may be there is some issue with the host, the host is slow in responding and there is a pile up of outstanding requests), it may essentially starve the requests going to other hosts due to unavailability of direct agent threads as most of them will be serving a very few hosts. The problem being addressed is that a few bad hosts should not affect the entire management server. The solution is to localize the impact of the bad hosts. One such way is to throttle based on the # of outstanding requests on per host basis. The outstanding requests will be a % of the direct agent pool size. This will ensure that the impacted host will be bound by a upper cap on the number of threads it can use to process request and not the entire pool. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4855) Throttle based on the # of outstanding requests to the directly managed HV host (direct agents)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das resolved CLOUDSTACK-4855. - Resolution: Fixed Throttle based on the # of outstanding requests to the directly managed HV host (direct agents) --- Key: CLOUDSTACK-4855 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4855 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: pre-4.0.0, 4.1.0, 4.2.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.3.0 Currently requests to all direct managed HV hosts (direct agents) are handled by the direct agent thread pool. The size of the pool is determined by global config direct.agent.pool.size defaulted to 500. Currently there is no restriction on the number of requests that can be sent to a given HV host. The down side is if a lot commands are getting generated for some specific hosts (may be there is some issue with the host, the host is slow in responding and there is a pile up of outstanding requests), it may essentially starve the requests going to other hosts due to unavailability of direct agent threads as most of them will be serving a very few hosts. The problem being addressed is that a few bad hosts should not affect the entire management server. The solution is to localize the impact of the bad hosts. One such way is to throttle based on the # of outstanding requests on per host basis. The outstanding requests will be a % of the direct agent pool size. This will ensure that the impacted host will be bound by a upper cap on the number of threads it can use to process request and not the entire pool. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5016) Failed to reboot the VM which has VM Snapshots and Migrated Volumes
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ram Ganesh updated CLOUDSTACK-5016:
---
Assignee: Likitha Shetty
Failed to reboot the VM which has VM Snapshots and Migrated Volumes
---
Key: CLOUDSTACK-5016
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5016
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.1
Reporter: Sailaja Mada
Assignee: Likitha Shetty
Priority: Critical
Fix For: 4.2.1
Attachments: logsall.rar, startvm.png
Steps:
1. Configure Adv Zone with 2 zone wide primary storages using VMWARE 5.0
update2 Hypervisor
2. Deploy VM using user account
3. Create 2 VMsnapshots wo memory and 1 VM snapshot with Memory
4. Revert to VM Snap2 then to VM Snap1
5. Stop the VM and Migrate the Volume to second Primary Storage
7. Start the VM - It got started.
8. Tried to reboot the VM.
Observation:
It failed to start the VM .
2013-10-31 20:17:28,495 WARN [storage.resource.VmwareStorageLayoutHelper]
(DirectAgent-289:10.102.192.18) Unable to locate VMDK file:
a933eb3fa28a473ab5e28b99f5f2607e-delta.vmdk
2013-10-31 20:17:28,496 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-289:null) Seq 9-894174187: Response Received:
2013-10-31 20:17:28,497 DEBUG [agent.transport.Request]
(DirectAgent-289:null) Seq 9-894174187: Processing: { Ans: , MgmtId:
94838926819810, via: 9, Ver: v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:true,details:Success,wait:0}}]
}
2013-10-31 20:17:28,497 DEBUG [agent.transport.Request]
(Job-Executor-5:job-143 = [ 57e484cb-c0aa-47c8-b991-1aa7aed9b038 ]) Seq
9-894174187: Received: { Ans: , MgmtId: 94838926819810, via: 9, Ver: v1,
Flags: 10, { Answer } }
2013-10-31 20:17:28,507 INFO [storage.volume.VolumeServiceImpl]
(Job-Executor-5:job-143 = [ 57e484cb-c0aa-47c8-b991-1aa7aed9b038 ]) Volume 39
is not referred anywhere, remove it from volumes table
2013-10-31 20:17:28,513 ERROR [cloud.storage.VolumeManagerImpl]
(Job-Executor-5:job-143 = [ 57e484cb-c0aa-47c8-b991-1aa7aed9b038 ]) migrate
volume failed:copy volume from primary to secondary failed due to exception:
Exception: java.lang.RuntimeException
Message: File [7f18caf5397a340a934ed37c558aee2b] i-5-24-VM/i-5-24-VM.vmx was
not found
2013-10-31 20:17:28,519 INFO [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-5:job-143 = [ 57e484cb-c0aa-47c8-b991-1aa7aed9b038 ]) Unable to
contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:5] is
unreachable: migrate volume failed: copy volume from primary to secondary
failed due to exception: Exception: java.lang.RuntimeException
Message: File [7f18caf5397a340a934ed37c558aee2b] i-5-24-VM/i-5-24-VM.vmx was
not found
2013-10-31 20:17:28,519 INFO [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-5:job-143 = [ 57e484cb-c0aa-47c8-b991-1aa7aed9b038 ]) Unable to
contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:5] is
unreachable: migrate volume failed: copy volume from primary to secondary
failed due to exception: Exception: java.lang.RuntimeException
Message: File [7f18caf5397a340a934ed37c558aee2b] i-5-24-VM/i-5-24-VM.vmx was
not found
at
com.cloud.storage.VolumeManagerImpl.migrateVolume(VolumeManagerImpl.java:2278)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2629)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:888)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:577)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:570)
at
com.cloud.vm.UserVmManagerImpl.restoreVMInternal(UserVmManagerImpl.java:4930)
at
com.cloud.vm.UserVmManagerImpl.rebootVirtualMachine(UserVmManagerImpl.java:1971)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
org.apache.cloudstack.api.command.user.vm.RebootVMCmd.execute(RebootVMCmd.java:99)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
[jira] [Updated] (CLOUDSTACK-5027) [VMWARE] Failed to Deploy instance when primary storage of a different zone are in maintenance mode
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ram Ganesh updated CLOUDSTACK-5027:
---
Assignee: Sateesh Chodapuneedi
[VMWARE] Failed to Deploy instance when primary storage of a different zone
are in maintenance mode
---
Key: CLOUDSTACK-5027
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5027
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.1
Reporter: Sailaja Mada
Assignee: Sateesh Chodapuneedi
Priority: Critical
Fix For: 4.2.1
Attachments: failureloigs.rar
Steps:
1. Configure 2 vMWARE zones each with Zone wide primary storages
2. Moved Zone 1 primary storages into maintenance mode
3. Tried to deploy VM on second VMWARE zone which has Primary storage up
state.
Observation:
[VMWARE] Failed to Deploy instance when primary storage of a different zone
are in maintenance mode
2013-11-03 10:21:07,088 DEBUG [cloud.storage.VolumeManagerImpl]
(Job-Executor-17:job-155 = [ d4cadcb1-7e06-4ee2-9d08-0585964fc934 ]) Checking
if we need to prepare 1 volumes for VM[DomainRouter|r-30-VM]
2013-11-03 10:21:07,099 DEBUG [storage.image.TemplateDataFactoryImpl]
(Job-Executor-17:job-155 = [ d4cadcb1-7e06-4ee2-9d08-0585964fc934 ]) template
8 is already in store:1, type:Image
2013-11-03 10:21:07,104 DEBUG [storage.datastore.PrimaryDataStoreImpl]
(Job-Executor-17:job-155 = [ d4cadcb1-7e06-4ee2-9d08-0585964fc934 ]) Not
found (templateId:8poolId:6) in template_spool_ref, persisting it
2013-11-03 10:21:07,121 DEBUG [storage.image.TemplateDataFactoryImpl]
(Job-Executor-17:job-155 = [ d4cadcb1-7e06-4ee2-9d08-0585964fc934 ]) template
8 is already in store:6, type:Primary
2013-11-03 10:21:07,123 DEBUG [storage.volume.VolumeServiceImpl]
(Job-Executor-17:job-155 = [ d4cadcb1-7e06-4ee2-9d08-0585964fc934 ]) Found
template routing-8 in storage pool 6 with VMTemplateStoragePool id: 28
2013-11-03 10:21:07,187 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-3:null) SeqA 10-30340: Processing Seq 10-30340: { Cmd
, MgmtId: -1, via: 10, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:17,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2013-11-03 10:21:07,331 DEBUG [storage.volume.VolumeServiceImpl]
(Job-Executor-17:job-155 = [ d4cadcb1-7e06-4ee2-9d08-0585964fc934 ]) Acquire
lock on VMTemplateStoragePool 28 with timeout 3600 seconds
2013-11-03 10:21:07,333 INFO [storage.volume.VolumeServiceImpl]
(Job-Executor-17:job-155 = [ d4cadcb1-7e06-4ee2-9d08-0585964fc934 ]) lock is
acquired for VMTemplateStoragePool 28
2013-11-03 10:21:07,341 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-3:null) SeqA 10-30340: Sending Seq 10-30340: { Ans: ,
MgmtId: 94838926819810, via: 10, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2013-11-03 10:21:07,373 DEBUG [storage.motion.AncientDataMotionStrategy]
(Job-Executor-17:job-155 = [ d4cadcb1-7e06-4ee2-9d08-0585964fc934 ])
copyAsync inspecting src type TEMPLATE copyAsync inspecting dest type TEMPLATE
2013-11-03 10:21:07,387 DEBUG [storage.motion.AncientDataMotionStrategy]
(Job-Executor-17:job-155 = [ d4cadcb1-7e06-4ee2-9d08-0585964fc934 ]) copy
object failed:
java.lang.NullPointerException
at
org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyObject(AncientDataMotionStrategy.java:210)
at
org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:411)
at
org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:58)
at
org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:446)
at
org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:575)
at
com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2567)
at
com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2631)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:888)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:577)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2764)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1896)
at
[jira] [Created] (CLOUDSTACK-5031) Wrong install steps for installing the Usage server in the documentation of ACS.
Kiran Koneti created CLOUDSTACK-5031: Summary: Wrong install steps for installing the Usage server in the documentation of ACS. Key: CLOUDSTACK-5031 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5031 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.2.0 Reporter: Kiran Koneti Priority: Critical Fix For: 4.2.0 In the steps for installation of the usage server in the documentation under thes etion 9.1 we dosent see the correct steps for installing the usage server. The steps mentioned in the doc are as below: 9.1.2. Steps to Install the Usage Server Run ./install.sh. # ./install.sh You should see a few messages as the installer prepares, followed by a list of choices. Choose S to install the Usage Server. S Once installed, start the Usage Server with the following command. # service cloudstack-usage start The Administration Guide discusses further configuration of the Usage Server. But the ACS version doesn't have the install.sh script it can be done using the yum install cloudstack-usage . -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-2272) Automation - DeployVM User data enhancement
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812764#comment-13812764 ] ASF subversion and git services commented on CLOUDSTACK-2272: - Commit 9bf30479fc088a8d0dc8dafebbf9de5824287f81 in branch refs/heads/4.2 from [~sadhu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9bf3047 ] CLOUDSTACK-2272: testscript validates the vmdeployment with userdata Automation - DeployVM User data enhancement --- Key: CLOUDSTACK-2272 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2272 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sudha Ponnaganti Assignee: sadhu suresh Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-2272) Automation - DeployVM User data enhancement
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812765#comment-13812765 ] ASF subversion and git services commented on CLOUDSTACK-2272: - Commit f25354dca11faa1450b677fa2eb1065a1da8aefd in branch refs/heads/master from [~sadhu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f25354d ] CLOUDSTACK-2272: testscript validates the vmdeployment with userdata Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org Automation - DeployVM User data enhancement --- Key: CLOUDSTACK-2272 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2272 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sudha Ponnaganti Assignee: sadhu suresh Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5032) Adding assertElementInList to cloudstackTestCase
Santhosh Kumar Edukulla created CLOUDSTACK-5032: --- Summary: Adding assertElementInList to cloudstackTestCase Key: CLOUDSTACK-5032 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5032 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Added assertElementInList to cloudstackTestCase for derived Classes. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5032) Adding assertElementInList to cloudstackTestCase
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla updated CLOUDSTACK-5032: Description: Added assertElementInList to cloudstackTestCase for derived Classes. The purpose is to provide a custom assert to test features for list verification. (was: Added assertElementInList to cloudstackTestCase for derived Classes. ) Adding assertElementInList to cloudstackTestCase Key: CLOUDSTACK-5032 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5032 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Added assertElementInList to cloudstackTestCase for derived Classes. The purpose is to provide a custom assert to test features for list verification. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3216) Logs in the Software router are not being rotated
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812924#comment-13812924 ] ASF subversion and git services commented on CLOUDSTACK-3216: - Commit 70330f5cf32f4a0463edf5024cf841e0e678f423 in branch refs/heads/master from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=70330f5 ] CLOUDSTACK-3216 /var/log/cloud.log did not have a logrotate script, here is a basic one. Logs in the Software router are not being rotated - Key: CLOUDSTACK-3216 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3216 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.1.0, 4.2.0 Environment: centos kvm Reporter: Brian Angus Assignee: Rajesh Battala Priority: Blocker Labels: debian Fix For: 4.1.1, 4.2.0 Original Estimate: 3h Remaining Estimate: 3h root@r-6-VM:/etc# ls -l logrotate.* -rwxr-xr-x 1 root root 498 Jun 19 16:34 logrotate.conf logrotate.d: total 10 -rwxr-xr-x 1 root root 192 Jun 19 16:34 apache2 -rw-r--r-- 1 root root 173 Dec 13 2012 apt -rw-r--r-- 1 root root 79 Nov 5 2012 aptitude -rw-r--r-- 1 root root 154 Jun 12 2012 conntrackd -rwxr-xr-x 1 root root 266 Jun 19 16:34 dnsmasq -rw-r--r-- 1 root root 232 Oct 20 2012 dpkg -rwxr-xr-x 1 root root 203 Jun 19 16:34 haproxy -rw-r--r-- 1 root root 268 Jun 1 2012 monit -rwxr-xr-x 1 root root 93 Jun 19 16:34 ppp -rwxr-xr-x 1 root root 515 Jun 19 16:34 rsyslog root@r-6-VM:/etc# /usr/sbin/logrotate -d -v /etc/logrotate.conf Ignoring /etc/logrotate.conf because of bad file mode. Handling 0 logs root@r-6-VM:/etc# Looks like the file permissions are correct in the template (0644) but when the router gets deployed the permissions are getting changed. Looks like the problem is in patches/pom.xml: the filemode for the tarfileset is set to 755 Also there needs to be a logrotate config for /var/log/cloud.log -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3216) Logs in the Software router are not being rotated
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13812926#comment-13812926 ] ASF subversion and git services commented on CLOUDSTACK-3216: - Commit 5cc9b1de661f3189dcd1e3eb65d7e1d15c05e9e6 in branch refs/heads/4.2 from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5cc9b1d ] CLOUDSTACK-3216 /var/log/cloud.log did not have a logrotate script, here is a basic one. Logs in the Software router are not being rotated - Key: CLOUDSTACK-3216 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3216 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.1.0, 4.2.0 Environment: centos kvm Reporter: Brian Angus Assignee: Rajesh Battala Priority: Blocker Labels: debian Fix For: 4.1.1, 4.2.0 Original Estimate: 3h Remaining Estimate: 3h root@r-6-VM:/etc# ls -l logrotate.* -rwxr-xr-x 1 root root 498 Jun 19 16:34 logrotate.conf logrotate.d: total 10 -rwxr-xr-x 1 root root 192 Jun 19 16:34 apache2 -rw-r--r-- 1 root root 173 Dec 13 2012 apt -rw-r--r-- 1 root root 79 Nov 5 2012 aptitude -rw-r--r-- 1 root root 154 Jun 12 2012 conntrackd -rwxr-xr-x 1 root root 266 Jun 19 16:34 dnsmasq -rw-r--r-- 1 root root 232 Oct 20 2012 dpkg -rwxr-xr-x 1 root root 203 Jun 19 16:34 haproxy -rw-r--r-- 1 root root 268 Jun 1 2012 monit -rwxr-xr-x 1 root root 93 Jun 19 16:34 ppp -rwxr-xr-x 1 root root 515 Jun 19 16:34 rsyslog root@r-6-VM:/etc# /usr/sbin/logrotate -d -v /etc/logrotate.conf Ignoring /etc/logrotate.conf because of bad file mode. Handling 0 logs root@r-6-VM:/etc# Looks like the file permissions are correct in the template (0644) but when the router gets deployed the permissions are getting changed. Looks like the problem is in patches/pom.xml: the filemode for the tarfileset is set to 755 Also there needs to be a logrotate config for /var/log/cloud.log -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4820) TestVPCNetworkGc.test_01_wait_network_gc netacls are not cleared
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-4820: Priority: Blocker (was: Major) TestVPCNetworkGc.test_01_wait_network_gc netacls are not cleared Key: CLOUDSTACK-4820 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4820 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.1 Reporter: Girish Shilamkar Priority: Blocker Attachments: management-server.tgz While updating the testcase TestVPCNetworkGc.test_01_wait_network_gc it was found that even after waiting for network garbage collector to run, the netacls are not cleared. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5034) Finding snapshot size
Diogo Monteiro created CLOUDSTACK-5034: -- Summary: Finding snapshot size Key: CLOUDSTACK-5034 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5034 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Diogo Monteiro Steps to reproduce: Create a volume Attach volume to a server Take snapshot from volume Delete volume After the volume is deleted there is no way to find the size of the snapshot. Expected results: When listing a snapshot besides the volumeId and name the size should be included as one of its attributes. Internally the size is being tracked since if a template is created from a snapshot it will inherit its size. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5035) Finding snapshot size
Diogo Monteiro created CLOUDSTACK-5035: -- Summary: Finding snapshot size Key: CLOUDSTACK-5035 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5035 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Diogo Monteiro Steps to reproduce: Create a volume Attach volume to a server Take snapshot from volume Delete volume After the volume is deleted there is no way to find the size of the snapshot. Expected results: When listing a snapshot besides the volumeId and name the size should be included as one of its attributes. Internally the size is being tracked since if a template is created from a snapshot it will inherit its size. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5032) Adding assertElementInList to cloudstackTestCase
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813035#comment-13813035 ] Santhosh Kumar Edukulla commented on CLOUDSTACK-5032: - Added commit 59e95c44345c6554149f4934e2161b29a986ac70 for this fix. Adding assertElementInList to cloudstackTestCase Key: CLOUDSTACK-5032 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5032 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla Added assertElementInList to cloudstackTestCase for derived Classes. The purpose is to provide a custom assert to test features for list verification. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-5022) [Automation] Failed to create volume from snapshot in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-5022.
---
Verified
[Automation] Failed to create volume from snapshot in KVM
-
Key: CLOUDSTACK-5022
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5022
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.2.1
Environment: KVM (RHEL 6.3)
Build : 4.2
Reporter: Rayees Namathponnan
Assignee: edison su
Priority: Blocker
Fix For: 4.2.1
Attachments: CLOUDSTACK-5022.rar
Steps to reproduce
Step 1 : Create snapshot of ROOT volume
Step 2 : Create volume from snapshot
Failed to create volume with below null pointer exception
2013-11-01 08:19:18,229 DEBUG [agent.transport.Request]
(Job-Executor-147:job-6486 = [ 14b465b9-0c03-4783-866f-1296b20c358b ]) Seq
1-894971116: Sending { Cmd , MgmtId: 29066118877352, via: 1, Ver: v1, Flags:
11,
[{com.cloud.agent.api.routing.IpAssocCommand:{ipAddresses:[{accountId:911,publicIp:10.223.122.92,sourceNat:true,add:true,oneToOneNat:false,firstIP:true,vlanId:1221,vlanGateway:10.223.122.65,vlanNetmask:255.255.255.192,vifMacAddress:06:39:a6:00:00:55,networkRate:200,trafficType:Public},{accountId:911,publicIp:10.223.122.113,sourceNat:false,add:true,oneToOneNat:false,firstIP:false,vlanId:1221,vlanGateway:10.223.122.65,vlanNetmask:255.255.255.192,vifMacAddress:06:52:bb:00:00:55,networkRate:200,trafficType:Public},{accountId:911,publicIp:10.223.122.79,sourceNat:false,add:true,oneToOneNat:false,firstIP:false,vlanId:1221,vlanGateway:10.223.122.65,vlanNetmask:255.255.255.192,vifMacAddress:06:52:bb:00:00:55,networkRate:200,trafficType:Public}],accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:169.254.0.81,router.name:r-1662-QA},wait:0}}]
}
2013-11-01 08:19:18,345 DEBUG [agent.transport.Request]
(AgentManager-Handler-6:null) Seq 2-877402380: Processing: { Ans: , MgmtId:
29066118877352, via: 2, Ver: v1, Flags: 110,
[{com.cloud.agent.api.Answer:{result:false,details:java.lang.NullPointerException\n\tat
com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.createVolumeFromSnapshot(KVMStorageProcessor.java:1178)\n\tat
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:86)\n\tat
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49)\n\tat
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1286)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:525)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)\n\tat
com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\n\tat
java.lang.Thread.run(Thread.java:679)\n,wait:0}}] }
2013-11-01 08:19:18,345 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-6:null) Seq 2-877402380: No more commands found
2013-11-01 08:19:18,345 DEBUG [agent.transport.Request]
(Job-Executor-120:job-6487 = [ f6fbb88e-1fe1-4507-9406-b8e62d9e1f70 ]) Seq
2-877402380: Received: { Ans: , MgmtId: 29066118877352, via: 2, Ver: v1,
Flags: 110, { Answer } }
2013-11-01 08:19:18,350 WARN
[storage.datastore.ObjectInDataStoreManagerImpl] (Job-Executor-120:job-6487 =
[ f6fbb88e-1fe1-4507-9406-b8e62d9e1f70 ]) Unsupported data object (VOLUME,
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@3918ddd), no
need to delete from object in store ref table
2013-11-01 08:19:18,372 WARN
[storage.datastore.ObjectInDataStoreManagerImpl] (Job-Executor-120:job-6487 =
[ f6fbb88e-1fe1-4507-9406-b8e62d9e1f70 ]) Snapshot 38 is not found on image
store 1, so no need to delete
2013-11-01 08:19:18,372 DEBUG [cloud.storage.VolumeManagerImpl]
(Job-Executor-120:job-6487 = [ f6fbb88e-1fe1-4507-9406-b8e62d9e1f70 ]) Failed
to create volume from snapshot:java.lang.NullPointerException
at
com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.createVolumeFromSnapshot(KVMStorageProcessor.java:1178)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:86)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1286)
at
[jira] [Commented] (CLOUDSTACK-5017) If SSVM is unavailable DownloadCommands will be routed to mgmt server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813230#comment-13813230 ] ASF subversion and git services commented on CLOUDSTACK-5017: - Commit 9a62239a92c5eafca6fafee1fbccd413bdfb91af in branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9a62239 ] CLOUDSTACK-5017: Throw CloudRuntimeException in case of template/volume download when ssvm is not ready so that caller can remove some leftover entries in template_store_ref and volume_store_ref. If SSVM is unavailable DownloadCommands will be routed to mgmt server - Key: CLOUDSTACK-5017 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5017 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Darren Shepherd Assignee: Min Chen Priority: Blocker Fix For: 4.3.0 If a SSVM in the zone is not available, meaning either it does not exist or the host entry is not Up or Connecting, DownloadCommand will get routed to LocalHostEndpoint. This is particularily dangerous in a NFS setup. If the mgmt server handles the DownloadCommand it has sudo access to mount NFS and perform the action. This mean the mgmt server is now in the data path, or worse, it could hang if it does not have network access to the NFS server. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3216) Logs in the Software router are not being rotated
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813363#comment-13813363 ] ASF subversion and git services commented on CLOUDSTACK-3216: - Commit 70330f5cf32f4a0463edf5024cf841e0e678f423 in branch refs/heads/ui-restyle from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=70330f5 ] CLOUDSTACK-3216 /var/log/cloud.log did not have a logrotate script, here is a basic one. Logs in the Software router are not being rotated - Key: CLOUDSTACK-3216 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3216 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.1.0, 4.2.0 Environment: centos kvm Reporter: Brian Angus Assignee: Rajesh Battala Priority: Blocker Labels: debian Fix For: 4.1.1, 4.2.0 Original Estimate: 3h Remaining Estimate: 3h root@r-6-VM:/etc# ls -l logrotate.* -rwxr-xr-x 1 root root 498 Jun 19 16:34 logrotate.conf logrotate.d: total 10 -rwxr-xr-x 1 root root 192 Jun 19 16:34 apache2 -rw-r--r-- 1 root root 173 Dec 13 2012 apt -rw-r--r-- 1 root root 79 Nov 5 2012 aptitude -rw-r--r-- 1 root root 154 Jun 12 2012 conntrackd -rwxr-xr-x 1 root root 266 Jun 19 16:34 dnsmasq -rw-r--r-- 1 root root 232 Oct 20 2012 dpkg -rwxr-xr-x 1 root root 203 Jun 19 16:34 haproxy -rw-r--r-- 1 root root 268 Jun 1 2012 monit -rwxr-xr-x 1 root root 93 Jun 19 16:34 ppp -rwxr-xr-x 1 root root 515 Jun 19 16:34 rsyslog root@r-6-VM:/etc# /usr/sbin/logrotate -d -v /etc/logrotate.conf Ignoring /etc/logrotate.conf because of bad file mode. Handling 0 logs root@r-6-VM:/etc# Looks like the file permissions are correct in the template (0644) but when the router gets deployed the permissions are getting changed. Looks like the problem is in patches/pom.xml: the filemode for the tarfileset is set to 755 Also there needs to be a logrotate config for /var/log/cloud.log -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5017) If SSVM is unavailable DownloadCommands will be routed to mgmt server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813368#comment-13813368 ] ASF subversion and git services commented on CLOUDSTACK-5017: - Commit 9a62239a92c5eafca6fafee1fbccd413bdfb91af in branch refs/heads/ui-restyle from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9a62239 ] CLOUDSTACK-5017: Throw CloudRuntimeException in case of template/volume download when ssvm is not ready so that caller can remove some leftover entries in template_store_ref and volume_store_ref. If SSVM is unavailable DownloadCommands will be routed to mgmt server - Key: CLOUDSTACK-5017 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5017 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Darren Shepherd Assignee: Min Chen Priority: Blocker Fix For: 4.3.0 If a SSVM in the zone is not available, meaning either it does not exist or the host entry is not Up or Connecting, DownloadCommand will get routed to LocalHostEndpoint. This is particularily dangerous in a NFS setup. If the mgmt server handles the DownloadCommand it has sudo access to mount NFS and perform the action. This mean the mgmt server is now in the data path, or worse, it could hang if it does not have network access to the NFS server. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-730) Site-to-Site VPN VR-to-VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-730. --- Resolution: Fixed Fix Version/s: (was: Future) 4.3.0 Site-to-Site VPN VR-to-VR - Key: CLOUDSTACK-730 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-730 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Reporter: Manan Shah Assignee: Sheng Yang Fix For: 4.3.0 Creating a sub-task for the Site-to-Site VPN between two Virtual Routers. Please see the main task for requirements. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4992) Domain/Account/User Sync Up Among Multiple Regions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Ough updated CLOUDSTACK-4992: -- Description: Currently, under the environment of cloudstack with multiple regions, each region has its own management server running with a separate database. So if we want to support multiple regions and provide one point of entry for a customer, we need to duplicate domain/account/user information of that customer to all of the databases of regions the customer accesses, which will cause data discrepancies when users update those data independently in each management server. So I'd like to provide a way to sync up the data using the messaging system introduced in 4.1.0. Using the events from each management server, updates from each region can be propagated to the rest regions and they can be executed accordingly. This is the title of the email for discuss. [DISCUSS] Domain/Account/User Sync Up Among Multiple Regions Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain-Account-User+Sync+Up+Among+Multiple+Regions The implementation of the first approach, master-slave architecture. https://github.com/alexoughsg/albatross was: Currently, under the environment of cloudstack with multiple regions, each region has its own management server running with a separate database. So if we want to support multiple regions and provide one point of entry for a customer, we need to duplicate domain/account/user information of that customer to all of the databases of regions the customer accesses, which will cause data discrepancies when users update those data independently in each management server. So I'd like to provide a way to sync up the data using the messaging system introduced in 4.1.0. Using the events from each management server, updates from each region can be propagated to the rest regions and they can be executed accordingly. This is the title of the email for discuss. [DISCUSS] Domain/Account/User Sync Up Among Multiple Regions Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain-Account-User+Sync+Up+Among+Multiple+Regions Domain/Account/User Sync Up Among Multiple Regions -- Key: CLOUDSTACK-4992 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4992 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: Future Reporter: Alex Ough Assignee: Alex Ough Labels: features Fix For: Future Currently, under the environment of cloudstack with multiple regions, each region has its own management server running with a separate database. So if we want to support multiple regions and provide one point of entry for a customer, we need to duplicate domain/account/user information of that customer to all of the databases of regions the customer accesses, which will cause data discrepancies when users update those data independently in each management server. So I'd like to provide a way to sync up the data using the messaging system introduced in 4.1.0. Using the events from each management server, updates from each region can be propagated to the rest regions and they can be executed accordingly. This is the title of the email for discuss. [DISCUSS] Domain/Account/User Sync Up Among Multiple Regions Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain-Account-User+Sync+Up+Among+Multiple+Regions The implementation of the first approach, master-slave architecture. https://github.com/alexoughsg/albatross -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-730) Site-to-Site VPN VR-to-VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813416#comment-13813416 ] ASF subversion and git services commented on CLOUDSTACK-730: Commit c350999c932dcafbc2fbe592ba6b7ce38d443d50 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c350999 ] CLOUDSTACK-730: UI VPC Router site-to-site VPN VPN Connection detailView add Passive field. Site-to-Site VPN VR-to-VR - Key: CLOUDSTACK-730 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-730 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Reporter: Manan Shah Assignee: Sheng Yang Fix For: 4.3.0 Creating a sub-task for the Site-to-Site VPN between two Virtual Routers. Please see the main task for requirements. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5017) If SSVM is unavailable DownloadCommands will be routed to mgmt server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813430#comment-13813430 ] ASF subversion and git services commented on CLOUDSTACK-5017: - Commit 9a62239a92c5eafca6fafee1fbccd413bdfb91af in branch refs/heads/rbac from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9a62239 ] CLOUDSTACK-5017: Throw CloudRuntimeException in case of template/volume download when ssvm is not ready so that caller can remove some leftover entries in template_store_ref and volume_store_ref. If SSVM is unavailable DownloadCommands will be routed to mgmt server - Key: CLOUDSTACK-5017 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5017 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Darren Shepherd Assignee: Min Chen Priority: Blocker Fix For: 4.3.0 If a SSVM in the zone is not available, meaning either it does not exist or the host entry is not Up or Connecting, DownloadCommand will get routed to LocalHostEndpoint. This is particularily dangerous in a NFS setup. If the mgmt server handles the DownloadCommand it has sudo access to mount NFS and perform the action. This mean the mgmt server is now in the data path, or worse, it could hang if it does not have network access to the NFS server. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4908) cpu socket count of hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813461#comment-13813461 ] ASF subversion and git services commented on CLOUDSTACK-4908: - Commit 57678257a123da1f74fa2a81407beb94450444b3 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5767825 ] CLOUDSTACK-4908: UI Infrastructure Sockets view all calculate Hosts for each hypervisor. cpu socket count of hosts - Key: CLOUDSTACK-4908 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4908 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Fix For: 4.3.0 Additional infrastructure statistics to display the number of hosts/cpu sockets being managed by cloudstack which reflects the size of cloud. When we add the host we collect the number of CPU sockets and add this information in HostReponse. So we can calculate the cpu socket number summing the number of sockets for each host using listHostsAPI. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-3961) [Automation] Failed to create LB rule in test case TestVMDeployVPC.test_07_delete_network_with_rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan closed CLOUDSTACK-3961. --- Resolution: Fixed Closing this defect, SSH failures is comman with many test case, we will track in another defect [Automation] Failed to create LB rule in test case TestVMDeployVPC.test_07_delete_network_with_rules Key: CLOUDSTACK-3961 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3961 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.2.0 Environment: Automation Reporter: Rayees Namathponnan Assignee: Girish Shilamkar Fix For: 4.3.0 Test case integration.component.test_vpc_vms_deployment.TestVMDeployVPC.test_07_delete_network_with_rules failed to create LB rule Execute cmd: createloadbalancerrule failed, due to: errorCode: 530, errorText:Failed to create load balancer rule: SSH begin captured logging testclient.testcase.TestVMDeployVPC: DEBUG: Creating a VPC offering.. testclient.testcase.TestVMDeployVPC: DEBUG: Check if the VPC offering is created successfully? testclient.testcase.TestVMDeployVPC: DEBUG: VPC offering is created successfully - VPC off-2MEVUE testclient.testcase.TestVMDeployVPC: DEBUG: Enabling the VPC offering created testclient.testcase.TestVMDeployVPC: DEBUG: creating a VPC network in the account: test-YJ705G testclient.testcase.TestVMDeployVPC: DEBUG: Check if the VPC network is created successfully? testclient.testcase.TestVMDeployVPC: DEBUG: VPC network validated - TestVPC-LP7HLI testclient.testcase.TestVMDeployVPC: DEBUG: Creating network with network offering: 99875261-5eae-413f-94ac-c02da2b4fc0e testclient.testcase.TestVMDeployVPC: DEBUG: Created network with ID: 31116a68-3b10-49fe-8360-ba1002749e12 testclient.testcase.TestVMDeployVPC: DEBUG: Creating network with network offering: 86ae23ca-f7da-405e-98da-39051628f325 testclient.testcase.TestVMDeployVPC: DEBUG: Created network with ID: d12a75f6-c714-482d-9678-1285681a3964 testclient.testcase.TestVMDeployVPC: DEBUG: deploying VMs in network: Test Network testclient.testcase.TestVMDeployVPC: DEBUG: Deployed VM in network: 31116a68-3b10-49fe-8360-ba1002749e12 testclient.testcase.TestVMDeployVPC: DEBUG: Deployed another VM in network: 31116a68-3b10-49fe-8360-ba1002749e12 testclient.testcase.TestVMDeployVPC: DEBUG: deploying VMs in network: Test Network testclient.testcase.TestVMDeployVPC: DEBUG: Deployed VM in network: d12a75f6-c714-482d-9678-1285681a3964 testclient.testcase.TestVMDeployVPC: DEBUG: Deployed VM in network: d12a75f6-c714-482d-9678-1285681a3964 testclient.testcase.TestVMDeployVPC: DEBUG: Check if deployed VMs are in running state? testclient.testcase.TestVMDeployVPC: DEBUG: VM name: 170e8320-57b6-4732-9982-ba89317d0881, VM state: Running testclient.testcase.TestVMDeployVPC: DEBUG: VM name: 91474c90-12ce-4c78-91a1-b12abfb80cac, VM state: Running testclient.testcase.TestVMDeployVPC: DEBUG: VM name: 99bd4d34-40e1-4d17-adac-54e672a2c9e4, VM state: Running testclient.testcase.TestVMDeployVPC: DEBUG: VM name: 99defa04-8752-47bf-a619-ae8d32500f39, VM state: Running testclient.testcase.TestVMDeployVPC: DEBUG: Associating public IP for network: Test Network testclient.testcase.TestVMDeployVPC: DEBUG: Associated 10.223.122.81 with network 31116a68-3b10-49fe-8360-ba1002749e12 testclient.testcase.TestVMDeployVPC: DEBUG: Adding NetwrokACl rules to make NAT rule accessible testclient.testcase.TestVMDeployVPC: DEBUG: Associating public IP for network: Test Network testclient.testcase.TestVMDeployVPC: DEBUG: Associated 10.223.122.82 with network 31116a68-3b10-49fe-8360-ba1002749e12 testclient.testcase.TestVMDeployVPC: DEBUG: Enabling static NAT for IP: 10.223.122.82 testclient.testcase.TestVMDeployVPC: DEBUG: Static NAT enabled for IP: 10.223.122.82 testclient.testcase.TestVMDeployVPC: DEBUG: Associating public IP for network: TestVPC-LP7HLI testclient.testcase.TestVMDeployVPC: DEBUG: Associated 10.223.122.84 with network d12a75f6-c714-482d-9678-1285681a3964 testclient.testcase.TestVMDeployVPC: DEBUG: Creating LB rule for IP address: 10.223.122.84 - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_vpc_vms_deployment.py, line 1986, in test_07_delete_network_with_rules domainid=self.account.domainid File
[jira] [Commented] (CLOUDSTACK-4755) cloudstack 4.x does not allow memory upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813482#comment-13813482 ] ASF subversion and git services commented on CLOUDSTACK-4755: - Commit 3cc823903a0aa99b20a55b13e871d0ad8f6caf79 in branch refs/heads/master from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3cc8239 ] CLOUDSTACK-4755: cloudstack 4.x does not allow memory upgrade Changes: - Set total capacity of a host if it has changed in the CapacityChecker thread - Fix bug while setting the reserved/used cpu/mem capacity - only one of them used to get set cloudstack 4.x does not allow memory upgrade Key: CLOUDSTACK-4755 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4755 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.1.0 Reporter: Timothy Ehlers Assignee: Prachi Damle Fix For: 4.2.1 to reproduce open your server and add ram. Cloudstack will not update Here is how to fix it until the code is fixed: mysql select s.id, h.name, s.total_capacity from host as h, op_host_capacity as s where h.id=s.host_id and capacity_type=0 and h.name like 'myservername%' order by h.name; update op_host_capacity set total_capacity=202812919808 where id=71; -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4755) cloudstack 4.x does not allow memory upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Damle resolved CLOUDSTACK-4755. -- Resolution: Fixed cloudstack 4.x does not allow memory upgrade Key: CLOUDSTACK-4755 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4755 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.1.0 Reporter: Timothy Ehlers Assignee: Prachi Damle Fix For: 4.2.1 to reproduce open your server and add ram. Cloudstack will not update Here is how to fix it until the code is fixed: mysql select s.id, h.name, s.total_capacity from host as h, op_host_capacity as s where h.id=s.host_id and capacity_type=0 and h.name like 'myservername%' order by h.name; update op_host_capacity set total_capacity=202812919808 where id=71; -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4948) DeploymentPlanner: Logic to check if cluster can be avoided, needs to consider if VM is using local storage and/or shared storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813481#comment-13813481 ] ASF subversion and git services commented on CLOUDSTACK-4948: - Commit 863a84a15dca7889692323e9e024fc8cedc1dc2b in branch refs/heads/master from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=863a84a ] CLOUDSTACK-4948: DeploymentPlanner: Logic to check if cluster can be avoided, needs to consider if VM is using local storage and/or shared storage Changes: - Changes due to VirtualMachineProfile changes done in master DeploymentPlanner: Logic to check if cluster can be avoided, needs to consider if VM is using local storage and/or shared storage - Key: CLOUDSTACK-4948 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4948 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: Prachi Damle Assignee: Prachi Damle Fix For: 4.2.1 During VM deployment the DeploymentPlanningManager iterates over each cluster and if there is no destination found in a cluster, it tries to see if that cluster should be avoided. This logic puts a cluster is avoid set if all hosts in the cluster are in avoid set or all pools in the cluster are in avoid set. In the check to see all pools, the logic should consider the storage requirements of the VM. If the VM just uses local storage, 'all pools' in cluster should only consider local pools in the cluster. Else the presence of shared pools in the cluster can prevent the cluster from getting avoided. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5037) UI - Pop up a warning message when user is changing over provisioning factor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-5037: Description: UI - Pop up a warning message when user is changing cpu/memory over provisioning factor for cluster and that cluster has vms deployed. Following should be the message. Please note - you are changing the over provisioning factor for a cluster with vms running. Please refer to the admin guide to understand the capacity calculation. was: UI - Pop up a warning message when user is changing cpu/memory over provisioning factor for cluster and that cluster has vms deployed. Please note - you are changing the over provisioning factor for a cluster with vms running. Please refer to the admin guide to understand the capacity calculation. UI - Pop up a warning message when user is changing over provisioning factor Key: CLOUDSTACK-5037 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5037 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Nitin Mehta Fix For: 4.2.1 UI - Pop up a warning message when user is changing cpu/memory over provisioning factor for cluster and that cluster has vms deployed. Following should be the message. Please note - you are changing the over provisioning factor for a cluster with vms running. Please refer to the admin guide to understand the capacity calculation. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5017) If SSVM is unavailable DownloadCommands will be routed to mgmt server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-5017. -- Resolution: Fixed If SSVM is unavailable DownloadCommands will be routed to mgmt server - Key: CLOUDSTACK-5017 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5017 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Darren Shepherd Assignee: Min Chen Priority: Blocker Fix For: 4.3.0 If a SSVM in the zone is not available, meaning either it does not exist or the host entry is not Up or Connecting, DownloadCommand will get routed to LocalHostEndpoint. This is particularily dangerous in a NFS setup. If the mgmt server handles the DownloadCommand it has sudo access to mount NFS and perform the action. This mean the mgmt server is now in the data path, or worse, it could hang if it does not have network access to the NFS server. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5038) Upgrade to 4.2 - used cpu is getting bumped up when the over provisioning factor 1
Nitin Mehta created CLOUDSTACK-5038: --- Summary: Upgrade to 4.2 - used cpu is getting bumped up when the over provisioning factor 1 Key: CLOUDSTACK-5038 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5038 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Fix For: 4.2.1 Upgrade to 4.2 - used cpu is getting bumped up when the over provisioning factor 1. Provide a code/sql fix. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-5038) Upgrade to 4.2 - used cpu is getting bumped up when the over provisioning factor 1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta reassigned CLOUDSTACK-5038: --- Assignee: Nitin Mehta Upgrade to 4.2 - used cpu is getting bumped up when the over provisioning factor 1 Key: CLOUDSTACK-5038 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5038 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: 4.2.1 Upgrade to 4.2 - used cpu is getting bumped up when the over provisioning factor 1. Provide a code/sql fix. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5039) [KVM] live migration failed : Domain not found: no domain with matching uuid 'uuid'
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yoshikazu Nojima updated CLOUDSTACK-5039:
-
Description:
{code}
2013-11-05 04:39:29,345 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-1:null) Can't migrate domain: Domain not found: no domain
with matching uuid '87c06b76-5ee6-3f1b-8c89-54e75de6bd3d'
{code}
was:
{noformat}
2013-11-05 04:39:29,345 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-1:null) Can't migrate domain: Domain not found: no domain
with matching uuid '87c06b76-5ee6-3f1b-8c89-54e75de6bd3d'
{noformat}
[KVM] live migration failed : Domain not found: no domain with matching uuid
'uuid'
-
Key: CLOUDSTACK-5039
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5039
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.3.0
Reporter: Yoshikazu Nojima
Assignee: Yoshikazu Nojima
{code}
2013-11-05 04:39:29,345 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-1:null) Can't migrate domain: Domain not found: no
domain with matching uuid '87c06b76-5ee6-3f1b-8c89-54e75de6bd3d'
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CLOUDSTACK-5039) [KVM] live migration failed : Domain not found: no domain with matching uuid 'uuid'
Yoshikazu Nojima created CLOUDSTACK-5039:
Summary: [KVM] live migration failed : Domain not found: no domain
with matching uuid 'uuid'
Key: CLOUDSTACK-5039
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5039
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: 4.3.0
Reporter: Yoshikazu Nojima
Assignee: Yoshikazu Nojima
{noformat}
2013-11-05 04:39:29,345 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-1:null) Can't migrate domain: Domain not found: no domain
with matching uuid '87c06b76-5ee6-3f1b-8c89-54e75de6bd3d'
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5039) [KVM] live migration failed : Domain not found: no domain with matching uuid 'uuid'
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813634#comment-13813634 ] Marcus Sorensen commented on CLOUDSTACK-5039: - There should be something prior to this explaining why libvirtd failed to start the destination VM. Maybe in the qemu log for that vm, if the agent doesn't catch it. [KVM] live migration failed : Domain not found: no domain with matching uuid 'uuid' - Key: CLOUDSTACK-5039 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5039 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: Yoshikazu Nojima Assignee: Yoshikazu Nojima Live migration failed with following error message: 2013-11-05 04:39:29,345 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-1:null) Can't migrate domain: Domain not found: no domain with matching uuid '87c06b76-5ee6-3f1b-8c89-54e75de6bd3d' -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5039) [KVM] live migration failed : Domain not found: no domain with matching uuid 'uuid'
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yoshikazu Nojima updated CLOUDSTACK-5039:
-
Description:
Live migration failed with following error message:
2013-11-05 04:39:29,345 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-1:null) Can't migrate domain: Domain not found: no domain
with matching uuid '87c06b76-5ee6-3f1b-8c89-54e75de6bd3d'
was:
{code}
2013-11-05 04:39:29,345 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-1:null) Can't migrate domain: Domain not found: no domain
with matching uuid '87c06b76-5ee6-3f1b-8c89-54e75de6bd3d'
{code}
[KVM] live migration failed : Domain not found: no domain with matching uuid
'uuid'
-
Key: CLOUDSTACK-5039
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5039
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.3.0
Reporter: Yoshikazu Nojima
Assignee: Yoshikazu Nojima
Live migration failed with following error message:
2013-11-05 04:39:29,345 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-1:null) Can't migrate domain: Domain not found: no
domain with matching uuid '87c06b76-5ee6-3f1b-8c89-54e75de6bd3d'
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4938) Add account password confirmation broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813726#comment-13813726 ] Animesh Chaturvedi commented on CLOUDSTACK-4938: Brian can you check on this again? Add account password confirmation broken Key: CLOUDSTACK-4938 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4938 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Brian Federle Assignee: Ian Duffy Priority: Blocker Fix For: 4.3.0 Currently the password confirmation field is not validating, even if the confirmation value is correct. The validation needs to be fixed, otherwise the add account dialog will not execute. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4835) [Automation] [BVT] Update global configuration test cases failed in master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813727#comment-13813727 ] Animesh Chaturvedi commented on CLOUDSTACK-4835: gaurav, rayees is this still an issue. Can you post the results from run on master [Automation] [BVT] Update global configuration test cases failed in master -- Key: CLOUDSTACK-4835 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4835 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: KVM Branch - master Reporter: Rayees Namathponnan Priority: Blocker Fix For: 4.3.0 Below BVT test cases failed, integration.smoke.test_global_settings.TestUpdateConfigWithScope.test_UpdateConfigParamWithScope Unable to find the global property use.external.dns in master, is it removed ? you can see the result at http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/lastCompletedBuild/suite=test_global_settings/#showFailuresLink Error Message Execute cmd: updateconfiguration failed, due to: errorCode: 431, errorText:Config parameter with name use.external.dns doesn't exist Stacktrace Traceback (most recent call last): File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/test/integration/smoke/test_global_settings.py, line 47, in test_UpdateConfigParamWithScope updateConfigurationResponse = self.apiClient.updateConfiguration(updateConfigurationCmd) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py, line 1188, in updateConfiguration response = self.connection.marvin_request(command, response_type=response, method=method) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 222, in marvin_request response = jsonHelper.getResultObj(response.json(), response_type) File /var/lib/jenkins/workspace/test-smoke-matrix/suite/test_global_settings/887/lib/python2.7/site-packages/marvin/jsonHelper.py, line 148, in getResultObj raise cloudstackException.cloudstackAPIException(respname, errMsg) cloudstackAPIException: Execute cmd: updateconfiguration failed, due to: errorCode: 431, errorText:Config parameter with name use.external.dns doesn't exist -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4865) KVM deployVM fails on master (f451a811) due to NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-4865: --- Assignee: edison su KVM deployVM fails on master (f451a811) due to NPE -- Key: CLOUDSTACK-4865 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4865 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: Prasanna Santhanam Assignee: edison su Priority: Blocker Fix For: 4.3.0 Attachments: 210.tar.bz2 DeployVM on a KVM host is failing on master with the following exception: Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com local0: 2013-10-14 13:33:04,303 ERROR [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-8:ctx-3def89f5 ctx-b0dcc8e6) Failed to start instance VM[User|44ea7da2-9194-44d3-b14e-5ea3fe3b168 a] Oct 14 06:33:04 java.lang.NullPointerException Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:418) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:564) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1015) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:1069) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:830) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:510) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3338) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2919) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2905) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:421) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$1.runInContext(AsyncJobManagerImpl.java:532) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04
[jira] [Commented] (CLOUDSTACK-4865) KVM deployVM fails on master (f451a811) due to NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813730#comment-13813730 ] Animesh Chaturvedi commented on CLOUDSTACK-4865: Edison can you check on this? KVM deployVM fails on master (f451a811) due to NPE -- Key: CLOUDSTACK-4865 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4865 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: Prasanna Santhanam Assignee: edison su Priority: Blocker Fix For: 4.3.0 Attachments: 210.tar.bz2 DeployVM on a KVM host is failing on master with the following exception: Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com local0: 2013-10-14 13:33:04,303 ERROR [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-8:ctx-3def89f5 ctx-b0dcc8e6) Failed to start instance VM[User|44ea7da2-9194-44d3-b14e-5ea3fe3b168 a] Oct 14 06:33:04 java.lang.NullPointerException Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:418) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:564) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1015) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:1069) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:830) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:510) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3338) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2919) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2905) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:421) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$1.runInContext(AsyncJobManagerImpl.java:532) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) Oct 14 06:33:04 cloudstack-centos63.fmt.vmops.com at
[jira] [Commented] (CLOUDSTACK-5028) Instance is failing to start after releasing the primary storage from maintenance mode
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13813733#comment-13813733
]
ASF subversion and git services commented on CLOUDSTACK-5028:
-
Commit bc36aa026fe5d38643829a2bead56c9dd109ba57 in branch refs/heads/4.2 from
[~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bc36aa0 ]
CLOUDSTACK-5028. Vmware instance fails to start when the chain_info of any
volume that belongs to the VM is longer than 255 characters.
If the VM has snapshots then the chain_info of a volume can be longer than 255
characters.
Increasing the column length of chain_info in VolumeVO to match the maximum
length of type text(db schema type)
Instance is failing to start after releasing the primary storage from
maintenance mode
---
Key: CLOUDSTACK-5028
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5028
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.1
Reporter: Sailaja Mada
Assignee: Likitha Shetty
Priority: Critical
Fix For: 4.2.1
Attachments: startvmlogs.rar
Steps:
1. Configure two Adv zones using VMWARE hypervisor
2. Configuration with Zone wide primary storages
3. Deploy VM using a user account
4. Move the Primary storage into maintenance
5. With this VM got into stopped state
6. Release the Storage into maintenance
7. Now start the VM.
Observation:
Instance is failing to start after releasing the primary storage from
maintenance mode
2013-11-03 19:14:30,652 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-330:null) Seq 9-894186938: Executing request
2013-11-03 19:14:30,665 INFO [vmware.resource.VmwareResource]
(DirectAgent-330:10.102.192.18) Executing resource StartCommand:
{vm:{id:24,name:i-5-24-VM,bootloader:HVM,type:User,cpus:1,minSpeed:200,maxSpeed:200,minRam:536870912,maxRam:536870912,hostName:sailajaVM1,arch:x86_64,os:CentOS
5.3
(64-bit),bootArgs:,rebootOnCrash:false,enableHA:true,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:e5e3f536d1a3d5cc,params:{nicAdapter:E1000,vmware.reserve.cpu:false,nestedVirtualizationFlag:false,Message.ReservedCapacityFreed.Flag:false,rootDiskController:ide,vmware.reserve.mem:false},uuid:1ec83c40-e0dc-48ad-90d8-f4000c0dfe91,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:1ffa6e41-00cc-47d5-958c-f8305ac06af4,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:b33e996a-444e-3685-9070-0865067454c4,id:6,poolType:NetworkFilesystem,host:10.102.192.100,path:/cpg_vol/sailaja/sailajaps2,port:2049}},name:DATA-24,size:5368709120,path:a933eb3fa28a473ab5e28b99f5f2607e,volumeId:37,vmName:i-5-24-VM,accountId:5,chainInfo:{\diskDeviceBusName\:\scsi0:0\,\diskChain\:[\[7f18caf5397a340a934ed37c558aee2b]
i-5-24-VM/8d463fcfe15c43dea0cef4474864552e-04.vmdk\,\[7f18caf5397a340a934ed37c558aee2b]
i-5-24-VM/8d463fcfe15c43dea0cef4474864552e-03.vmdk\,\[7f18caf5397a340a934ed37c5,format:OVA,id:37,hypervisorType:VMware}},diskSeq:1,type:DATADISK},{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:91d3fff2-cc90-4122-b076-06588fa33401,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:7f18caf5-397a-340a-934e-d37c558aee2b,id:5,poolType:NetworkFilesystem,host:10.102.192.100,path:/cpg_vol/sailaja/sailajaps1,port:2049}},name:ROOT-24,size:2147483648,path:ROOT-24,volumeId:38,vmName:i-5-24-VM,accountId:5,format:OVA,id:38,hypervisorType:VMware}},diskSeq:0,type:ROOT},{data:{org.apache.cloudstack.storage.to.TemplateObjectTO:{uuid:257add99-2031-4ad8-b633-979f3812b1cd,id:200,format:ISO,accountId:1,hvm:true,displayText:VMware
Tools Installer ISO,name:vmware-tools.iso,guestOsType:CentOS 4.5
(32-bit),hypervisorType:VMware}},diskSeq:3,type:ISO}],nics:[{deviceId:0,networkRateMbps:200,defaultNic:true,uuid:f3987dbb-7e7e-4a50-8dc1-761b6bdd2f41,ip:10.1.1.79,netmask:255.255.255.0,gateway:10.1.1.1,mac:02:00:3a:5d:00:01,dns1:10.103.128.15,broadcastType:Vlan,type:Guest,broadcastUri:vlan://777,isolationUri:vlan://777,isSecurityGroupEnabled:false}]},hostIp:10.102.192.18,executeInSequence:true,wait:0}
2013-11-03 19:14:30,747 DEBUG [vmware.mo.HostMO]
(DirectAgent-330:10.102.192.18) find VM i-5-24-VM on host
2013-11-03 19:14:30,747 INFO [vmware.mo.HostMO]
(DirectAgent-330:10.102.192.18) VM i-5-24-VM not found in host cache
2013-11-03 19:14:30,747 DEBUG [vmware.mo.HostMO]
(DirectAgent-330:10.102.192.18) load VM cache on host
2013-11-03 19:14:30,769 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null)
===START=== 10.104.255.45 -- GET
