[jira] [Created] (CLOUDSTACK-7621) Database schema not getting upgraded
Pavan Kumar Bandarupally created CLOUDSTACK-7621: Summary: Database schema not getting upgraded Key: CLOUDSTACK-7621 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 After installing management server , the process is stuck at database schema update. The update doesn't progress ahead from 4.0.0 mysql select * from version; ++-+-+--+ | id | version | updated | step | ++-+-+--+ | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | ++-+-+--+ 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally updated CLOUDSTACK-7621: - Attachment: management-server.log Database schema not getting upgraded Key: CLOUDSTACK-7621 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: management-server.log After installing management server , the process is stuck at database schema update. The update doesn't progress ahead from 4.0.0 mysql select * from version; ++-+-+--+ | id | version | updated | step | ++-+-+--+ | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | ++-+-+--+ 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7583) Send statistics collected by StatsCollector to optional Graphite host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146034#comment-14146034 ] ASF subversion and git services commented on CLOUDSTACK-7583: - Commit aa78e5709ec1400292d80cacb6f9cea7c1d958b7 in cloudstack's branch refs/heads/statscollector-graphite from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aa78e57 ] CLOUDSTACK-7583: Send VmStats to Graphite host when configured This allows external processing of VmStats information without using the usage server of CloudStack Send statistics collected by StatsCollector to optional Graphite host - Key: CLOUDSTACK-7583 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7583 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: Wido den Hollander Assignee: Wido den Hollander Fix For: Future It would be very useful if the StatsCollector inside the management server could also send all the stats collected to a Graphite server in addition to the usage database. This allows for easy graph generation for CPU, Network and Disk I/O of Instances and hosts. Via a global setting we can configure: * Graphite host * Graphite port * Key prefix We can then send Instance and Host information, like: cloudstack.stats.instances.vm id.cpu.num 1 cloudstack.stats.instances.vm id.cpu.utilization 50 cloudstack.stats.instances.vm id.network.read_kbs 4817 cloudstack.stats.instances.vm id.network.write_kbs 672 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7583) Send statistics collected by StatsCollector to optional Graphite host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146036#comment-14146036 ] ASF subversion and git services commented on CLOUDSTACK-7583: - Commit f7de57d92aadc01f605873ccb4652eeea15ebba6 in cloudstack's branch refs/heads/statscollector-graphite from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f7de57d ] CLOUDSTACK-7583: Send VmStats to Graphite host when configured This allows external processing of VmStats information without using the usage server of CloudStack Send statistics collected by StatsCollector to optional Graphite host - Key: CLOUDSTACK-7583 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7583 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: Wido den Hollander Assignee: Wido den Hollander Fix For: Future It would be very useful if the StatsCollector inside the management server could also send all the stats collected to a Graphite server in addition to the usage database. This allows for easy graph generation for CPU, Network and Disk I/O of Instances and hosts. Via a global setting we can configure: * Graphite host * Graphite port * Key prefix We can then send Instance and Host information, like: cloudstack.stats.instances.vm id.cpu.num 1 cloudstack.stats.instances.vm id.cpu.utilization 50 cloudstack.stats.instances.vm id.network.read_kbs 4817 cloudstack.stats.instances.vm id.network.write_kbs 672 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146070#comment-14146070 ] Alex Brett commented on CLOUDSTACK-7621: Looking at the history, I see the following two schema changes between a working build and a broken one: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=872b48b0c34d85d934344c8ccf33fa328d2748ed https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=b3c117a11eda3373a5a7187547a441be908f4453 [~pdion] could this be a side effect of these? Database schema not getting upgraded Key: CLOUDSTACK-7621 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: management-server.log After installing management server , the process is stuck at database schema update. The update doesn't progress ahead from 4.0.0 mysql select * from version; ++-+-+--+ | id | version | updated | step | ++-+-+--+ | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | ++-+-+--+ 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7621) Database schema not getting upgraded
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146076#comment-14146076
]
Alex Brett commented on CLOUDSTACK-7621:
Also from localhost log on another run:
{noformat}
SEVERE: Exception sending context initialized event to listener instance of
class org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener
org.springframework.context.ApplicationContextException: Failed to start bean
'cloudStackLifeCycle'; nested exception is
com.cloud.utils.exception.CloudRuntimeException: Caught: null
at
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:170)
at
org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
at
org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339)
at
org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143)
at
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:108)
at
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:945)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:79)
at
org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:57)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:61)
at
org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:52)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4467)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
at
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:516)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:593)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at
[jira] [Closed] (CLOUDSTACK-5851) add a nic to vm failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye closed CLOUDSTACK-5851. -- Resolution: Incomplete Closing because no further updates from Zhenglei add a nic to vm failed -- Key: CLOUDSTACK-5851 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5851 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.1.0 Environment: cloudstack4.1.0 and xenserver6.0 Reporter: zhenglei 1. Create a vm successfully in an advanced zone. 2. Create a network with the default networkoffering successfully. There is no vm in the network now, and also the vrouter is not started. 3. Add the network to the vm by calling the restful api successfully. 4. But when I login the cloudstack ui, I find the new network vrouter is not started and its status is ”starting“. so add nic operation is failed. 5. I want to check the vrouter by xencenter, but there is no this vrouter. 6. At last, i check the management server log files, There is no any ERROR and Exception. I think the reason is the vrouter is not started, But i don't know why. I also do some add nic or remove nic tests when a vrouer is running, and it is normal. so, why?Thanks... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146109#comment-14146109 ] Sanjeev N commented on CLOUDSTACK-7621: --- Observed this even on the simulator environment. Database schema not getting upgraded Key: CLOUDSTACK-7621 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: management-server.log After installing management server , the process is stuck at database schema update. The update doesn't progress ahead from 4.0.0 mysql select * from version; ++-+-+--+ | id | version | updated | step | ++-+-+--+ | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | ++-+-+--+ 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7617) [Automation] Fix the script test_clustom_hostname.py - Do not use the same name to deploy multiple VMs.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Aradhye reassigned CLOUDSTACK-7617:
--
Assignee: Gaurav Aradhye
[Automation] Fix the script test_clustom_hostname.py - Do not use the same
name to deploy multiple VMs.
-
Key: CLOUDSTACK-7617
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7617
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Gaurav Aradhye
Priority: Critical
Fix For: 4.5.0
The below mentioned code is resulting in multiple test case failures in the
test suite. We should not use the same name to deploy multiple VMs in the
test suite.
{code}
def test_04_edit_display_name(self):
Test Edit the Display name Through the UI.
# Validate the following
# 1) Set the Global Setting vm.instancename.flag to true
# 2) Create a VM give a Display name.
# 3) Once the VM is created stop the VM.
# 4) Edit the VM Display name. The Display name will be changed but
the
#internal name will not be changed. The VM functionality must not
#be effected.
self.services[virtual_machine][name] = TestVM4
# Spawn an instance in that network
self.debug(Deploying VM in account: %s % self.account.name)
virtual_machine = VirtualMachine.create(
self.apiclient,
self.services[virtual_machine],
accountid=self.account.name,
domainid=self.account.domainid,
serviceofferingid=self.service_offering.id,
)
{code}
*Error:*
{noformat}
Stacktrace
File /usr/lib/python2.7/unittest/case.py, line 332, in run
testMethod()
File /root/cloudstack/test/integration/component/test_custom_hostname.py,
line 540, in test_instance_name_with_hyphens
serviceofferingid=self.service_offering.id,
File /usr/local/lib/python2.7/dist-packages/marvin/lib/base.py, line 476,
in create
virtual_machine = apiclient.deployVirtualMachine(cmd, method=method)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 706, in deployVirtualMachine
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line
379, in marvinRequest
raise e
'Execute cmd: deployvirtualmachine failed, due to: errorCode: 431,
errorText:The vm with hostName TestVM4 already exists in the network domain:
cscbcloud.internal; network=Ntwk[373|Guest|8]\n
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally updated CLOUDSTACK-7621: - Attachment: localhost.2014-09-24.log Database schema not getting upgraded Key: CLOUDSTACK-7621 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: localhost.2014-09-24.log, management-server.log After installing management server , the process is stuck at database schema update. The update doesn't progress ahead from 4.0.0 mysql select * from version; ++-+-+--+ | id | version | updated | step | ++-+-+--+ | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | ++-+-+--+ 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7574) Fail to create Windows 2012r2 VM with OS type: Windows Server 2012 R2 (64-bit)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146181#comment-14146181 ] ASF subversion and git services commented on CLOUDSTACK-7574: - Commit df4d5ede901eb9cdce4b2bd905ea476d28f6b248 in cloudstack's branch refs/heads/4.4 from [~pdion] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=df4d5ed ] CLOUDSTACK-7574, CREATE TABLE cloud.baremetal_rct Fail to create Windows 2012r2 VM with OS type: Windows Server 2012 R2 (64-bit) -- Key: CLOUDSTACK-7574 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7574 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: ISO, XenServer Affects Versions: 4.4.0, 4.4.1 Reporter: Pierre-Luc Dion Assignee: Pierre-Luc Dion Priority: Minor Cannot create Windows 2012r2 VM from an ISO with OS type: Windows Server 2012 R2 (64-bit), if the OS type is Windows Server 2012 (64-bit) The VM will succeed to create and boot from the iso. This as been reported by motty.c...@gmail.com. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7536) user vm can get a gateway ip in case of shared network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7536: - Status: Reviewable (was: In Progress) user vm can get a gateway ip in case of shared network. --- Key: CLOUDSTACK-7536 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7536 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: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 steps to reproduce. 1.) create a shared network with the following details. gateway 10.136.10.1 netmask 255.255.255.0 guest ip range 10.136.10.1 to 10.136.10.20 (note that the gateway ip is a part of the guest ip range.) 2.) deploy a vm the gateway ip gets allocated to a uservm. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7536) user vm can get a gateway ip in case of shared network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146188#comment-14146188 ] Bharat Kumar commented on CLOUDSTACK-7536: -- https://reviews.apache.org/r/25991/ user vm can get a gateway ip in case of shared network. --- Key: CLOUDSTACK-7536 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7536 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: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 steps to reproduce. 1.) create a shared network with the following details. gateway 10.136.10.1 netmask 255.255.255.0 guest ip range 10.136.10.1 to 10.136.10.20 (note that the gateway ip is a part of the guest ip range.) 2.) deploy a vm the gateway ip gets allocated to a uservm. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7598) Cloudstack VM State is not in sync with state from Hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devdeep Singh reassigned CLOUDSTACK-7598: - Assignee: Devdeep Singh Cloudstack VM State is not in sync with state from Hypervisor - Key: CLOUDSTACK-7598 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7598 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: XenServer Affects Versions: 4.5.0 Reporter: Sailaja Mada Assignee: Devdeep Singh Priority: Blocker Fix For: 4.5.0 Attachments: vmsynclogs.rar Steps: 1. Install and configure Adv zone using XS 6.5 Hypervisor 2. Deploy Linux VM , Windows VM 3. After VM is up and running login to the VM and shutdown the instance 4. It moved to Shutdown state in the hypervisor 5. But this state is not synced to cloudstack and it remained in running state in cloudstack Observation: Cloudstack VM State is not in sync with state from Hypervisor Ob -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7534) ResetVM for VM with attached datadisk fails when enable.ha.storage.migration is false
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146205#comment-14146205 ] ASF subversion and git services commented on CLOUDSTACK-7534: - Commit c55bc0b2d11be4820a24af426e23da3db54a0cb1 in cloudstack's branch refs/heads/master from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c55bc0b ] CLOUDSTACK-7534: ResetVM for VM with attached datadisk fails when enable.ha.storage.migration is false Separate global config to enable/disable Storage Migration during normal deployment Introduced a configuration parameter named enable.storage.migration ResetVM for VM with attached datadisk fails when enable.ha.storage.migration is false - Key: CLOUDSTACK-7534 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7534 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Fix For: 4.5.0 ResetVM for a VM having a attached datadisk fails if, 1. there are 2 or more storage pools in the cluster 2. enable.ha.storage.migration is set to false 3. allocator has chosen a different pool for the datadisk than where it currently exists and migration from one pool to another failed because enable.ha.storage.migration set to false. The issue is currently enable.ha.storage.migration applies to both normal and HA deployment. We should have another parameter which is specific to normal deployments (say enable.storage.migration) so that during migration check we can clearly differentiate normal and HA deployments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7534) ResetVM for VM with attached datadisk fails when enable.ha.storage.migration is false
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala resolved CLOUDSTACK-7534. - Resolution: Fixed ResetVM for VM with attached datadisk fails when enable.ha.storage.migration is false - Key: CLOUDSTACK-7534 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7534 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Fix For: 4.5.0 ResetVM for a VM having a attached datadisk fails if, 1. there are 2 or more storage pools in the cluster 2. enable.ha.storage.migration is set to false 3. allocator has chosen a different pool for the datadisk than where it currently exists and migration from one pool to another failed because enable.ha.storage.migration set to false. The issue is currently enable.ha.storage.migration applies to both normal and HA deployment. We should have another parameter which is specific to normal deployments (say enable.storage.migration) so that during migration check we can clearly differentiate normal and HA deployments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7598) Cloudstack VM State is not in sync with state from Hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146216#comment-14146216 ] Devdeep Singh edited comment on CLOUDSTACK-7598 at 9/24/14 11:22 AM: - As part of commit 7f440854f7bcd41a1bd6581c0239cde2e98261b7, the directagentattache was updated to retry PingCommand to deal with network glitches. However, there is a minor bug in the logic because of which the agent attache is never sending the PingCommand. The vm state is retrieved as part of this ping command. So if a vm is stopped on the hypervisor, cloudstack will never update the state of the vms in its db. The retry logic needs to be fixed to make sure the command is send atleast once. was (Author: devdeep): As part of commit 7f440854f7bcd41a1bd6581c0239cde2e98261b7, the directagentattache was updated to retry PingCommand to deal with network glitches. However, there is a minor bug in the logic because of which the agent attache is never sending the PingCommand. The vm state is retrieved as part of this ping command. So if a vm is stopped on the hypervisor, cloudstack will never update the state of the vms in its db. The retyr logic needs to be fixed to make sure the command is send atleast once. Cloudstack VM State is not in sync with state from Hypervisor - Key: CLOUDSTACK-7598 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7598 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: XenServer Affects Versions: 4.5.0 Reporter: Sailaja Mada Assignee: Devdeep Singh Priority: Blocker Fix For: 4.5.0 Attachments: vmsynclogs.rar Steps: 1. Install and configure Adv zone using XS 6.5 Hypervisor 2. Deploy Linux VM , Windows VM 3. After VM is up and running login to the VM and shutdown the instance 4. It moved to Shutdown state in the hypervisor 5. But this state is not synced to cloudstack and it remained in running state in cloudstack Observation: Cloudstack VM State is not in sync with state from Hypervisor Ob -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7598) Cloudstack VM State is not in sync with state from Hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146216#comment-14146216 ] Devdeep Singh commented on CLOUDSTACK-7598: --- As part of commit 7f440854f7bcd41a1bd6581c0239cde2e98261b7, the directagentattache was updated to retry PingCommand to deal with network glitches. However, there is a minor bug in the logic because of which the agent attache is never sending the PingCommand. The vm state is retrieved as part of this ping command. So if a vm is stopped on the hypervisor, cloudstack will never update the state of the vms in its db. The retyr logic needs to be fixed to make sure the command is send atleast once. Cloudstack VM State is not in sync with state from Hypervisor - Key: CLOUDSTACK-7598 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7598 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: XenServer Affects Versions: 4.5.0 Reporter: Sailaja Mada Assignee: Devdeep Singh Priority: Blocker Fix For: 4.5.0 Attachments: vmsynclogs.rar Steps: 1. Install and configure Adv zone using XS 6.5 Hypervisor 2. Deploy Linux VM , Windows VM 3. After VM is up and running login to the VM and shutdown the instance 4. It moved to Shutdown state in the hypervisor 5. But this state is not synced to cloudstack and it remained in running state in cloudstack Observation: Cloudstack VM State is not in sync with state from Hypervisor Ob -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7571) changing value of cpu/mem.overprovisioning.factor for xen cluster is not affecting total memory at zone level
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146223#comment-14146223 ] ASF subversion and git services commented on CLOUDSTACK-7571: - Commit 476733cb92634c8494fe64762d7fbc178292a754 in cloudstack's branch refs/heads/master from [~bharat.kumar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=476733c ] CLOUDSTACK-7571 changing value of cpu/mem.overprovisioning.factor for xen cluster is not affecting total memory at zone level changing value of cpu/mem.overprovisioning.factor for xen cluster is not affecting total memory at zone level - Key: CLOUDSTACK-7571 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7571 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 steps to reproduce == 1-prepare a CS3.6 setup with vmware and xen cluster 2-set mem.overprovisioning.factor=3 and cpu.overprovisioning.factor=2 2-upgrade it to CCP4.3 3-record total memory and cpu at zone level 4-change cpu/memory overprovisioning for xen server cluster to some valid value expected = at zone level total memory should get changed , depends on overprovisioning value Actual === 1-total memory is not getting changed at zone level 2-but total memory/cpu of xen cluster is getting changed with overprovisioning factor My observation == 1-if i change overspovisioning factor of vmware cluster total memory is getting changed 2-In fresh setup with one xen cluster i did not see this problem -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7583) Send statistics collected by StatsCollector to optional Graphite host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146225#comment-14146225 ] ASF subversion and git services commented on CLOUDSTACK-7583: - Commit e4d2ab32f60e94e5610bca6444b122bc85f10b58 in cloudstack's branch refs/heads/statscollector-graphite from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e4d2ab3 ] CLOUDSTACK-7583: Send VmStats to Graphite host when configured This allows external processing of VmStats information without using the usage server of CloudStack Statistics are being send to Graphite using UDP and not TCP. UDP is used to prevent the management server waiting for TCP timeouts when the Graphite server is unavailable Send statistics collected by StatsCollector to optional Graphite host - Key: CLOUDSTACK-7583 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7583 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: Wido den Hollander Assignee: Wido den Hollander Fix For: Future It would be very useful if the StatsCollector inside the management server could also send all the stats collected to a Graphite server in addition to the usage database. This allows for easy graph generation for CPU, Network and Disk I/O of Instances and hosts. Via a global setting we can configure: * Graphite host * Graphite port * Key prefix We can then send Instance and Host information, like: cloudstack.stats.instances.vm id.cpu.num 1 cloudstack.stats.instances.vm id.cpu.utilization 50 cloudstack.stats.instances.vm id.network.read_kbs 4817 cloudstack.stats.instances.vm id.network.write_kbs 672 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett resolved CLOUDSTACK-7621. Resolution: Fixed Appears to be fixed by https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=2503aaafef5280ce20e319c77623f9709d85151a which reverted [~anthonyxu]'s commit https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=093fa6f0a53bd031a09e4042c3aa25860bc947e5 Looks to be just a coincidence that some schema changes came in at the same time - apologies for any confusion... Database schema not getting upgraded Key: CLOUDSTACK-7621 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: localhost.2014-09-24.log, management-server.log After installing management server , the process is stuck at database schema update. The update doesn't progress ahead from 4.0.0 mysql select * from version; ++-+-+--+ | id | version | updated | step | ++-+-+--+ | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | ++-+-+--+ 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally closed CLOUDSTACK-7621. Working fine after the commit 093fa6f0a53bd031a09e4042c3aa25860bc947e5 has been reverted. Database schema not getting upgraded Key: CLOUDSTACK-7621 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: localhost.2014-09-24.log, management-server.log After installing management server , the process is stuck at database schema update. The update doesn't progress ahead from 4.0.0 mysql select * from version; ++-+-+--+ | id | version | updated | step | ++-+-+--+ | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | ++-+-+--+ 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7590) Deletion of Account is not deleting the account from the database
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146244#comment-14146244
]
Rahul Rege commented on CLOUDSTACK-7590:
I tried to reproduce this on 4.4 first but it works correctly. It does create
multiple users inside the db with same name on subsequent removal and addition
of accounts but does not give any error of user already present when its
removed. I then upgraded to 4.5 and during upgrade itself it failed because I
had 2 deleted users in the db with same name. So, I had to redeploy the db and
given that it is not allowing the same username, I am sure it will give the
error.
The db schema has changed in 4.5 which has caused this issue and it would fail
to create a new user with same name and also during upgrades in case you have
recreated any users in the past on earlier versions, it will not migrate the db
due to different schema (unless there is another way to do it)
Fixing the db schema seems to be the right choice here than removing the user
alltogether in case they are using it for some auditing purpose.
Deletion of Account is not deleting the account from the database
-
Key: CLOUDSTACK-7590
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7590
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
Fix For: 4.5.0
Deletion of account marks the account as removed in the database but doesnt
remove the record from the database as shown below:
mysql select * from account where removed is not null \G
*** 1. row ***
id: 7
account_name: CSRegularVPNClientUser
uuid: 96e06a77-fa96-4e38-b380-023d406d445e
type: 0
domain_id: 1
state: enabled
removed: 2014-09-20 00:33:41
cleanup_needed: 0
network_domain: NULL
default_zone_id: NULL
default: 0
1 row in set (0.00 sec)
mysql
*If anyone wants to recreate the account with the same name. It fails with
the below exception:*
{noformat}
2014-09-20 00:27:05,880 DEBUG [c.c.u.AccountManagerImpl]
(catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Creating user:
CSRegularVPNClientUser, accountId: 6 timezone:null
2014-09-20 00:27:05,882 DEBUG [c.c.u.d.T.Transaction]
(catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Rolling back the
transaction: Time = 16 Name = catalina-exec-11; called by
-TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy67.persist:-1-AccountManagerImpl.createUser:1962-AccountManagerImpl$2.doInTransaction:1039-AccountManagerImpl$2.doInTransaction:1027
2014-09-20 00:27:05,898 ERROR [c.c.a.ApiServer]
(catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) unhandled exception
executing api command: [Ljava.lang.String;@5b4cfa82
javax.persistence.EntityExistsException: Entity already exists:
at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1398)
at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:141)
at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:33)
at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy67.persist(Unknown Source)
at
[jira] [Created] (CLOUDSTACK-7622) Can't delete the network when providers this network uses, are disabled
Jayapal Reddy created CLOUDSTACK-7622: - Summary: Can't delete the network when providers this network uses, are disabled Key: CLOUDSTACK-7622 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7622 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.0.0 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Fix For: 4.5.0 Steps to reproduce: create network, use VR as a provider for its services disable VR provider try to delete the network. Shutdown network fails due to disabled provider. Shutdown should be successful even when provider is disabled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7590) Deletion of Account is not deleting the account from the database
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146253#comment-14146253
]
Rahul Rege commented on CLOUDSTACK-7590:
This blocker tracks the schema changes for 4.5
Deletion of Account is not deleting the account from the database
-
Key: CLOUDSTACK-7590
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7590
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
Fix For: 4.5.0
Deletion of account marks the account as removed in the database but doesnt
remove the record from the database as shown below:
mysql select * from account where removed is not null \G
*** 1. row ***
id: 7
account_name: CSRegularVPNClientUser
uuid: 96e06a77-fa96-4e38-b380-023d406d445e
type: 0
domain_id: 1
state: enabled
removed: 2014-09-20 00:33:41
cleanup_needed: 0
network_domain: NULL
default_zone_id: NULL
default: 0
1 row in set (0.00 sec)
mysql
*If anyone wants to recreate the account with the same name. It fails with
the below exception:*
{noformat}
2014-09-20 00:27:05,880 DEBUG [c.c.u.AccountManagerImpl]
(catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Creating user:
CSRegularVPNClientUser, accountId: 6 timezone:null
2014-09-20 00:27:05,882 DEBUG [c.c.u.d.T.Transaction]
(catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Rolling back the
transaction: Time = 16 Name = catalina-exec-11; called by
-TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy67.persist:-1-AccountManagerImpl.createUser:1962-AccountManagerImpl$2.doInTransaction:1039-AccountManagerImpl$2.doInTransaction:1027
2014-09-20 00:27:05,898 ERROR [c.c.a.ApiServer]
(catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) unhandled exception
executing api command: [Ljava.lang.String;@5b4cfa82
javax.persistence.EntityExistsException: Entity already exists:
at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1398)
at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:141)
at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:33)
at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy67.persist(Unknown Source)
at
com.cloud.user.AccountManagerImpl.createUser(AccountManagerImpl.java:1962)
at
com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1039)
at
com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1027)
at
com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49)
at com.cloud.utils.db.Transaction.execute(Transaction.java:37)
at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
at
com.cloud.user.AccountManagerImpl.createUserAccount(AccountManagerImpl.java:1027)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
[jira] [Commented] (CLOUDSTACK-7622) Can't delete the network when providers this network uses, are disabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146267#comment-14146267
]
Jayapal Reddy commented on CLOUDSTACK-7622:
---
MS logs:
2014-09-24 15:35:18,719 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(1949422689@qtp-2019457093-0:ctx-fe1d81bc ctx-ecb8d94c) submit async job-29,
details: AsyncJobVO {id:29, userId: 2, accountId: 2, instanceType: None,
instanceId: null, cmd: com.cloud.api.commands.AddSrxFirewallCmd, cmdInfo:
{physicalnetworkid:5a343691-932d-4f4c-9e65-da754b5b93cb,sessionkey:0is9qGB4EiFibf2X7eQD8KKitIs\u003d,cmdEventType:PHYSICAL.FIREWALL.ADD,ctxUserId:2,httpmethod:POST,password:password,url:https://10.147.40.3?publicinterface\u003dfe00\u0026privateinterface\u003dfe01\u0026numretries\u003d2\u0026timeout\u003d300\u0026fwdevicededicated\u003dfalse,response:json,ctxDetails:{\com.cloud.network.PhysicalNetwork\:\5a343691-932d-4f4c-9e65-da754b5b93cb\},username:admin,networkdevicetype:JuniperSRXFirewall,ctxAccountId:2,ctxStartEventId:78},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 1, completeMsid: null, lastUpdated: null, lastPolled: null,
created: null}
2014-09-24 15:35:18,720 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-2:ctx-5ec8cde4 job-29) Add job-29 into job monitoring
2014-09-24 15:35:18,721 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-2:ctx-5ec8cde4 job-29) Executing AsyncJobVO {id:29, userId:
2, accountId: 2, instanceType: None, instanceId: null, cmd:
com.cloud.api.commands.AddSrxFirewallCmd, cmdInfo:
{physicalnetworkid:5a343691-932d-4f4c-9e65-da754b5b93cb,sessionkey:0is9qGB4EiFibf2X7eQD8KKitIs\u003d,cmdEventType:PHYSICAL.FIREWALL.ADD,ctxUserId:2,httpmethod:POST,password:password,url:https://10.147.40.3?publicinterface\u003dfe00\u0026privateinterface\u003dfe01\u0026numretries\u003d2\u0026timeout\u003d300\u0026fwdevicededicated\u003dfalse,response:json,ctxDetails:{\com.cloud.network.PhysicalNetwork\:\5a343691-932d-4f4c-9e65-da754b5b93cb\},username:admin,networkdevicetype:JuniperSRXFirewall,ctxAccountId:2,ctxStartEventId:78},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 1, completeMsid: null, lastUpdated: null, lastPolled: null,
created: null}
Can't delete the network when providers this network uses, are disabled
---
Key: CLOUDSTACK-7622
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7622
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.0.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
Fix For: 4.5.0
Steps to reproduce:
create network, use VR as a provider for its services
disable VR provider
try to delete the network. Shutdown network fails due to disabled provider.
Shutdown should be successful even when provider is disabled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7623) SystemVMs not getting created on VmWare
Pavan Kumar Bandarupally created CLOUDSTACK-7623: Summary: SystemVMs not getting created on VmWare Key: CLOUDSTACK-7623 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 After installing latest Management Server and zone creation, system VMs are not getting created. The following exception is being generated: 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . Waited for 0seconds 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console proxy com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock vm_instance1 . Waited for 0seconds at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) at com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) at com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy53.lockInLockTable(Unknown Source) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) at com.cloud.utils.db.Transaction.execute(Transaction.java:37) at com.cloud.utils.db.Transaction.execute(Transaction.java:46) at com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) at com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) at com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at
[jira] [Updated] (CLOUDSTACK-7623) SystemVMs not getting created on VmWare
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally updated CLOUDSTACK-7623: - Attachment: management-server.log SystemVMs not getting created on VmWare --- Key: CLOUDSTACK-7623 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: management-server.log After installing latest Management Server and zone creation, system VMs are not getting created. The following exception is being generated: 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . Waited for 0seconds 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console proxy com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock vm_instance1 . Waited for 0seconds at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) at com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) at com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy53.lockInLockTable(Unknown Source) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) at com.cloud.utils.db.Transaction.execute(Transaction.java:37) at com.cloud.utils.db.Transaction.execute(Transaction.java:46) at com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) at com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) at com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at
[jira] [Updated] (CLOUDSTACK-7623) SystemVMs not starting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett updated CLOUDSTACK-7623: --- Summary: SystemVMs not starting (was: SystemVMs not getting created on VmWare) SystemVMs not starting -- Key: CLOUDSTACK-7623 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: management-server.log After installing latest Management Server and zone creation, system VMs are not getting created. The following exception is being generated: 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . Waited for 0seconds 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console proxy com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock vm_instance1 . Waited for 0seconds at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) at com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) at com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy53.lockInLockTable(Unknown Source) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) at com.cloud.utils.db.Transaction.execute(Transaction.java:37) at com.cloud.utils.db.Transaction.execute(Transaction.java:46) at com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) at com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) at com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at
[jira] [Updated] (CLOUDSTACK-3367) When one primary storage fails, all XenServer hosts get rebooted, killing all VMs, even those not on this primary storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] France updated CLOUDSTACK-3367: --- Affects Version/s: 4.3.1 4.5.0 When one primary storage fails, all XenServer hosts get rebooted, killing all VMs, even those not on this primary storage. -- Key: CLOUDSTACK-3367 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3367 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.1.0, 4.2.0, 4.5.0, 4.3.1 Environment: CentOS 6.3, XenServer 6.0.2 + all hotfixes, CloudStack 4.1.0 Reporter: France Fix For: Future As the title says: if only one of the primary storages fails, all XenServer hosts get rebooted one by one. Because i have many primary storages, which are/were running fine with other VMs, rebooting XenServer Hipervisor is an overkill. Please disable this or implement just stopping/killing the VMs running on that storage and try to re-attach that storage only. Problem was reported on the mailing list, as well as a workaround for XenServer. So i'm not the only one hit by this bug/feature. Workaround for now is as follows: 1. Modify /opt/xensource/bin/xenheartbeat.sh on all your Hosts, commenting out the two entries which have reboot -f 2. Identify the PID of the script - pidof -x xenheartbeat.sh 3. Restart the Script - kill pid 4. Force reconnect Host from the UI, the script will then re-launch on reconnect -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-3367) When one primary storage fails, all XenServer hosts get rebooted, killing all VMs, even those not on this primary storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146276#comment-14146276 ] France commented on CLOUDSTACK-3367: Anyone willing to pick this up? It has been well over a year by now. :-( When one primary storage fails, all XenServer hosts get rebooted, killing all VMs, even those not on this primary storage. -- Key: CLOUDSTACK-3367 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3367 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.1.0, 4.2.0, 4.5.0, 4.3.1 Environment: CentOS 6.3, XenServer 6.0.2 + all hotfixes, CloudStack 4.1.0 Reporter: France Fix For: Future As the title says: if only one of the primary storages fails, all XenServer hosts get rebooted one by one. Because i have many primary storages, which are/were running fine with other VMs, rebooting XenServer Hipervisor is an overkill. Please disable this or implement just stopping/killing the VMs running on that storage and try to re-attach that storage only. Problem was reported on the mailing list, as well as a workaround for XenServer. So i'm not the only one hit by this bug/feature. Workaround for now is as follows: 1. Modify /opt/xensource/bin/xenheartbeat.sh on all your Hosts, commenting out the two entries which have reboot -f 2. Identify the PID of the script - pidof -x xenheartbeat.sh 3. Restart the Script - kill pid 4. Force reconnect Host from the UI, the script will then re-launch on reconnect -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7623) SystemVMs not starting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146277#comment-14146277 ] Alex Brett commented on CLOUDSTACK-7623: Based on the exception text I imagine https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=d8ad3e32bc6ee41d576fa99473834485a5266f93 is the cause here - it turned something that was returning false in to raising the exception we're seeing... SystemVMs not starting -- Key: CLOUDSTACK-7623 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: management-server.log After installing latest Management Server and zone creation, system VMs are not getting created. The following exception is being generated: 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . Waited for 0seconds 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console proxy com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock vm_instance1 . Waited for 0seconds at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) at com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) at com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy53.lockInLockTable(Unknown Source) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) at com.cloud.utils.db.Transaction.execute(Transaction.java:37) at com.cloud.utils.db.Transaction.execute(Transaction.java:46) at com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) at com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) at com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at
[jira] [Assigned] (CLOUDSTACK-6631) unable to attach new Volume to VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty reassigned CLOUDSTACK-6631:
--
Assignee: Likitha Shetty
unable to attach new Volume to VM
-
Key: CLOUDSTACK-6631
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
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: Cloudstack 4.2.1 + KVM on CentOS 6.4
Reporter: Kazuhiro Ito
Assignee: Likitha Shetty
Attachments: management-server.log.0521
1. I added new volume.
2. I tried to attach the volume to a VM on UI.
3. It failed and the following log appeared.
2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet]
(http-6443-exec-116:null) ===START=== 133.xx.xxx.xxx -- GET
command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl]
(http-6443-exec-116:null) submit async job-4916 = [
dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId:
3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543,
cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd,
cmdOriginator: null, cmdInfo:
{response:json,id:ac7099fb-ac66-4c63-bf1e-ed0e1429f412,sessionkey:TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d,cmdEventType:VOLUME.ATTACH,ctxUserId:3,virtualMachineId:ecdc2c1d-e21e-4c04-962a-4efac1a69a74,httpmethod:GET,_:1399861774316,ctxAccountId:3,ctxStartEventId:34276},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for
job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet]
(http-6443-exec-116:null) ===END=== 133.xx.xxx.xxx -- GET
command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to
Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
DomainChecker_EnhancerByCloudStack_9b413459
2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
to VM[User|TEST-A2-VM01] granted to
Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
DomainChecker_EnhancerByCloudStack_9b413459
2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
LocalStoragePoolAllocator trying to find storage pool to fit the vm
2014-05-12 11:29:47,212 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
ClusterScopeStoragePoolAllocator looking for storage pool
2014-05-12 11:29:47,212 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Looking for pools in dc: 1 pod:1 cluster:null having tags:[MPI]
2014-05-12 11:29:47,216 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No
storage pools available for shared volume allocation, returning
2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Unexpected exception while executing
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
com.cloud.utils.exception.CloudRuntimeException: Caught: SELECT pool.id,
SUM(IF(vol.state='Ready' AND vol.account_id = ?, 1, 0)) FROM
`cloud`.`storage_pool` pool LEFT JOIN `cloud`.`volumes` vol ON pool.id =
vol.pool_id WHERE pool.data_center_id = ? AND pool.pod_id = ? AND
pool.cluster_id = ? GROUP BY pool.id ORDER BY 2 ASC
at
com.cloud.storage.dao.VolumeDaoImpl.listPoolIdsByVolumeCount(VolumeDaoImpl.java:480)
at
[jira] [Commented] (CLOUDSTACK-6631) unable to attach new Volume to VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146309#comment-14146309
]
Likitha Shetty commented on CLOUDSTACK-6631:
To attach a volume to a VM, CCP creates the volume in primary storage if it
hasn't already been created. During this creation, CCP tries to select a
storage pool to deploy the volume in.
And the storage pool selection fails with the error you mentioned if the
following two conditions are met -
1. ROOT volume of the VM we are trying to attach a datadisk to is in a
zone-wide primary storage.
2. Global config vm.allocation.algorithm is set to userdispersing.
Is the above true in your case?
unable to attach new Volume to VM
-
Key: CLOUDSTACK-6631
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
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: Cloudstack 4.2.1 + KVM on CentOS 6.4
Reporter: Kazuhiro Ito
Assignee: Likitha Shetty
Attachments: management-server.log.0521
1. I added new volume.
2. I tried to attach the volume to a VM on UI.
3. It failed and the following log appeared.
2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet]
(http-6443-exec-116:null) ===START=== 133.xx.xxx.xxx -- GET
command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl]
(http-6443-exec-116:null) submit async job-4916 = [
dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId:
3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543,
cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd,
cmdOriginator: null, cmdInfo:
{response:json,id:ac7099fb-ac66-4c63-bf1e-ed0e1429f412,sessionkey:TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d,cmdEventType:VOLUME.ATTACH,ctxUserId:3,virtualMachineId:ecdc2c1d-e21e-4c04-962a-4efac1a69a74,httpmethod:GET,_:1399861774316,ctxAccountId:3,ctxStartEventId:34276},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for
job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet]
(http-6443-exec-116:null) ===END=== 133.xx.xxx.xxx -- GET
command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to
Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
DomainChecker_EnhancerByCloudStack_9b413459
2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
to VM[User|TEST-A2-VM01] granted to
Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
DomainChecker_EnhancerByCloudStack_9b413459
2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
LocalStoragePoolAllocator trying to find storage pool to fit the vm
2014-05-12 11:29:47,212 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
ClusterScopeStoragePoolAllocator looking for storage pool
2014-05-12 11:29:47,212 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Looking for pools in dc: 1 pod:1 cluster:null having tags:[MPI]
2014-05-12 11:29:47,216 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No
storage pools available for shared volume allocation, returning
2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Unexpected exception while executing
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
com.cloud.utils.exception.CloudRuntimeException:
[jira] [Updated] (CLOUDSTACK-7574) Fail to create Windows 2012r2 VM with OS type: Windows Server 2012 R2 (64-bit)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7574: Fix Version/s: 4.4.1 Fail to create Windows 2012r2 VM with OS type: Windows Server 2012 R2 (64-bit) -- Key: CLOUDSTACK-7574 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7574 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: ISO, XenServer Affects Versions: 4.4.0, 4.4.1 Reporter: Pierre-Luc Dion Assignee: Pierre-Luc Dion Priority: Minor Fix For: 4.4.1 Cannot create Windows 2012r2 VM from an ISO with OS type: Windows Server 2012 R2 (64-bit), if the OS type is Windows Server 2012 (64-bit) The VM will succeed to create and boot from the iso. This as been reported by motty.c...@gmail.com. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7538) Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146318#comment-14146318 ] Saksham Srivastava commented on CLOUDSTACK-7538: Created https://issues.apache.org/jira/browse/CLOUDSTACK-7548 Fixed on master https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=8c671c4;hp=6379ca4548b8329f2492fa7f142c4946bef8d55e Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule -- Key: CLOUDSTACK-7538 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7538 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0, 4.5.0 Reporter: Wei Zhou Assignee: Wei Zhou Fix For: 4.5.0, 4.4.1 When I tried to remove a nic from a VM, an exception raised: 2014-09-08 10:07:12,847 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. at com.cloud.vm.VirtualMachineManagerImpl.removeNicFromVm(VirtualMachineManagerImpl.java:3129) at com.cloud.vm.UserVmManagerImpl.removeNicFromVirtualMachine(UserVmManagerImpl.java:1068) at org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd.execute(RemoveNicFromVMCmd.java:103) 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) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) 2014-09-08 10:07:12,849 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Complete async job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. This is because there is another vm (with same internal ip) having port forward rules . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7624) Long hostnames cause CloudStack to die with an encryption error during startup
Hugo Trippaers created CLOUDSTACK-7624: -- Summary: Long hostnames cause CloudStack to die with an encryption error during startup Key: CLOUDSTACK-7624 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7624 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: Future, 4.4.0 Reporter: Hugo Trippaers Assignee: Hugo Trippaers Fix For: 4.4.1 Machines with a long hostname will have a longer certificate in cloud.keystore. When encrypted this certificate will be longer than 4095 which is the maximum length of the database field. When the value is read back the stripped value is returned and the decryption routine will throw an error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7624) Long hostnames cause CloudStack to die with an encryption error during startup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146422#comment-14146422 ] ASF subversion and git services commented on CLOUDSTACK-7624: - Commit 9eb86560c9b83456be9ee32e8b713b213baed7bb in cloudstack's branch refs/heads/hotfix/4.4/CLOUDSTACK-7624 from [~htrippaers] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9eb8656 ] CLOUDSTACK-7624 The value field of the configuration table is not big enough for some values Long hostnames cause CloudStack to die with an encryption error during startup -- Key: CLOUDSTACK-7624 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7624 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: Future, 4.4.0 Reporter: Hugo Trippaers Assignee: Hugo Trippaers Fix For: 4.4.1 Machines with a long hostname will have a longer certificate in cloud.keystore. When encrypted this certificate will be longer than 4095 which is the maximum length of the database field. When the value is read back the stripped value is returned and the decryption routine will throw an error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7624) Long hostnames cause CloudStack to die with an encryption error during startup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146426#comment-14146426 ] ASF subversion and git services commented on CLOUDSTACK-7624: - Commit 9eb86560c9b83456be9ee32e8b713b213baed7bb in cloudstack's branch refs/heads/4.4 from [~htrippaers] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9eb8656 ] CLOUDSTACK-7624 The value field of the configuration table is not big enough for some values Long hostnames cause CloudStack to die with an encryption error during startup -- Key: CLOUDSTACK-7624 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7624 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: Future, 4.4.0 Reporter: Hugo Trippaers Assignee: Hugo Trippaers Fix For: 4.4.1 Machines with a long hostname will have a longer certificate in cloud.keystore. When encrypted this certificate will be longer than 4095 which is the maximum length of the database field. When the value is read back the stripped value is returned and the decryption routine will throw an error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7623) SystemVMs not starting
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146587#comment-14146587
]
Anthony Xu commented on CLOUDSTACK-7623:
Waited for 0seconds
The cause is it is trying to acquire DB table lock with timeout 0, if there is
any contention for the lock, the lock acquisition will fail due to timeout, the
code doesn't check if it acquires the lock successfully, and continues the
execution, it means without the checkout, the code will execute without getting
the lock, which is wrong. looks like return false hide this issue, which may
cause other DB issue later, and is very hard debug,
I'll remove the exception to unblock QA, call stack trace will be still logged.
_vmDao.lockInLockTable(String.valueOf(vm.getId()),
Integer.MAX_VALUE);
try {
ListVmWorkJobVO pendingWorkJobs =
_workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance,
vm.getId(), VmWorkStart.class.getName());
SystemVMs not starting
--
Key: CLOUDSTACK-7623
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM
Affects Versions: 4.5.0
Reporter: Pavan Kumar Bandarupally
Priority: Blocker
Fix For: 4.5.0
Attachments: management-server.log
After installing latest Management Server and zone creation, system VMs are
not getting created. The following exception is being generated:
2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2]
(consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 .
Waited for 0seconds
2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl]
(consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console
proxy
com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock
vm_instance1 . Waited for 0seconds
at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143)
at
com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389)
at
com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy53.lockInLockTable(Unknown Source)
at
com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927)
at
com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922)
at
com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49)
at com.cloud.utils.db.Transaction.execute(Transaction.java:37)
at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
at
com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157)
at
[jira] [Resolved] (CLOUDSTACK-7623) SystemVMs not starting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Xu resolved CLOUDSTACK-7623. Resolution: Fixed commit f5eae55abb4591109dd22c1ba9d25f0876ebe52f Author: Anthony Xu anthony...@citrix.com Date: Wed Sep 24 10:57:36 2014 -0700 timeInSeconds * 1000 timeInSeconds is int type, if timeInSeconds is very big, it makes timeInseconds * 1000 very small even 0 commit c74dada8541cbb81c3a4c06843d93aa1ce32f1ef Author: Anthony Xu anthony...@citrix.com Date: Wed Sep 24 10:28:04 2014 -0700 add logs for lock acquire and release SystemVMs not starting -- Key: CLOUDSTACK-7623 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: management-server.log After installing latest Management Server and zone creation, system VMs are not getting created. The following exception is being generated: 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . Waited for 0seconds 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console proxy com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock vm_instance1 . Waited for 0seconds at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) at com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) at com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy53.lockInLockTable(Unknown Source) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) at com.cloud.utils.db.Transaction.execute(Transaction.java:37) at com.cloud.utils.db.Transaction.execute(Transaction.java:46) at com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) at com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) at com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at
[jira] [Updated] (CLOUDSTACK-7623) SystemVMs not starting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-7623: Assignee: Anthony Xu SystemVMs not starting -- Key: CLOUDSTACK-7623 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Assignee: Anthony Xu Priority: Blocker Fix For: 4.5.0 Attachments: management-server.log After installing latest Management Server and zone creation, system VMs are not getting created. The following exception is being generated: 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . Waited for 0seconds 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console proxy com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock vm_instance1 . Waited for 0seconds at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) at com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) at com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy53.lockInLockTable(Unknown Source) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) at com.cloud.utils.db.Transaction.execute(Transaction.java:37) at com.cloud.utils.db.Transaction.execute(Transaction.java:46) at com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) at com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) at com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at
[jira] [Created] (CLOUDSTACK-7625) UI IP Address page EnableVPN If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failu
Jessica Wang created CLOUDSTACK-7625: Summary: UI IP Address page EnableVPN If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failure. Key: CLOUDSTACK-7625 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7625 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7625) UI IP Address page EnableVPN If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a fai
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146915#comment-14146915 ] ASF subversion and git services commented on CLOUDSTACK-7625: - Commit b592e0af345c38b5a898ec238bc4f2c8cedf6ef9 in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b592e0a ] CLOUDSTACK-7625: UI IP Address page EnableVPN If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failure. UI IP Address page EnableVPN If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failure. Key: CLOUDSTACK-7625 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7625 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7625) UI IP Address page EnableVPN If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failu
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-7625: - Attachment: jessica4.PNG jessica3.PNG jessica2.PNG jessica1.PNG UI IP Address page EnableVPN If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failure. Key: CLOUDSTACK-7625 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7625 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang Attachments: jessica1.PNG, jessica2.PNG, jessica3.PNG, jessica4.PNG -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7625) UI IP Address page EnableVPN If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-7625. -- Resolution: Fixed UI IP Address page EnableVPN If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failure. Key: CLOUDSTACK-7625 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7625 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang Attachments: jessica1.PNG, jessica2.PNG, jessica3.PNG, jessica4.PNG -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7625) UI IP Address page EnableVPN If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a fai
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146917#comment-14146917
]
Jessica Wang commented on CLOUDSTACK-7625:
--
screenshots of UI change are attached.
API calls in the screenshots:
https://issues.citrite.net/i#browse/CS-19442
http://10.215.3.26:8080/client/api?command=createRemoteAccessVpnresponse=jsonsessionkey=j86M%2FWlXUFfHsvj4rcpj%2FPUM4aA%3Dpublicipid=9784e132-7414-45e6-878f-82f081babb26domainid=5adf2319-38a9-11e4-b948-d4ae52cb99a3account=admin_=1411592742041
createremoteaccessvpnresponse: {
id: 750d1c27-c38b-45cd-92aa-59be98834c83,
jobid: 23c7553d-5c7a-499b-a22f-710c906ccaf1
}
}
http://10.215.3.26:8080/client/api?command=queryAsyncJobResultjobId=23c7553d-5c7a-499b-a22f-710c906ccaf1response=jsonsessionkey=j86M%2FWlXUFfHsvj4rcpj%2FPUM4aA%3D_=1411592745244
{
queryasyncjobresultresponse: {
accountid: da1a0149-38aa-11e4-b948-d4ae52cb99a3,
userid: da1a0c8e-38aa-11e4-b948-d4ae52cb99a3,
cmd:
org.apache.cloudstack.api.command.user.vpn.CreateRemoteAccessVpnCmd,
jobstatus: 1,
jobprocstatus: 0,
jobresultcode: 0,
jobresulttype: object,
jobresult: {
remoteaccessvpn: {
publicipid: 9784e132-7414-45e6-878f-82f081babb26,
publicip: 10.147.30.162,
iprange: 10.1.2.2-10.1.2.8,
presharedkey: 387sWNpGUWbJyd6aOWZDBOFS,
account: admin,
domainid: 5adf2319-38a9-11e4-b948-d4ae52cb99a3,
domain: ROOT,
state: Added,
id: 750d1c27-c38b-45cd-92aa-59be98834c83,
fordisplay: true
}
},
jobinstancetype: None,
created: 2014-09-24T13:05:41-0800,
jobid: 23c7553d-5c7a-499b-a22f-710c906ccaf1
}
}
UI IP Address page EnableVPN If createRemoteAccessVpn returns success,
but the newly created remoteaccessvpn object's state is not Running, treat it
as a failure.
Key: CLOUDSTACK-7625
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7625
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang
Attachments: jessica1.PNG, jessica2.PNG, jessica3.PNG, jessica4.PNG
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7625) UI IP Address page EnableVPN If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failur
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang closed CLOUDSTACK-7625. UI IP Address page EnableVPN If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failure. Key: CLOUDSTACK-7625 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7625 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang Attachments: jessica1.PNG, jessica2.PNG, jessica3.PNG, jessica4.PNG -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7626) SAMLUtilsTest failing inconsistently during build
Rayees Namathponnan created CLOUDSTACK-7626: --- Summary: SAMLUtilsTest failing inconsistently during build Key: CLOUDSTACK-7626 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7626 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Environment: 4.5 Reporter: Rayees Namathponnan Priority: Blocker Fix For: 4.5.0 4.5 build failing inconsistently while running unit test, unning org.apache.cloudstack.utils.auth.SAMLUtilsTest I have seen this issue multiple times, after the some merge happened 2 week ago, Build fails with below error [INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-utils --- [INFO] Surefire report directory: /root/jenkins/build/workspace/CloudPlatform-4.x-rhel63_Simulator/internal-cloudstack/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/utils/target/surefire-reports --- T E S T S --- Running org.apache.cloudstack.utils.auth.SAMLUtilsTest Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.245 sec Running com.cloud.utils.TestProfiler Configure log4j with default properties 2014-09-24 03:38:16,415 INFO [cloud.utils.TestProfiler] (main:) testProfiler() started 2014-09-24 03:38:17,417 INFO [cloud.utils.TestProfiler] (main:) Duration : 1000 2014-09-24 03:38:17,419 INFO [cloud.utils.TestProfiler] (main:) testProfiler() stopped Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.012 sec Running com.cloud.utils.ScriptTest 2014-09-24 03:38:17,526 DEBUG [utils.script.Script] (main:) Executing: /bin/echo bar 2014-09-24 03:38:17,537 DEBUG [utils.script.Script] (main:) Execution is successful. 2014-09-24 03:38:17,545 DEBUG [utils.script.Script] (main:) Looking for pwd in the classpath 2014-09-24 03:38:17,545 DEBUG [utils.script.Script] (main:) System resource: null 2014-09-24 03:38:17,546 DEBUG [utils.script.Script] (main:) Classpath resource: null 2014-09-24 03:38:17,549 DEBUG [utils.script.Script] (main:) Executing: /bin/bash -c echo 'hello world!' 2014-09-24 03:38:17,551 DEBUG [utils.script.Script] (main:) Execution is successful. 2014-09-24 03:38:17,551 WARN [utils.script.Script] (main:) Exception: /bin/bash -c echo 'hello world!' java.lang.IllegalArgumentException at com.cloud.utils.ScriptTest$1.interpret(ScriptTest.java:107) at com.cloud.utils.script.Script.execute(Script.java:220) at com.cloud.utils.ScriptTest.executeWithOutputInterpreter(ScriptTest.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at
[jira] [Created] (CLOUDSTACK-7627) [Automation] Automate Remote Access VPN on VPC Test Plan
Chandan Purushothama created CLOUDSTACK-7627: Summary: [Automation] Automate Remote Access VPN on VPC Test Plan Key: CLOUDSTACK-7627 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7627 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 This ticket refers to automation of the test cases in the test plan present at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Remote+Access+VPN+on+VPC+Feature+Test+Plan -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
Min Chen created CLOUDSTACK-7628: Summary: VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run. Key: CLOUDSTACK-7628 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 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 Reporter: Min Chen Priority: Critical Fix For: 4.5.0 Based on design, when VM worker job cleanup thread runs, it should only expunge those vm work jobs that are completed more than one hour ago. This is to prevent some Db constraint error in expunging these jobs since there are still reference to the worker job in async_job_map table. Also on some racing condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-7628: Assignee: Min Chen VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run. --- Key: CLOUDSTACK-7628 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 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 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Based on design, when VM worker job cleanup thread runs, it should only expunge those vm work jobs that are completed more than one hour ago. This is to prevent some Db constraint error in expunging these jobs since there are still reference to the worker job in async_job_map table. Also on some racing condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147174#comment-14147174 ] ASF subversion and git services commented on CLOUDSTACK-7628: - Commit 4317a85e97643c681b98b3e58990ec2f22abedd8 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4317a85 ] CLOUDSTACK-7628:VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run. VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run. --- Key: CLOUDSTACK-7628 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 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 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Based on design, when VM worker job cleanup thread runs, it should only expunge those vm work jobs that are completed more than one hour ago. This is to prevent some Db constraint error in expunging these jobs since there are still reference to the worker job in async_job_map table. Also on some racing condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147178#comment-14147178 ] Min Chen commented on CLOUDSTACK-7628: -- This is caused by a bug in code to set search criteria bind value, mismatched with the bind parameter defined earlier, thus cut date criteria is not used. VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run. --- Key: CLOUDSTACK-7628 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 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 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Based on design, when VM worker job cleanup thread runs, it should only expunge those vm work jobs that are completed more than one hour ago. This is to prevent some Db constraint error in expunging these jobs since there are still reference to the worker job in async_job_map table. Also on some racing condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7628. -- Resolution: Fixed VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run. --- Key: CLOUDSTACK-7628 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 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 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Based on design, when VM worker job cleanup thread runs, it should only expunge those vm work jobs that are completed more than one hour ago. This is to prevent some Db constraint error in expunging these jobs since there are still reference to the worker job in async_job_map table. Also on some racing condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6631) unable to attach new Volume to VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147181#comment-14147181
]
Kazuhiro Ito commented on CLOUDSTACK-6631:
--
Thank you for your comment.
Yes, both are true in my case.
Is this cloudstack's bug?
If I set vm.allocation.algorithm in global settings to random, I can attach
a volume to a VM?
unable to attach new Volume to VM
-
Key: CLOUDSTACK-6631
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
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: Cloudstack 4.2.1 + KVM on CentOS 6.4
Reporter: Kazuhiro Ito
Assignee: Likitha Shetty
Attachments: management-server.log.0521
1. I added new volume.
2. I tried to attach the volume to a VM on UI.
3. It failed and the following log appeared.
2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet]
(http-6443-exec-116:null) ===START=== 133.xx.xxx.xxx -- GET
command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl]
(http-6443-exec-116:null) submit async job-4916 = [
dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId:
3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543,
cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd,
cmdOriginator: null, cmdInfo:
{response:json,id:ac7099fb-ac66-4c63-bf1e-ed0e1429f412,sessionkey:TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d,cmdEventType:VOLUME.ATTACH,ctxUserId:3,virtualMachineId:ecdc2c1d-e21e-4c04-962a-4efac1a69a74,httpmethod:GET,_:1399861774316,ctxAccountId:3,ctxStartEventId:34276},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for
job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet]
(http-6443-exec-116:null) ===END=== 133.xx.xxx.xxx -- GET
command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to
Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
DomainChecker_EnhancerByCloudStack_9b413459
2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
to VM[User|TEST-A2-VM01] granted to
Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
DomainChecker_EnhancerByCloudStack_9b413459
2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
LocalStoragePoolAllocator trying to find storage pool to fit the vm
2014-05-12 11:29:47,212 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
ClusterScopeStoragePoolAllocator looking for storage pool
2014-05-12 11:29:47,212 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Looking for pools in dc: 1 pod:1 cluster:null having tags:[MPI]
2014-05-12 11:29:47,216 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No
storage pools available for shared volume allocation, returning
2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Unexpected exception while executing
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
com.cloud.utils.exception.CloudRuntimeException: Caught: SELECT pool.id,
SUM(IF(vol.state='Ready' AND vol.account_id = ?, 1, 0)) FROM
`cloud`.`storage_pool` pool LEFT JOIN `cloud`.`volumes` vol ON pool.id =
vol.pool_id WHERE pool.data_center_id = ? AND pool.pod_id = ? AND
pool.cluster_id = ? GROUP BY pool.id ORDER BY 2 ASC
at
[jira] [Commented] (CLOUDSTACK-6631) unable to attach new Volume to VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147334#comment-14147334
]
Likitha Shetty commented on CLOUDSTACK-6631:
Yes, this a CloudStack bug. I am working on a fix.
But in the meantime as a workaround to proceed with attach volumes, please set
the global setting to the default value that is 'random'.
unable to attach new Volume to VM
-
Key: CLOUDSTACK-6631
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
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: Cloudstack 4.2.1 + KVM on CentOS 6.4
Reporter: Kazuhiro Ito
Assignee: Likitha Shetty
Attachments: management-server.log.0521
1. I added new volume.
2. I tried to attach the volume to a VM on UI.
3. It failed and the following log appeared.
2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet]
(http-6443-exec-116:null) ===START=== 133.xx.xxx.xxx -- GET
command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl]
(http-6443-exec-116:null) submit async job-4916 = [
dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId:
3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543,
cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd,
cmdOriginator: null, cmdInfo:
{response:json,id:ac7099fb-ac66-4c63-bf1e-ed0e1429f412,sessionkey:TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d,cmdEventType:VOLUME.ATTACH,ctxUserId:3,virtualMachineId:ecdc2c1d-e21e-4c04-962a-4efac1a69a74,httpmethod:GET,_:1399861774316,ctxAccountId:3,ctxStartEventId:34276},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for
job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet]
(http-6443-exec-116:null) ===END=== 133.xx.xxx.xxx -- GET
command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to
Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
DomainChecker_EnhancerByCloudStack_9b413459
2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
to VM[User|TEST-A2-VM01] granted to
Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
DomainChecker_EnhancerByCloudStack_9b413459
2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
LocalStoragePoolAllocator trying to find storage pool to fit the vm
2014-05-12 11:29:47,212 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
ClusterScopeStoragePoolAllocator looking for storage pool
2014-05-12 11:29:47,212 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Looking for pools in dc: 1 pod:1 cluster:null having tags:[MPI]
2014-05-12 11:29:47,216 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No
storage pools available for shared volume allocation, returning
2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Unexpected exception while executing
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
com.cloud.utils.exception.CloudRuntimeException: Caught: SELECT pool.id,
SUM(IF(vol.state='Ready' AND vol.account_id = ?, 1, 0)) FROM
`cloud`.`storage_pool` pool LEFT JOIN `cloud`.`volumes` vol ON pool.id =
vol.pool_id WHERE pool.data_center_id = ? AND pool.pod_id = ? AND
pool.cluster_id = ? GROUP BY pool.id ORDER BY 2 ASC
at
[jira] [Created] (CLOUDSTACK-7629) addBaremetalRct() API call is not available in cloudstackAPI library in marvin.
Sangeetha Hariharan created CLOUDSTACK-7629: --- Summary: addBaremetalRct() API call is not available in cloudstackAPI library in marvin. Key: CLOUDSTACK-7629 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7629 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Sangeetha Hariharan Assignee: frank zhang Fix For: 4.5.0 addBaremetalRct() API call is not available in cloudstackAPI library in marvin. When a new API call is added , we expect the python libraries for this API to be available as part of cloudstackAPI in marvin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6631) unable to attach new Volume to VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147358#comment-14147358
]
Kazuhiro Ito commented on CLOUDSTACK-6631:
--
You've been very helpful.
I will try your advice.
Best regards,
unable to attach new Volume to VM
-
Key: CLOUDSTACK-6631
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
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: Cloudstack 4.2.1 + KVM on CentOS 6.4
Reporter: Kazuhiro Ito
Assignee: Likitha Shetty
Attachments: management-server.log.0521
1. I added new volume.
2. I tried to attach the volume to a VM on UI.
3. It failed and the following log appeared.
2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet]
(http-6443-exec-116:null) ===START=== 133.xx.xxx.xxx -- GET
command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl]
(http-6443-exec-116:null) submit async job-4916 = [
dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId:
3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543,
cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd,
cmdOriginator: null, cmdInfo:
{response:json,id:ac7099fb-ac66-4c63-bf1e-ed0e1429f412,sessionkey:TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d,cmdEventType:VOLUME.ATTACH,ctxUserId:3,virtualMachineId:ecdc2c1d-e21e-4c04-962a-4efac1a69a74,httpmethod:GET,_:1399861774316,ctxAccountId:3,ctxStartEventId:34276},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for
job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet]
(http-6443-exec-116:null) ===END=== 133.xx.xxx.xxx -- GET
command=attachVolumeid=ac7099fb-ac66-4c63-bf1e-ed0e1429f412virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74response=jsonsessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D_=1399861774316
2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to
Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
DomainChecker_EnhancerByCloudStack_9b413459
2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
to VM[User|TEST-A2-VM01] granted to
Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
DomainChecker_EnhancerByCloudStack_9b413459
2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
LocalStoragePoolAllocator trying to find storage pool to fit the vm
2014-05-12 11:29:47,212 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
ClusterScopeStoragePoolAllocator looking for storage pool
2014-05-12 11:29:47,212 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Looking for pools in dc: 1 pod:1 cluster:null having tags:[MPI]
2014-05-12 11:29:47,216 DEBUG
[storage.allocator.ClusterScopeStoragePoolAllocator]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No
storage pools available for shared volume allocation, returning
2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
Unexpected exception while executing
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
com.cloud.utils.exception.CloudRuntimeException: Caught: SELECT pool.id,
SUM(IF(vol.state='Ready' AND vol.account_id = ?, 1, 0)) FROM
`cloud`.`storage_pool` pool LEFT JOIN `cloud`.`volumes` vol ON pool.id =
vol.pool_id WHERE pool.data_center_id = ? AND pool.pod_id = ? AND
pool.cluster_id = ? GROUP BY pool.id ORDER BY 2 ASC
at
com.cloud.storage.dao.VolumeDaoImpl.listPoolIdsByVolumeCount(VolumeDaoImpl.java:480)
at
[jira] [Issue Comment Deleted] (CLOUDSTACK-7622) Can't delete the network when providers this network uses, are disabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy updated CLOUDSTACK-7622:
--
Comment: was deleted
(was: MS logs:
2014-09-24 15:35:18,719 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(1949422689@qtp-2019457093-0:ctx-fe1d81bc ctx-ecb8d94c) submit async job-29,
details: AsyncJobVO {id:29, userId: 2, accountId: 2, instanceType: None,
instanceId: null, cmd: com.cloud.api.commands.AddSrxFirewallCmd, cmdInfo:
{physicalnetworkid:5a343691-932d-4f4c-9e65-da754b5b93cb,sessionkey:0is9qGB4EiFibf2X7eQD8KKitIs\u003d,cmdEventType:PHYSICAL.FIREWALL.ADD,ctxUserId:2,httpmethod:POST,password:password,url:https://10.147.40.3?publicinterface\u003dfe00\u0026privateinterface\u003dfe01\u0026numretries\u003d2\u0026timeout\u003d300\u0026fwdevicededicated\u003dfalse,response:json,ctxDetails:{\com.cloud.network.PhysicalNetwork\:\5a343691-932d-4f4c-9e65-da754b5b93cb\},username:admin,networkdevicetype:JuniperSRXFirewall,ctxAccountId:2,ctxStartEventId:78},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 1, completeMsid: null, lastUpdated: null, lastPolled: null,
created: null}
2014-09-24 15:35:18,720 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-2:ctx-5ec8cde4 job-29) Add job-29 into job monitoring
2014-09-24 15:35:18,721 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-2:ctx-5ec8cde4 job-29) Executing AsyncJobVO {id:29, userId:
2, accountId: 2, instanceType: None, instanceId: null, cmd:
com.cloud.api.commands.AddSrxFirewallCmd, cmdInfo:
{physicalnetworkid:5a343691-932d-4f4c-9e65-da754b5b93cb,sessionkey:0is9qGB4EiFibf2X7eQD8KKitIs\u003d,cmdEventType:PHYSICAL.FIREWALL.ADD,ctxUserId:2,httpmethod:POST,password:password,url:https://10.147.40.3?publicinterface\u003dfe00\u0026privateinterface\u003dfe01\u0026numretries\u003d2\u0026timeout\u003d300\u0026fwdevicededicated\u003dfalse,response:json,ctxDetails:{\com.cloud.network.PhysicalNetwork\:\5a343691-932d-4f4c-9e65-da754b5b93cb\},username:admin,networkdevicetype:JuniperSRXFirewall,ctxAccountId:2,ctxStartEventId:78},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 1, completeMsid: null, lastUpdated: null, lastPolled: null,
created: null}
)
Can't delete the network when providers this network uses, are disabled
---
Key: CLOUDSTACK-7622
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7622
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.0.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
Fix For: 4.5.0
Steps to reproduce:
create network, use VR as a provider for its services
disable VR provider
try to delete the network. Shutdown network fails due to disabled provider.
Shutdown should be successful even when provider is disabled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7630) CPU utilization display of VM Instances is incorrect. (In the case of VMware vSphere 5)
satoru nakaya created CLOUDSTACK-7630: - Summary: CPU utilization display of VM Instances is incorrect. (In the case of VMware vSphere 5) Key: CLOUDSTACK-7630 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7630 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.1, 4.3.0 Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 Reporter: satoru nakaya CPU utilization display of VM Instances is incorrect. Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 CloudStack UI Instances-VM-Statistics CPU Utilized: 1980% ^^^ == # top top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7630) CPU utilization display of VM Instances is incorrect. (In the case of VMware vSphere 5)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] satoru nakaya updated CLOUDSTACK-7630: -- Description: CPU utilization display of VM Instances is incorrect. Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 CloudStack UI Instances-VM-Statistics CPU Utilized: 1980% ^^^ == '# top top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st was: CPU utilization display of VM Instances is incorrect. Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 CloudStack UI Instances-VM-Statistics CPU Utilized: 1980% ^^^ == # top top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st CPU utilization display of VM Instances is incorrect. (In the case of VMware vSphere 5) --- Key: CLOUDSTACK-7630 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7630 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.1, 4.3.0 Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 Reporter: satoru nakaya CPU utilization display of VM Instances is incorrect. Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 CloudStack UI Instances-VM-Statistics CPU Utilized: 1980% ^^^ == '# top top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7630) CPU utilization display of VM Instances is incorrect. (In the case of VMware vSphere 5)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] satoru nakaya updated CLOUDSTACK-7630: -- Description: CPU utilization display of VM Instances is incorrect. Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 CloudStack UI Instances-VM-Statistics CPU Utilized: 1980% ^^^ == # top top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st was: CPU utilization display of VM Instances is incorrect. Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 CloudStack UI Instances-VM-Statistics CPU Utilized: 1980% ^^^ == # top top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st CPU utilization display of VM Instances is incorrect. (In the case of VMware vSphere 5) --- Key: CLOUDSTACK-7630 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7630 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.1, 4.3.0 Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 Reporter: satoru nakaya CPU utilization display of VM Instances is incorrect. Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 CloudStack UI Instances-VM-Statistics CPU Utilized: 1980% ^^^ == # top top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7622) Can't delete the network when providers this network uses, are disabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147390#comment-14147390 ] ASF subversion and git services commented on CLOUDSTACK-7622: - Commit 8c8c54f9f59249c47ff5985626579b4f9565d9fd in cloudstack's branch refs/heads/master from Jayapal [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8c8c54f ] CLOUDSTACK-7622: Fixed deleting network when provider is disable Can't delete the network when providers this network uses, are disabled --- Key: CLOUDSTACK-7622 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7622 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.0.0 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Fix For: 4.5.0 Steps to reproduce: create network, use VR as a provider for its services disable VR provider try to delete the network. Shutdown network fails due to disabled provider. Shutdown should be successful even when provider is disabled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7631) Log rotate on VR may fail as /etc/init.d/rsyslog does not anymore support reload option on debian wheezy
Saksham Srivastava created CLOUDSTACK-7631:
--
Summary: Log rotate on VR may fail as /etc/init.d/rsyslog does not
anymore support reload option on debian wheezy
Key: CLOUDSTACK-7631
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7631
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Saksham Srivastava
Assignee: Saksham Srivastava
As shown below we get the following message when doing logrotate on VR:
#logrotate -v /etc/logrotate.conf
rotating pattern: /var/log/syslog
running postrotate script
Usage: /etc/init.d/rsyslog
{start|stop|rotate|restart|force-reload|status}
invoke-rc.d: initscript rsyslog, action reload failed.
error: error running non-shared postrotate script for /var/log/syslog of
'/var/log/syslog
https://github.com/Yubico/yubikey-val/issues/18
https://access.redhat.com/solutions/232793
https://www.rudder-project.org/redmine/issues/3176
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7631) Log rotate on VR may fail as /etc/init.d/rsyslog does not anymore support reload option on debian wheezy
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saksham Srivastava updated CLOUDSTACK-7631:
---
Fix Version/s: 4.5.0
Log rotate on VR may fail as /etc/init.d/rsyslog does not anymore support
reload option on debian wheezy
Key: CLOUDSTACK-7631
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7631
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Reporter: Saksham Srivastava
Assignee: Saksham Srivastava
Fix For: 4.5.0
As shown below we get the following message when doing logrotate on VR:
#logrotate -v /etc/logrotate.conf
rotating pattern: /var/log/syslog
running postrotate script
Usage: /etc/init.d/rsyslog
{start|stop|rotate|restart|force-reload|status}
invoke-rc.d: initscript rsyslog, action reload failed.
error: error running non-shared postrotate script for /var/log/syslog of
'/var/log/syslog
https://github.com/Yubico/yubikey-val/issues/18
https://access.redhat.com/solutions/232793
https://www.rudder-project.org/redmine/issues/3176
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7622) Can't delete the network when providers this network uses, are disabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14147438#comment-14147438 ] Jayapal Reddy commented on CLOUDSTACK-7622: --- Problem: --- When network provider is disabled state network is not able to shutdown, delete. Root Cause Analysis: --- On network shutdown and deleting checking for wether provide is enabled or not, if is enabled then only allowed to perform. Proposed solution: Removing the condition of checking provider enabled . Verification steps: - 1. Create isolated network and deploy vms. 2. Delete the vm in this network. 3. Network state change to shutdown with out errors and then to allocated. 4. Delete network should also successful. Can't delete the network when providers this network uses, are disabled --- Key: CLOUDSTACK-7622 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7622 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.0.0 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Fix For: 4.5.0 Steps to reproduce: create network, use VR as a provider for its services disable VR provider try to delete the network. Shutdown network fails due to disabled provider. Shutdown should be successful even when provider is disabled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7622) Can't delete the network when providers this network uses, are disabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy resolved CLOUDSTACK-7622. --- Resolution: Fixed Can't delete the network when providers this network uses, are disabled --- Key: CLOUDSTACK-7622 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7622 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.0.0 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Fix For: 4.5.0 Steps to reproduce: create network, use VR as a provider for its services disable VR provider try to delete the network. Shutdown network fails due to disabled provider. Shutdown should be successful even when provider is disabled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
