[jira] [Resolved] (CLOUDSTACK-4858) Disable copy snapshot to secondary storage snapshot.backup.rightafter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Weller resolved CLOUDSTACK-4858. -- Resolution: Fixed Assignee: Nathan Johnson Fix Version/s: 4.9.0 > Disable copy snapshot to secondary storage snapshot.backup.rightafter > - > > Key: CLOUDSTACK-4858 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4858 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.0 > Environment: kvm, rbd >Reporter: Sebastian Igerl >Assignee: Nathan Johnson > Fix For: 4.9.0 > > > "snapshot.backup.rightafterbackup" is set to false but still the snapshot is > copied to secondary storage. > Primary storage is Ceph/RDB, Secondary is NFS. I restarted both the > management server and the nodes. > see : > http://www.marshut.com/wpviz/disable-copy-snapshot-to-secondary-storage-in-cs-4-2.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CLOUDSTACK-4858) Disable copy snapshot to secondary storage snapshot.backup.rightafter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Weller updated CLOUDSTACK-4858: - Fix Version/s: 4.10.0.0 > Disable copy snapshot to secondary storage snapshot.backup.rightafter > - > > Key: CLOUDSTACK-4858 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4858 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.0 > Environment: kvm, rbd >Reporter: Sebastian Igerl >Assignee: Nathan Johnson > Fix For: 4.9.0, 4.10.0.0 > > > "snapshot.backup.rightafterbackup" is set to false but still the snapshot is > copied to secondary storage. > Primary storage is Ceph/RDB, Secondary is NFS. I restarted both the > management server and the nodes. > see : > http://www.marshut.com/wpviz/disable-copy-snapshot-to-secondary-storage-in-cs-4-2.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CLOUDSTACK-9661) Allow Carrier Grade NAT IP ranges (RFC 6598) to be used within a VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Weller updated CLOUDSTACK-9661: - Affects Version/s: 4.8.0 4.9.0 Fix Version/s: (was: Future) > Allow Carrier Grade NAT IP ranges (RFC 6598) to be used within a VPC > > > Key: CLOUDSTACK-9661 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9661 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.8.0, 4.9.0, 4.10.0.0 >Reporter: Simon Weller >Assignee: Simon Weller >Priority: Minor > > In a carrier environment, IP space is very precious. RFC 6598 specifies a > IANA-Reserved IPv4 Prefix for Shared Address Space that is used in carrier > networks for handling Carrier Grade NAT (CGN). Since this range is not > publicly routable, it can be used within a carriers network in a similar way > to RFC 1918 space. > This PR adds support for RFC 6598 space. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9661) Allow Carrier Grade NAT IP ranges (RFC 6598) to be used within a VPC
Simon Weller created CLOUDSTACK-9661: Summary: Allow Carrier Grade NAT IP ranges (RFC 6598) to be used within a VPC Key: CLOUDSTACK-9661 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9661 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.10.0.0 Reporter: Simon Weller Assignee: Simon Weller Priority: Minor Fix For: Future In a carrier environment, IP space is very precious. RFC 6598 specifies a IANA-Reserved IPv4 Prefix for Shared Address Space that is used in carrier networks for handling Carrier Grade NAT (CGN). Since this range is not publicly routable, it can be used within a carriers network in a similar way to RFC 1918 space. This PR adds support for RFC 6598 space. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9461) When RBD backup snapshot to secondary occurs, secondary storage image format is RAW
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Weller reassigned CLOUDSTACK-9461: Assignee: Simon Weller > When RBD backup snapshot to secondary occurs, secondary storage image format > is RAW > --- > > Key: CLOUDSTACK-9461 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9461 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.7.0, 4.8.0, 4.9.0 >Reporter: Simon Weller >Assignee: Simon Weller >Priority: Minor > Fix For: Future > > > RBD snapshot backup to secondary storage should use QCOW2, not RAW. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9461) When RBD backup snapshot to secondary occurs, secondary storage image format is RAW
Simon Weller created CLOUDSTACK-9461: Summary: When RBD backup snapshot to secondary occurs, secondary storage image format is RAW Key: CLOUDSTACK-9461 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9461 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.9.0, 4.8.0, 4.7.0 Reporter: Simon Weller Priority: Minor Fix For: Future RBD snapshot backup to secondary storage should use QCOW2, not RAW. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4858) Disable copy snapshot to secondary storage snapshot.backup.rightafter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15411728#comment-15411728 ] Simon Weller commented on CLOUDSTACK-4858: -- We have a working PR to fix this in the works. We're working on extending the test set around it and then we'll issue it against ACS. - Si > Disable copy snapshot to secondary storage snapshot.backup.rightafter > - > > Key: CLOUDSTACK-4858 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4858 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.0 > Environment: kvm, rbd >Reporter: Sebastian Igerl > > "snapshot.backup.rightafterbackup" is set to false but still the snapshot is > copied to secondary storage. > Primary storage is Ceph/RDB, Secondary is NFS. I restarted both the > management server and the nodes. > see : > http://www.marshut.com/wpviz/disable-copy-snapshot-to-secondary-storage-in-cs-4-2.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9434) NPE on attempting account/domain cleanup automation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Weller updated CLOUDSTACK-9434: - Attachment: dump.txt MySQL query logs for the NPE > NPE on attempting account/domain cleanup automation > --- > > Key: CLOUDSTACK-9434 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9434 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.8.0 > Environment: Centos 7.2, KVM >Reporter: Simon Weller >Priority: Minor > Attachments: dump.txt > > > When attempting to delete a domain, an NPE is thrown trying to cleanup > associated accounts. > 2016-07-21 08:48:58,119 INFO [c.c.u.AccountManagerImpl] > (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Found 5 removed accounts to > cleanup > 2016-07-21 08:48:58,119 DEBUG [c.c.u.AccountManagerImpl] > (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Cleaning up 12 > 2016-07-21 08:48:58,125 DEBUG [c.c.u.AccountManagerImpl] > (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Successfully deleted > snapshots directories for all volumes under account 12 across all zones > 2016-07-21 08:48:58,129 DEBUG [c.c.u.AccountManagerImpl] > (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Expunging # of vms > (accountId=12): 0 > 2016-07-21 08:48:58,134 INFO [c.c.u.AccountManagerImpl] > (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) deleteAccount: Deleted 0 > network groups for account 12 > 2016-07-21 08:48:58,135 INFO [c.c.u.AccountManagerImpl] > (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) deleteAccount: Deleted 0 > affinity groups for account 12 > 2016-07-21 08:48:58,135 DEBUG [c.c.u.AccountManagerImpl] > (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Deleting networks for > account 12 > 2016-07-21 08:48:58,138 DEBUG [c.c.u.AccountManagerImpl] > (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Deleting vpcs for account 12 > 2016-07-21 08:48:58,140 DEBUG [c.c.u.AccountManagerImpl] > (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Deleting site-to-site VPN > customer gateways for account 12 > 2016-07-21 08:48:58,148 DEBUG [c.c.u.d.T.Transaction] > (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Rolling back the > transaction: Time = 2 Name = AccountChecker-1; called by > -TransactionLegacy.rollback:879-TransactionLegacy.removeUpTo:822-TransactionLegacy.close:646-Transaction.execute:43-Transaction.execute:47-ConfigurationManagerImpl.releaseAccountSpecificVirtualRanges:4941-GeneratedMethodAccessor764.invoke:-1-DelegatingMethodAccessorImpl.invoke:43-Method.invoke:606-AopUtils.invokeJoinpointUsingReflection:317-ReflectiveMethodInvocation.invokeJoinpoint:183-ReflectiveMethodInvocation.proceed:150 > 2016-07-21 08:48:58,150 WARN [c.c.u.AccountManagerImpl] > (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Failed to cleanup account > Acct[9f367fca-d4c6-4603-b487-afd4e3d46dfc-admin-2177] due to > java.lang.NullPointerException > at > com.cloud.configuration.ConfigurationManagerImpl.releasePublicIpRange(ConfigurationManagerImpl.java:3473) > at > com.cloud.configuration.ConfigurationManagerImpl$12.doInTransactionWithoutResult(ConfigurationManagerImpl.java:4945) > at > com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50) > at com.cloud.utils.db.Transaction.execute(Transaction.java:40) > at com.cloud.utils.db.Transaction.execute(Transaction.java:47) > at > com.cloud.configuration.ConfigurationManagerImpl.releaseAccountSpecificVirtualRanges(ConfigurationManagerImpl.java:4941) > at sun.reflect.GeneratedMethodAccessor764.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at > com.sun.proxy.$Proxy117.releaseAccountSpecificVirtualRanges(Unknown
[jira] [Created] (CLOUDSTACK-9434) NPE on attempting account/domain cleanup automation
Simon Weller created CLOUDSTACK-9434: Summary: NPE on attempting account/domain cleanup automation Key: CLOUDSTACK-9434 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9434 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.8.0 Environment: Centos 7.2, KVM Reporter: Simon Weller Priority: Minor When attempting to delete a domain, an NPE is thrown trying to cleanup associated accounts. 2016-07-21 08:48:58,119 INFO [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Found 5 removed accounts to cleanup 2016-07-21 08:48:58,119 DEBUG [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Cleaning up 12 2016-07-21 08:48:58,125 DEBUG [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Successfully deleted snapshots directories for all volumes under account 12 across all zones 2016-07-21 08:48:58,129 DEBUG [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Expunging # of vms (accountId=12): 0 2016-07-21 08:48:58,134 INFO [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) deleteAccount: Deleted 0 network groups for account 12 2016-07-21 08:48:58,135 INFO [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) deleteAccount: Deleted 0 affinity groups for account 12 2016-07-21 08:48:58,135 DEBUG [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Deleting networks for account 12 2016-07-21 08:48:58,138 DEBUG [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Deleting vpcs for account 12 2016-07-21 08:48:58,140 DEBUG [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Deleting site-to-site VPN customer gateways for account 12 2016-07-21 08:48:58,148 DEBUG [c.c.u.d.T.Transaction] (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Rolling back the transaction: Time = 2 Name = AccountChecker-1; called by -TransactionLegacy.rollback:879-TransactionLegacy.removeUpTo:822-TransactionLegacy.close:646-Transaction.execute:43-Transaction.execute:47-ConfigurationManagerImpl.releaseAccountSpecificVirtualRanges:4941-GeneratedMethodAccessor764.invoke:-1-DelegatingMethodAccessorImpl.invoke:43-Method.invoke:606-AopUtils.invokeJoinpointUsingReflection:317-ReflectiveMethodInvocation.invokeJoinpoint:183-ReflectiveMethodInvocation.proceed:150 2016-07-21 08:48:58,150 WARN [c.c.u.AccountManagerImpl] (AccountChecker-1:ctx-d349b03d) (logid:61884c2d) Failed to cleanup account Acct[9f367fca-d4c6-4603-b487-afd4e3d46dfc-admin-2177] due to java.lang.NullPointerException at com.cloud.configuration.ConfigurationManagerImpl.releasePublicIpRange(ConfigurationManagerImpl.java:3473) at com.cloud.configuration.ConfigurationManagerImpl$12.doInTransactionWithoutResult(ConfigurationManagerImpl.java:4945) at com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50) at com.cloud.utils.db.Transaction.execute(Transaction.java:40) at com.cloud.utils.db.Transaction.execute(Transaction.java:47) at com.cloud.configuration.ConfigurationManagerImpl.releaseAccountSpecificVirtualRanges(ConfigurationManagerImpl.java:4941) at sun.reflect.GeneratedMethodAccessor764.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy117.releaseAccountSpecificVirtualRanges(Unknown Source) at com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:869) at com.cloud.user.AccountManagerImpl$AccountCleanupTask.runInContext(AccountManagerImpl.java:1722) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at
[jira] [Commented] (CLOUDSTACK-9209) Database HA not working on a fresh install on Ubuntu 12.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15353668#comment-15353668 ] Simon Weller commented on CLOUDSTACK-9209: -- Tom, This issue is fixed in master (future 4.9). You can change a couple of config files in your 4.8 install to fix this. Please see https://github.com/apache/cloudstack/pull/1428/commits/c22659d76d73f00f41c13776c490e17a50aacd20 for the changes. - Si > Database HA not working on a fresh install on Ubuntu 12.04 > -- > > Key: CLOUDSTACK-9209 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9209 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.7.0 > Environment: Two Ubuntu 12.04 Management Servers, Mysql Master Master > Replication, Official community repository: > http://cloudstack.apt-get.eu/ubuntu/dists/precise/4.7/ >Reporter: Thomas >Priority: Blocker > > The cloudstack-management service will not come up because of this error: > 2016-01-05 16:15:00,899 INFO [c.c.u.d.T.Transaction] (main:null) (logid:) Is > Data Base High Availiability enabled? Ans : true > 2016-01-05 16:15:00,924 INFO [c.c.u.d.T.Transaction] (main:null) (logid:) > The slaves configured for Cloud Data base is/are : 192.168.0.90 > 2016-01-05 16:15:00,974 ERROR [c.c.u.d.Merovingian2] (main:null) (logid:) > Unable to get a new db connection > java.sql.SQLException: Invalid load balancing strategy > 'com.cloud.utils.db.StaticStrategy'. > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:934) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:931) > at com.mysql.jdbc.Util.loadExtensions(Util.java:588) > at > com.mysql.jdbc.LoadBalancingConnectionProxy.(LoadBalancingConnectionProxy.java:279) > at > com.mysql.jdbc.FailoverConnectionProxy.(FailoverConnectionProxy.java:66) > at > com.mysql.jdbc.NonRegisteringDriver.connectFailover(NonRegisteringDriver.java:382) > at > com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:301) > at java.sql.DriverManager.getConnection(DriverManager.java:571) > at java.sql.DriverManager.getConnection(DriverManager.java:215) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) > at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188) > at > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) > at > com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:202) > at com.cloud.utils.db.Merovingian2.(Merovingian2.java:68) > at > com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:88) > at > com.cloud.server.LockMasterListener.(LockMasterListener.java:33) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:121) > at > org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:277) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1077) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:981) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:487) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) > at >
[jira] [Commented] (CLOUDSTACK-9370) Failed to create VPC: Unable to start VPC VR (VM DomainRouter) due to error in finalizeStart, not retrying
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15260136#comment-15260136
]
Simon Weller commented on CLOUDSTACK-9370:
--
According to the 4.8 docs, OVS and KVM VPC doesn't currently work. I'm not
aware of any work that has changed this in master.
http://docs.cloudstack.apache.org/en/latest/networking/ovs-plugin.html#using-the-ovs-plugin-with-vpc
> Failed to create VPC: Unable to start VPC VR (VM DomainRouter) due to error
> in finalizeStart, not retrying
> ---
>
> Key: CLOUDSTACK-9370
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9370
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.9.0
> Environment: Centos El7
> KVM
> OpenvSwitch (VLAN 0)
> NFS (primary/secondary)
>Reporter: Mani Prashanth Varma Manthena
>Priority: Critical
> Fix For: 4.9.0
>
>
> I am unable to create VPCs on latest cloudstack master due to the following
> error:
> {noformat:title=Root Cause Error in Agent log}
> 2016-04-27 02:31:03,134 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-2:null) (logid:6b2d4faa) [INFO] update_config.py ::
> Processing incoming file => ip_associations.json[INFO] Processing JSON file
> ip_associations.jsonTraceback (most recent call last): File
> "/opt/cloud/bin/update_config.py", line 140, in process_file()
> File "/opt/cloud/bin/update_config.py", line 52, in process_file
> qf.load(None) File "/opt/cloud/bin/merge.py", line 258, in loadproc =
> updateDataBag(self) File "/opt/cloud/bin/merge.py", line 91, in __init__
> self.process() File "/opt/cloud/bin/merge.py", line 103, in processdbag
> = self.processIP(self.db.getDataBag()) File "/opt/cloud/bin/merge.py", line
> 190, in processIPdbag = cs_ip.merge(dbag, ip) File
> "/opt/cloud/bin/cs_ip.py", line 32, in mergeip['device'] = 'eth' +
> str(ip['nic_dev_id'])KeyError: 'nic_dev_id'
> 2016-04-27 02:31:03,135 DEBUG
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-2:null) (logid:6b2d4faa) Processing ScriptConfigItem,
> executing update_config.py ip_associations.json took 911ms
> {noformat}
> {noformat:title=Root Cause Error in Management Server log}
> 2016-04-27 02:30:19,975 DEBUG [c.c.a.m.ClusteredAgentAttache]
> (Work-Job-Executor-10:ctx-1279b068 job-1159/job-1160 ctx-c31efe73)
> (logid:6b2d4faa) Seq 9-332421947495286159: Forwarding Seq
> 9-332421947495286159: { Cmd , MgmtId: 275619427298304, via:
> 9(ovs-2.mvdcvtb16.us.alcatel-lucent.com), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StartCommand":{"vm":{"id":252,"name":"r-252-VM","type":"DomainRouter","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":268435456,"maxRam":268435456,"arch":"x86_64","os":"Debian
> GNU/Linux 5.0 (64-bit)","platformEmulator":"Debian GNU/Linux 5","bootArgs":"
> vpccidr=10.1.1.1/16 domain=cs2cloud.internal dns1=128.251.10.29 template=domP
> name=r-252-VM eth0ip=169.254.1.123 eth0mask=255.255.0.0 type=vpcrouter
> disable_rp_filter=true
> baremetalnotificationsecuritykey=0oLpL4swbL6Yu_xsuRdyjwmmyPHAU1V-iMpmMNKO00vNIP5bxronvhQZ_qehiEZ99Eo9avCHg9uLh1cbiz7pQA
>
> baremetalnotificationapikey=wEax_CyEaKZHn8ZkPBQLQaibjSWZ0OYJuEQA3l2RUA41GXZxaie9P6oQPeNlzjIGl-fDpKWp9MkAEQOJYvE4vA
> host=10.31.59.151
>
[jira] [Updated] (CLOUDSTACK-9300) MySQL HA feature StaticStrategy throws exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Weller updated CLOUDSTACK-9300: - Fix Version/s: 4.9.0 > MySQL HA feature StaticStrategy throws exception > > > Key: CLOUDSTACK-9300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0, 4.7.1, 4.8.0, Future > Environment: Centos 7 >Reporter: Simon Weller >Assignee: Simon Weller >Priority: Minor > Fix For: 4.9.0 > > > 2016-03-03 12:00:13,204 INFO [c.c.u.d.T.Transaction] > (localhost-startStop-1:null) (logid:) Is Data Base High Availiability > enabled? Ans : true > 2016-03-03 12:00:13,239 INFO [c.c.u.d.T.Transaction] > (localhost-startStop-1:null) (logid:) The slaves configured for Cloud Data > base is/are : localhost,localhost > 2016-03-03 12:00:13,303 ERROR [c.c.u.d.Merovingian2] > (localhost-startStop-1:null) (logid:) Unable to get a new db connection > java.sql.SQLException: Invalid load balancing strategy > 'com.cloud.utils.db.StaticStrategy'. > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:924) > at com.mysql.jdbc.Util.loadExtensions(Util.java:602) > at > com.mysql.jdbc.LoadBalancingConnectionProxy.(LoadBalancingConnectionProxy.java:280) > at > com.mysql.jdbc.FailoverConnectionProxy.(FailoverConnectionProxy.java:67) > at > com.mysql.jdbc.NonRegisteringDriver.connectFailover(NonRegisteringDriver.java:433) > at > com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:346) > at java.sql.DriverManager.getConnection(DriverManager.java:571) > at java.sql.DriverManager.getConnection(DriverManager.java:215) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) > at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188) > at > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) > at > com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:202) > at com.cloud.utils.db.Merovingian2.(Merovingian2.java:68) > at > com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:88) > at > com.cloud.server.LockMasterListener.(LockMasterListener.java:33) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:121) > at > org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:277) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1077) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:981) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:487) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:191) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:636) > at >
[jira] [Assigned] (CLOUDSTACK-9300) MySQL HA feature StaticStrategy throws exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Weller reassigned CLOUDSTACK-9300: Assignee: Simon Weller > MySQL HA feature StaticStrategy throws exception > > > Key: CLOUDSTACK-9300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0, 4.7.1, 4.8.0, Future > Environment: Centos 7 >Reporter: Simon Weller >Assignee: Simon Weller >Priority: Minor > > 2016-03-03 12:00:13,204 INFO [c.c.u.d.T.Transaction] > (localhost-startStop-1:null) (logid:) Is Data Base High Availiability > enabled? Ans : true > 2016-03-03 12:00:13,239 INFO [c.c.u.d.T.Transaction] > (localhost-startStop-1:null) (logid:) The slaves configured for Cloud Data > base is/are : localhost,localhost > 2016-03-03 12:00:13,303 ERROR [c.c.u.d.Merovingian2] > (localhost-startStop-1:null) (logid:) Unable to get a new db connection > java.sql.SQLException: Invalid load balancing strategy > 'com.cloud.utils.db.StaticStrategy'. > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:924) > at com.mysql.jdbc.Util.loadExtensions(Util.java:602) > at > com.mysql.jdbc.LoadBalancingConnectionProxy.(LoadBalancingConnectionProxy.java:280) > at > com.mysql.jdbc.FailoverConnectionProxy.(FailoverConnectionProxy.java:67) > at > com.mysql.jdbc.NonRegisteringDriver.connectFailover(NonRegisteringDriver.java:433) > at > com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:346) > at java.sql.DriverManager.getConnection(DriverManager.java:571) > at java.sql.DriverManager.getConnection(DriverManager.java:215) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) > at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188) > at > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) > at > com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:202) > at com.cloud.utils.db.Merovingian2.(Merovingian2.java:68) > at > com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:88) > at > com.cloud.server.LockMasterListener.(LockMasterListener.java:33) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:121) > at > org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:277) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1077) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:981) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:487) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:191) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:636) > at >
[jira] [Commented] (CLOUDSTACK-9349) Unable to detach root volume when using Hypervisor Type KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15241212#comment-15241212 ] Simon Weller commented on CLOUDSTACK-9349: -- Here's the commit: https://github.com/myENA/cloudstack/commit/d0a02640dfd4878da81a2e59588c4b5ff2a06401 We're going to complete some further testing prior to submitting a PR. > Unable to detach root volume when using Hypervisor Type KVM > --- > > Key: CLOUDSTACK-9349 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9349 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.5.1, 4.6.2, 4.7.1, 4.8.0, 4.9.0 > Environment: Centos 7 >Reporter: Simon Weller >Priority: Minor > Fix For: 4.7.2 > > > Back in 4.5, support was added in CLOUDSTACK-6284 for detaching root volumes. > The original support was meant to work with Xen, VMware and KVM. > After chatting with fuflo in the Cloudstack irc channel, it was pointed out > that a constraint was not correctly modified in VolumeApiServiceImpl.java to > allow the detach to occur when vm.getHypervisorType() == HypervisorType.KVM. > This is a very useful feature, as it allows us to simulate a snapshot revert > with Ceph by using createVolume sourced from a snapshot, then detaching and > reattaching the root volume (new root volume needs to be attached as > device=0). > I'm going to propose a PR for this shortly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9349) Unable to detach root volume when using Hypervisor Type KVM
Simon Weller created CLOUDSTACK-9349: Summary: Unable to detach root volume when using Hypervisor Type KVM Key: CLOUDSTACK-9349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9349 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.8.0, 4.7.1, 4.6.2, 4.5.1, 4.9.0 Environment: Centos 7 Reporter: Simon Weller Priority: Minor Fix For: 4.7.2 Back in 4.5, support was added in CLOUDSTACK-6284 for detaching root volumes. The original support was meant to work with Xen, VMware and KVM. After chatting with fuflo in the Cloudstack irc channel, it was pointed out that a constraint was not correctly modified in VolumeApiServiceImpl.java to allow the detach to occur when vm.getHypervisorType() == HypervisorType.KVM. This is a very useful feature, as it allows us to simulate a snapshot revert with Ceph by using createVolume sourced from a snapshot, then detaching and reattaching the root volume (new root volume needs to be attached as device=0). I'm going to propose a PR for this shortly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9209) Database HA not working on a fresh install on Ubuntu 12.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15206689#comment-15206689 ] Simon Weller commented on CLOUDSTACK-9209: -- Please see my PR tested on Centos 7 that addresses this. I expect the Ubuntu issue is the same, but I have no way of testing it. https://github.com/apache/cloudstack/pull/1428 Usage server issue is address here: https://github.com/apache/cloudstack/pull/1433 > Database HA not working on a fresh install on Ubuntu 12.04 > -- > > Key: CLOUDSTACK-9209 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9209 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.7.0 > Environment: Two Ubuntu 12.04 Management Servers, Mysql Master Master > Replication, Official community repository: > http://cloudstack.apt-get.eu/ubuntu/dists/precise/4.7/ >Reporter: Thomas >Priority: Blocker > > The cloudstack-management service will not come up because of this error: > 2016-01-05 16:15:00,899 INFO [c.c.u.d.T.Transaction] (main:null) (logid:) Is > Data Base High Availiability enabled? Ans : true > 2016-01-05 16:15:00,924 INFO [c.c.u.d.T.Transaction] (main:null) (logid:) > The slaves configured for Cloud Data base is/are : 192.168.0.90 > 2016-01-05 16:15:00,974 ERROR [c.c.u.d.Merovingian2] (main:null) (logid:) > Unable to get a new db connection > java.sql.SQLException: Invalid load balancing strategy > 'com.cloud.utils.db.StaticStrategy'. > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:934) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:931) > at com.mysql.jdbc.Util.loadExtensions(Util.java:588) > at > com.mysql.jdbc.LoadBalancingConnectionProxy.(LoadBalancingConnectionProxy.java:279) > at > com.mysql.jdbc.FailoverConnectionProxy.(FailoverConnectionProxy.java:66) > at > com.mysql.jdbc.NonRegisteringDriver.connectFailover(NonRegisteringDriver.java:382) > at > com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:301) > at java.sql.DriverManager.getConnection(DriverManager.java:571) > at java.sql.DriverManager.getConnection(DriverManager.java:215) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) > at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188) > at > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) > at > com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:202) > at com.cloud.utils.db.Merovingian2.(Merovingian2.java:68) > at > com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:88) > at > com.cloud.server.LockMasterListener.(LockMasterListener.java:33) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:121) > at > org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:277) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1077) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:981) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:487) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) > at >
[jira] [Commented] (CLOUDSTACK-9079) ipsec service is not running after restarting virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15206681#comment-15206681 ] Simon Weller commented on CLOUDSTACK-9079: -- Is this the same issue as https://issues.apache.org/jira/browse/CLOUDSTACK-9296? > ipsec service is not running after restarting virtual router > > > Key: CLOUDSTACK-9079 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9079 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM, Virtual Router >Affects Versions: 4.6.0 > Environment: ACS 4.5.1 upgraded to 4.6.0 >Reporter: Erik Weber >Priority: Critical > Labels: systemvm, virtualrouter, vpn > > after upgrading to 4.6.0 the ipsec service does no longer automatically start > and as an effect vpn does not work. > manually starting the ipsec service, or doing any vpn related configuration > (adding/deleting users) remedies the problem. > Steps to reproduce: > 1) Install ACS 4.6.0 > 2) Configure a VPC (I haven't tested with normal isolated networks) > 3) Enable remote access VPN, configure a user > 4) Confirm that VPN works > 5) Restart the VR > 6) Confirm that VPN does NOT work, either by trying to connect or by issuing > 'service ipsec status' on the VR -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9285) Cloudstack 4.8 can't connect to XEN and KVM hosts
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15180338#comment-15180338
]
Simon Weller commented on CLOUDSTACK-9285:
--
Pull request now available to address issue:
https://github.com/apache/cloudstack/pull/1429
> Cloudstack 4.8 can't connect to XEN and KVM hosts
> -
>
> Key: CLOUDSTACK-9285
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9285
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Xen
>Affects Versions: 4.8.0
> Environment: CentOS 7
>Reporter: Jens Fettig
>Priority: Blocker
> Attachments: agentfailure.pcap
>
>
> We used Cloudstack 4.7 in our testing environment. For future uses we updated
> to Cloudstack 4.8 for some tests. But after the update from 4.7 to 4.8
> cloudstack has some problems to connect to the hosts again. Here are the
> error logs.
> {code:title=XEN Server from the managment-server.log:|borderStyle=solid}
> 2016-02-15 11:22:03,476 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Loading directly
> connected host 13(xen5)
> 2016-02-15 11:22:06,204 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-1:ctx-aaf933f3) (logid:d157e37d) AutoScaling Monitor is
> running...
> 2016-02-15 11:22:06,206 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-2:ctx-8e2fc084) (logid:379074cb) VmStatsCollector is
> running...
> 2016-02-15 11:22:06,217 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-4:ctx-cc1cf960) (logid:b6397e2e) HostStatsCollector is
> running...
> 2016-02-15 11:22:06,298 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) StorageCollector is
> running...
> 2016-02-15 11:22:06,302 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) There is no secondary
> storage VM for secondary storage host cdsdev-secondary
> 2016-02-15 11:22:11,018 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) Begin cleanup expired
> async-jobs
> 2016-02-15 11:22:11,024 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) End cleanup expired
> async-jobs
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.x.r.XenServerConnectionPool]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Unable to create
> master connection to host(192.168.0.97) , due to The credentials given by the
> user are incorrect, so access has been denied, and you have not been issued a
> session handle.
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.Status] (ClusteredAgentManager
> Timer:ctx-43ef0a0a) (logid:82d7b1ec) Transition:[Resource state = Enabled,
> Agent event = AgentDisconnected, Host id = 13, name = xen5]
> 2016-02-15 11:22:11,101 WARN [c.c.a.m.ClusteredAgentManagerImpl]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) can not load
> directly connected host 13(xen5) due to
> com.cloud.utils.exception.CloudRuntimeException: Unable to create master
> connection to host(192.168.0.97) , due to The credentials given by the user
> are incorrect, so access has been denied, and you have not been issued a
> session handle.
> at
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:163)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.CheckXenHostInfo(CitrixResourceBase.java:523)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.configure(CitrixResourceBase.java:827)
> at
> com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:158)
> at
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:697)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:217)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:182)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:96)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:233)
> at
> org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30)
> 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)
>
[jira] [Commented] (CLOUDSTACK-9300) MySQL HA feature StaticStrategy throws exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15179974#comment-15179974 ] Simon Weller commented on CLOUDSTACK-9300: -- Pull requested submitted to master for consideration: https://github.com/apache/cloudstack/pull/1428 > MySQL HA feature StaticStrategy throws exception > > > Key: CLOUDSTACK-9300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: Future, 4.7.0, 4.8.0, 4.7.1 > Environment: Centos 7 >Reporter: Simon Weller >Priority: Minor > > 2016-03-03 12:00:13,204 INFO [c.c.u.d.T.Transaction] > (localhost-startStop-1:null) (logid:) Is Data Base High Availiability > enabled? Ans : true > 2016-03-03 12:00:13,239 INFO [c.c.u.d.T.Transaction] > (localhost-startStop-1:null) (logid:) The slaves configured for Cloud Data > base is/are : localhost,localhost > 2016-03-03 12:00:13,303 ERROR [c.c.u.d.Merovingian2] > (localhost-startStop-1:null) (logid:) Unable to get a new db connection > java.sql.SQLException: Invalid load balancing strategy > 'com.cloud.utils.db.StaticStrategy'. > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:924) > at com.mysql.jdbc.Util.loadExtensions(Util.java:602) > at > com.mysql.jdbc.LoadBalancingConnectionProxy.(LoadBalancingConnectionProxy.java:280) > at > com.mysql.jdbc.FailoverConnectionProxy.(FailoverConnectionProxy.java:67) > at > com.mysql.jdbc.NonRegisteringDriver.connectFailover(NonRegisteringDriver.java:433) > at > com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:346) > at java.sql.DriverManager.getConnection(DriverManager.java:571) > at java.sql.DriverManager.getConnection(DriverManager.java:215) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) > at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188) > at > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) > at > com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:202) > at com.cloud.utils.db.Merovingian2.(Merovingian2.java:68) > at > com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:88) > at > com.cloud.server.LockMasterListener.(LockMasterListener.java:33) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:121) > at > org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:277) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1077) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:981) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:487) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:191) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:636) > at >
[jira] [Commented] (CLOUDSTACK-9300) MySQL HA feature StaticStrategy throws exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15179853#comment-15179853 ] Simon Weller commented on CLOUDSTACK-9300: -- Pull request available here: https://github.com/myENA/cloudstack/pull/1 We'll build rpms and test. > MySQL HA feature StaticStrategy throws exception > > > Key: CLOUDSTACK-9300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: Future, 4.7.0, 4.8.0, 4.7.1 > Environment: Centos 7 >Reporter: Simon Weller >Priority: Minor > > 2016-03-03 12:00:13,204 INFO [c.c.u.d.T.Transaction] > (localhost-startStop-1:null) (logid:) Is Data Base High Availiability > enabled? Ans : true > 2016-03-03 12:00:13,239 INFO [c.c.u.d.T.Transaction] > (localhost-startStop-1:null) (logid:) The slaves configured for Cloud Data > base is/are : localhost,localhost > 2016-03-03 12:00:13,303 ERROR [c.c.u.d.Merovingian2] > (localhost-startStop-1:null) (logid:) Unable to get a new db connection > java.sql.SQLException: Invalid load balancing strategy > 'com.cloud.utils.db.StaticStrategy'. > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:924) > at com.mysql.jdbc.Util.loadExtensions(Util.java:602) > at > com.mysql.jdbc.LoadBalancingConnectionProxy.(LoadBalancingConnectionProxy.java:280) > at > com.mysql.jdbc.FailoverConnectionProxy.(FailoverConnectionProxy.java:67) > at > com.mysql.jdbc.NonRegisteringDriver.connectFailover(NonRegisteringDriver.java:433) > at > com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:346) > at java.sql.DriverManager.getConnection(DriverManager.java:571) > at java.sql.DriverManager.getConnection(DriverManager.java:215) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) > at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188) > at > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) > at > com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:202) > at com.cloud.utils.db.Merovingian2.(Merovingian2.java:68) > at > com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:88) > at > com.cloud.server.LockMasterListener.(LockMasterListener.java:33) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:121) > at > org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:277) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1077) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:981) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:487) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:191) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:636) > at >
[jira] [Commented] (CLOUDSTACK-9285) Cloudstack 4.8 can't connect to XEN and KVM hosts
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15178852#comment-15178852
]
Simon Weller commented on CLOUDSTACK-9285:
--
We have a fix for this.
We'll post a pull request tomorrow.
> Cloudstack 4.8 can't connect to XEN and KVM hosts
> -
>
> Key: CLOUDSTACK-9285
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9285
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Xen
>Affects Versions: 4.8.0
> Environment: CentOS 7
>Reporter: Jens Fettig
>Priority: Blocker
> Attachments: agentfailure.pcap
>
>
> We used Cloudstack 4.7 in our testing environment. For future uses we updated
> to Cloudstack 4.8 for some tests. But after the update from 4.7 to 4.8
> cloudstack has some problems to connect to the hosts again. Here are the
> error logs.
> {code:title=XEN Server from the managment-server.log:|borderStyle=solid}
> 2016-02-15 11:22:03,476 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Loading directly
> connected host 13(xen5)
> 2016-02-15 11:22:06,204 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-1:ctx-aaf933f3) (logid:d157e37d) AutoScaling Monitor is
> running...
> 2016-02-15 11:22:06,206 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-2:ctx-8e2fc084) (logid:379074cb) VmStatsCollector is
> running...
> 2016-02-15 11:22:06,217 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-4:ctx-cc1cf960) (logid:b6397e2e) HostStatsCollector is
> running...
> 2016-02-15 11:22:06,298 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) StorageCollector is
> running...
> 2016-02-15 11:22:06,302 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) There is no secondary
> storage VM for secondary storage host cdsdev-secondary
> 2016-02-15 11:22:11,018 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) Begin cleanup expired
> async-jobs
> 2016-02-15 11:22:11,024 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) End cleanup expired
> async-jobs
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.x.r.XenServerConnectionPool]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Unable to create
> master connection to host(192.168.0.97) , due to The credentials given by the
> user are incorrect, so access has been denied, and you have not been issued a
> session handle.
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.Status] (ClusteredAgentManager
> Timer:ctx-43ef0a0a) (logid:82d7b1ec) Transition:[Resource state = Enabled,
> Agent event = AgentDisconnected, Host id = 13, name = xen5]
> 2016-02-15 11:22:11,101 WARN [c.c.a.m.ClusteredAgentManagerImpl]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) can not load
> directly connected host 13(xen5) due to
> com.cloud.utils.exception.CloudRuntimeException: Unable to create master
> connection to host(192.168.0.97) , due to The credentials given by the user
> are incorrect, so access has been denied, and you have not been issued a
> session handle.
> at
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:163)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.CheckXenHostInfo(CitrixResourceBase.java:523)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.configure(CitrixResourceBase.java:827)
> at
> com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:158)
> at
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:697)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:217)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:182)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:96)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:233)
> at
> org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30)
> 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
>
[jira] [Commented] (CLOUDSTACK-9285) Cloudstack 4.8 can't connect to XEN and KVM hosts
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15178806#comment-15178806
]
Simon Weller commented on CLOUDSTACK-9285:
--
Offending code:
_connection = new NioClient("Agent", _shell.getHost(), _shell.getPort(),
_shell.getWorkers(), this);
do {
s_logger.info("Reconnecting...");
try {
_connection.start();
} catch (final NioConnectionException e) {
throw new CloudRuntimeException("Unable to start the
connection!", e); // <-- seems odd. This will probably kill the agent, but
leave Tomcat running
}
_shell.getBackoffAlgorithm().waitBeforeRetry();
} while (!_connection.isStartup());
s_logger.info("Connected to the server");
}
> Cloudstack 4.8 can't connect to XEN and KVM hosts
> -
>
> Key: CLOUDSTACK-9285
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9285
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Xen
>Affects Versions: 4.8.0
> Environment: CentOS 7
>Reporter: Jens Fettig
>Priority: Blocker
> Attachments: agentfailure.pcap
>
>
> We used Cloudstack 4.7 in our testing environment. For future uses we updated
> to Cloudstack 4.8 for some tests. But after the update from 4.7 to 4.8
> cloudstack has some problems to connect to the hosts again. Here are the
> error logs.
> {code:title=XEN Server from the managment-server.log:|borderStyle=solid}
> 2016-02-15 11:22:03,476 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Loading directly
> connected host 13(xen5)
> 2016-02-15 11:22:06,204 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-1:ctx-aaf933f3) (logid:d157e37d) AutoScaling Monitor is
> running...
> 2016-02-15 11:22:06,206 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-2:ctx-8e2fc084) (logid:379074cb) VmStatsCollector is
> running...
> 2016-02-15 11:22:06,217 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-4:ctx-cc1cf960) (logid:b6397e2e) HostStatsCollector is
> running...
> 2016-02-15 11:22:06,298 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) StorageCollector is
> running...
> 2016-02-15 11:22:06,302 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) There is no secondary
> storage VM for secondary storage host cdsdev-secondary
> 2016-02-15 11:22:11,018 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) Begin cleanup expired
> async-jobs
> 2016-02-15 11:22:11,024 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) End cleanup expired
> async-jobs
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.x.r.XenServerConnectionPool]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Unable to create
> master connection to host(192.168.0.97) , due to The credentials given by the
> user are incorrect, so access has been denied, and you have not been issued a
> session handle.
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.Status] (ClusteredAgentManager
> Timer:ctx-43ef0a0a) (logid:82d7b1ec) Transition:[Resource state = Enabled,
> Agent event = AgentDisconnected, Host id = 13, name = xen5]
> 2016-02-15 11:22:11,101 WARN [c.c.a.m.ClusteredAgentManagerImpl]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) can not load
> directly connected host 13(xen5) due to
> com.cloud.utils.exception.CloudRuntimeException: Unable to create master
> connection to host(192.168.0.97) , due to The credentials given by the user
> are incorrect, so access has been denied, and you have not been issued a
> session handle.
> at
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:163)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.CheckXenHostInfo(CitrixResourceBase.java:523)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.configure(CitrixResourceBase.java:827)
> at
> com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:158)
> at
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:697)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:217)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:182)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:96)
> at
>
[jira] [Commented] (CLOUDSTACK-9285) Cloudstack 4.8 can't connect to XEN and KVM hosts
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15178788#comment-15178788
]
Simon Weller commented on CLOUDSTACK-9285:
--
The agent logic seems to be built around expecting a connection refused, where
here (in our case) a RST is being sent back.
> Cloudstack 4.8 can't connect to XEN and KVM hosts
> -
>
> Key: CLOUDSTACK-9285
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9285
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Xen
>Affects Versions: 4.8.0
> Environment: CentOS 7
>Reporter: Jens Fettig
>Priority: Blocker
> Attachments: agentfailure.pcap
>
>
> We used Cloudstack 4.7 in our testing environment. For future uses we updated
> to Cloudstack 4.8 for some tests. But after the update from 4.7 to 4.8
> cloudstack has some problems to connect to the hosts again. Here are the
> error logs.
> {code:title=XEN Server from the managment-server.log:|borderStyle=solid}
> 2016-02-15 11:22:03,476 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Loading directly
> connected host 13(xen5)
> 2016-02-15 11:22:06,204 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-1:ctx-aaf933f3) (logid:d157e37d) AutoScaling Monitor is
> running...
> 2016-02-15 11:22:06,206 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-2:ctx-8e2fc084) (logid:379074cb) VmStatsCollector is
> running...
> 2016-02-15 11:22:06,217 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-4:ctx-cc1cf960) (logid:b6397e2e) HostStatsCollector is
> running...
> 2016-02-15 11:22:06,298 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) StorageCollector is
> running...
> 2016-02-15 11:22:06,302 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) There is no secondary
> storage VM for secondary storage host cdsdev-secondary
> 2016-02-15 11:22:11,018 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) Begin cleanup expired
> async-jobs
> 2016-02-15 11:22:11,024 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) End cleanup expired
> async-jobs
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.x.r.XenServerConnectionPool]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Unable to create
> master connection to host(192.168.0.97) , due to The credentials given by the
> user are incorrect, so access has been denied, and you have not been issued a
> session handle.
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.Status] (ClusteredAgentManager
> Timer:ctx-43ef0a0a) (logid:82d7b1ec) Transition:[Resource state = Enabled,
> Agent event = AgentDisconnected, Host id = 13, name = xen5]
> 2016-02-15 11:22:11,101 WARN [c.c.a.m.ClusteredAgentManagerImpl]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) can not load
> directly connected host 13(xen5) due to
> com.cloud.utils.exception.CloudRuntimeException: Unable to create master
> connection to host(192.168.0.97) , due to The credentials given by the user
> are incorrect, so access has been denied, and you have not been issued a
> session handle.
> at
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:163)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.CheckXenHostInfo(CitrixResourceBase.java:523)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.configure(CitrixResourceBase.java:827)
> at
> com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:158)
> at
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:697)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:217)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:182)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:96)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:233)
> at
> org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30)
> 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] [Updated] (CLOUDSTACK-9285) Cloudstack 4.8 can't connect to XEN and KVM hosts
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Weller updated CLOUDSTACK-9285:
-
Attachment: agentfailure.pcap
Here's a pcap of the issue. haproxy is sending a RST
> Cloudstack 4.8 can't connect to XEN and KVM hosts
> -
>
> Key: CLOUDSTACK-9285
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9285
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Xen
>Affects Versions: 4.8.0
> Environment: CentOS 7
>Reporter: Jens Fettig
>Priority: Blocker
> Attachments: agentfailure.pcap
>
>
> We used Cloudstack 4.7 in our testing environment. For future uses we updated
> to Cloudstack 4.8 for some tests. But after the update from 4.7 to 4.8
> cloudstack has some problems to connect to the hosts again. Here are the
> error logs.
> {code:title=XEN Server from the managment-server.log:|borderStyle=solid}
> 2016-02-15 11:22:03,476 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Loading directly
> connected host 13(xen5)
> 2016-02-15 11:22:06,204 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-1:ctx-aaf933f3) (logid:d157e37d) AutoScaling Monitor is
> running...
> 2016-02-15 11:22:06,206 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-2:ctx-8e2fc084) (logid:379074cb) VmStatsCollector is
> running...
> 2016-02-15 11:22:06,217 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-4:ctx-cc1cf960) (logid:b6397e2e) HostStatsCollector is
> running...
> 2016-02-15 11:22:06,298 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) StorageCollector is
> running...
> 2016-02-15 11:22:06,302 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) There is no secondary
> storage VM for secondary storage host cdsdev-secondary
> 2016-02-15 11:22:11,018 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) Begin cleanup expired
> async-jobs
> 2016-02-15 11:22:11,024 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) End cleanup expired
> async-jobs
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.x.r.XenServerConnectionPool]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Unable to create
> master connection to host(192.168.0.97) , due to The credentials given by the
> user are incorrect, so access has been denied, and you have not been issued a
> session handle.
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.Status] (ClusteredAgentManager
> Timer:ctx-43ef0a0a) (logid:82d7b1ec) Transition:[Resource state = Enabled,
> Agent event = AgentDisconnected, Host id = 13, name = xen5]
> 2016-02-15 11:22:11,101 WARN [c.c.a.m.ClusteredAgentManagerImpl]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) can not load
> directly connected host 13(xen5) due to
> com.cloud.utils.exception.CloudRuntimeException: Unable to create master
> connection to host(192.168.0.97) , due to The credentials given by the user
> are incorrect, so access has been denied, and you have not been issued a
> session handle.
> at
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:163)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.CheckXenHostInfo(CitrixResourceBase.java:523)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.configure(CitrixResourceBase.java:827)
> at
> com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:158)
> at
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:697)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:217)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:182)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:96)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:233)
> at
> org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30)
> 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
>
[jira] [Commented] (CLOUDSTACK-9285) Cloudstack 4.8 can't connect to XEN and KVM hosts
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15178769#comment-15178769
]
Simon Weller commented on CLOUDSTACK-9285:
--
Are you using a load balancer between your management server and the host agent?
We are seeing this with haproxy between our agents and management server. If we
down all the management servers, the agents connection is cut to the load
balancer and the agent throws a "Could not find exception:
com.cloud.utils.exception.NioConnectionException in error code list for
exceptions."
We're digging into this right now.
> Cloudstack 4.8 can't connect to XEN and KVM hosts
> -
>
> Key: CLOUDSTACK-9285
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9285
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Xen
>Affects Versions: 4.8.0
> Environment: CentOS 7
>Reporter: Jens Fettig
>Priority: Blocker
>
> We used Cloudstack 4.7 in our testing environment. For future uses we updated
> to Cloudstack 4.8 for some tests. But after the update from 4.7 to 4.8
> cloudstack has some problems to connect to the hosts again. Here are the
> error logs.
> {code:title=XEN Server from the managment-server.log:|borderStyle=solid}
> 2016-02-15 11:22:03,476 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Loading directly
> connected host 13(xen5)
> 2016-02-15 11:22:06,204 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-1:ctx-aaf933f3) (logid:d157e37d) AutoScaling Monitor is
> running...
> 2016-02-15 11:22:06,206 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-2:ctx-8e2fc084) (logid:379074cb) VmStatsCollector is
> running...
> 2016-02-15 11:22:06,217 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-4:ctx-cc1cf960) (logid:b6397e2e) HostStatsCollector is
> running...
> 2016-02-15 11:22:06,298 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) StorageCollector is
> running...
> 2016-02-15 11:22:06,302 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) There is no secondary
> storage VM for secondary storage host cdsdev-secondary
> 2016-02-15 11:22:11,018 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) Begin cleanup expired
> async-jobs
> 2016-02-15 11:22:11,024 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) End cleanup expired
> async-jobs
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.x.r.XenServerConnectionPool]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Unable to create
> master connection to host(192.168.0.97) , due to The credentials given by the
> user are incorrect, so access has been denied, and you have not been issued a
> session handle.
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.Status] (ClusteredAgentManager
> Timer:ctx-43ef0a0a) (logid:82d7b1ec) Transition:[Resource state = Enabled,
> Agent event = AgentDisconnected, Host id = 13, name = xen5]
> 2016-02-15 11:22:11,101 WARN [c.c.a.m.ClusteredAgentManagerImpl]
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) can not load
> directly connected host 13(xen5) due to
> com.cloud.utils.exception.CloudRuntimeException: Unable to create master
> connection to host(192.168.0.97) , due to The credentials given by the user
> are incorrect, so access has been denied, and you have not been issued a
> session handle.
> at
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:163)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.CheckXenHostInfo(CitrixResourceBase.java:523)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.configure(CitrixResourceBase.java:827)
> at
> com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:158)
> at
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:697)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:217)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:182)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:96)
> at
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:233)
> at
> org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30)
> at
>
[jira] [Commented] (CLOUDSTACK-9300) MySQL HA feature StaticStrategy throws exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15178748#comment-15178748 ] Simon Weller commented on CLOUDSTACK-9300: -- This appears to be a 2 part issue. Got tomcat to dump the class loader info into journald and got this... WARNING: Problem with directory [/usr/share/cloudstack-mysql-ha/lib/*jar], exists: [false], isDirectory: [false], canRead I changed ​*jar to *​.jar in the catalina.properities common.loader and that issue was no longer seen in the class loader logs.. After further debugging, I found that having mysql-connector-java.jar referenced in the global class path in /etc/sysconfig/cloudstack-management prevents the inherited StaticStrategy class from loading. If you remove that and change to CLASSPATH=/etc/cloudstack/management:/usr/share/cloudstack-common:/usr/share/cloudstack-management/setup StaticStrategy loads It was already referenced in the catalina.properities common.loader I've tested that fix now on master and on 4.7.1. We'll complete testing after building new master rpms and then we'll submit a pull request on this. > MySQL HA feature StaticStrategy throws exception > > > Key: CLOUDSTACK-9300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: Future, 4.7.0, 4.8.0, 4.7.1 > Environment: Centos 7 >Reporter: Simon Weller >Priority: Minor > > 2016-03-03 12:00:13,204 INFO [c.c.u.d.T.Transaction] > (localhost-startStop-1:null) (logid:) Is Data Base High Availiability > enabled? Ans : true > 2016-03-03 12:00:13,239 INFO [c.c.u.d.T.Transaction] > (localhost-startStop-1:null) (logid:) The slaves configured for Cloud Data > base is/are : localhost,localhost > 2016-03-03 12:00:13,303 ERROR [c.c.u.d.Merovingian2] > (localhost-startStop-1:null) (logid:) Unable to get a new db connection > java.sql.SQLException: Invalid load balancing strategy > 'com.cloud.utils.db.StaticStrategy'. > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:924) > at com.mysql.jdbc.Util.loadExtensions(Util.java:602) > at > com.mysql.jdbc.LoadBalancingConnectionProxy.(LoadBalancingConnectionProxy.java:280) > at > com.mysql.jdbc.FailoverConnectionProxy.(FailoverConnectionProxy.java:67) > at > com.mysql.jdbc.NonRegisteringDriver.connectFailover(NonRegisteringDriver.java:433) > at > com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:346) > at java.sql.DriverManager.getConnection(DriverManager.java:571) > at java.sql.DriverManager.getConnection(DriverManager.java:215) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) > at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188) > at > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) > at > com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:202) > at com.cloud.utils.db.Merovingian2.(Merovingian2.java:68) > at > com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:88) > at > com.cloud.server.LockMasterListener.(LockMasterListener.java:33) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:121) > at > org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:277) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1077) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:981) > at >
[jira] [Created] (CLOUDSTACK-9300) MySQL HA feature StaticStrategy throws exception
Simon Weller created CLOUDSTACK-9300: Summary: MySQL HA feature StaticStrategy throws exception Key: CLOUDSTACK-9300 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9300 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: Future, 4.7.0, 4.8.0, 4.7.1 Environment: Centos 7 Reporter: Simon Weller Priority: Minor 2016-03-03 12:00:13,204 INFO [c.c.u.d.T.Transaction] (localhost-startStop-1:null) (logid:) Is Data Base High Availiability enabled? Ans : true 2016-03-03 12:00:13,239 INFO [c.c.u.d.T.Transaction] (localhost-startStop-1:null) (logid:) The slaves configured for Cloud Data base is/are : localhost,localhost 2016-03-03 12:00:13,303 ERROR [c.c.u.d.Merovingian2] (localhost-startStop-1:null) (logid:) Unable to get a new db connection java.sql.SQLException: Invalid load balancing strategy 'com.cloud.utils.db.StaticStrategy'. at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:924) at com.mysql.jdbc.Util.loadExtensions(Util.java:602) at com.mysql.jdbc.LoadBalancingConnectionProxy.(LoadBalancingConnectionProxy.java:280) at com.mysql.jdbc.FailoverConnectionProxy.(FailoverConnectionProxy.java:67) at com.mysql.jdbc.NonRegisteringDriver.connectFailover(NonRegisteringDriver.java:433) at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:346) at java.sql.DriverManager.getConnection(DriverManager.java:571) at java.sql.DriverManager.getConnection(DriverManager.java:215) at org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) at com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:202) at com.cloud.utils.db.Merovingian2.(Merovingian2.java:68) at com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:88) at com.cloud.server.LockMasterListener.(LockMasterListener.java:33) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148) at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:121) at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:277) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1077) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:981) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:487) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:191) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:636) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:934) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479) at org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145) at
[jira] [Commented] (CLOUDSTACK-9209) Database HA not working on a fresh install on Ubuntu 12.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15154586#comment-15154586 ] Simon Weller commented on CLOUDSTACK-9209: -- Have you got the MySQL ha jar working on Centos 7, with 4.7.x? > Database HA not working on a fresh install on Ubuntu 12.04 > -- > > Key: CLOUDSTACK-9209 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9209 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.7.0 > Environment: Two Ubuntu 12.04 Management Servers, Mysql Master Master > Replication, Official community repository: > http://cloudstack.apt-get.eu/ubuntu/dists/precise/4.7/ >Reporter: Thomas >Priority: Blocker > > The cloudstack-management service will not come up because of this error: > 2016-01-05 16:15:00,899 INFO [c.c.u.d.T.Transaction] (main:null) (logid:) Is > Data Base High Availiability enabled? Ans : true > 2016-01-05 16:15:00,924 INFO [c.c.u.d.T.Transaction] (main:null) (logid:) > The slaves configured for Cloud Data base is/are : 192.168.0.90 > 2016-01-05 16:15:00,974 ERROR [c.c.u.d.Merovingian2] (main:null) (logid:) > Unable to get a new db connection > java.sql.SQLException: Invalid load balancing strategy > 'com.cloud.utils.db.StaticStrategy'. > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:934) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:931) > at com.mysql.jdbc.Util.loadExtensions(Util.java:588) > at > com.mysql.jdbc.LoadBalancingConnectionProxy.(LoadBalancingConnectionProxy.java:279) > at > com.mysql.jdbc.FailoverConnectionProxy.(FailoverConnectionProxy.java:66) > at > com.mysql.jdbc.NonRegisteringDriver.connectFailover(NonRegisteringDriver.java:382) > at > com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:301) > at java.sql.DriverManager.getConnection(DriverManager.java:571) > at java.sql.DriverManager.getConnection(DriverManager.java:215) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) > at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188) > at > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) > at > com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:202) > at com.cloud.utils.db.Merovingian2.(Merovingian2.java:68) > at > com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:88) > at > com.cloud.server.LockMasterListener.(LockMasterListener.java:33) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:121) > at > org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:277) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1077) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:981) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:487) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:191) > at >
[jira] [Commented] (CLOUDSTACK-9209) Database HA not working on a fresh install on Ubuntu 12.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152490#comment-15152490 ] Simon Weller commented on CLOUDSTACK-9209: -- Thomas, Do you have the log4j ubuntu package installed? - Si > Database HA not working on a fresh install on Ubuntu 12.04 > -- > > Key: CLOUDSTACK-9209 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9209 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.7.0 > Environment: Two Ubuntu 12.04 Management Servers, Mysql Master Master > Replication, Official community repository: > http://cloudstack.apt-get.eu/ubuntu/dists/precise/4.7/ >Reporter: Thomas >Priority: Blocker > > The cloudstack-management service will not come up because of this error: > 2016-01-05 16:15:00,899 INFO [c.c.u.d.T.Transaction] (main:null) (logid:) Is > Data Base High Availiability enabled? Ans : true > 2016-01-05 16:15:00,924 INFO [c.c.u.d.T.Transaction] (main:null) (logid:) > The slaves configured for Cloud Data base is/are : 192.168.0.90 > 2016-01-05 16:15:00,974 ERROR [c.c.u.d.Merovingian2] (main:null) (logid:) > Unable to get a new db connection > java.sql.SQLException: Invalid load balancing strategy > 'com.cloud.utils.db.StaticStrategy'. > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:934) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:931) > at com.mysql.jdbc.Util.loadExtensions(Util.java:588) > at > com.mysql.jdbc.LoadBalancingConnectionProxy.(LoadBalancingConnectionProxy.java:279) > at > com.mysql.jdbc.FailoverConnectionProxy.(FailoverConnectionProxy.java:66) > at > com.mysql.jdbc.NonRegisteringDriver.connectFailover(NonRegisteringDriver.java:382) > at > com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:301) > at java.sql.DriverManager.getConnection(DriverManager.java:571) > at java.sql.DriverManager.getConnection(DriverManager.java:215) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) > at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188) > at > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) > at > com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:202) > at com.cloud.utils.db.Merovingian2.(Merovingian2.java:68) > at > com.cloud.utils.db.Merovingian2.createLockMaster(Merovingian2.java:88) > at > com.cloud.server.LockMasterListener.(LockMasterListener.java:33) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:148) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:121) > at > org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:277) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1077) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:981) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:487) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) > at > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:290) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:191) > at >
[jira] [Commented] (CLOUDSTACK-8943) KVM HA is broken, let's fix it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14974765#comment-14974765 ] Simon Weller commented on CLOUDSTACK-8943: -- So we've been looking around the code today and noticed that ipmi has already been implemented in the bare metal server plugin. scripts/util/ipmi.py is a wrapper for /usr/bin/ipmitool and is called out by: plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BareMetalResourceBase.java plugins/hypervisors/baremetal/src/com/cloud/baremetal/manager/BareMetalDiscoverer.java > KVM HA is broken, let's fix it > -- > > Key: CLOUDSTACK-8943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8943 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Environment: Linux distros with KVM/libvirt >Reporter: Nux > > Currently KVM HA works by monitoring an NFS based heartbeat file and it can > often fail whenever this network share becomes slower, causing the > hypervisors to reboot. > This can be particularly annoying when you have different kinds of primary > storages in place which are working fine (people running CEPH etc). > Having to wait for the affected HV which triggered this to come back and > declare it's not running VMs is a bad idea; this HV could require hours or > days of maintenance! > This is embarrassing. How can we fix it? Ideas, suggestions? How are other > hypervisors doing it? > Let's discuss, test, implement. :) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8943) KVM HA is broken, let's fix it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14954834#comment-14954834 ] Simon Weller commented on CLOUDSTACK-8943: -- In my opinion, you have to be careful with quorum style functionality on the host itself. It can make the hosts overly complicated, especially when you have a lot of hosts within a cluster. If you've built your storage correctly, it should be highly unlikely that you lose your storage (unless you're running NFS with no HA functionality). And if you do, that becomes a cluster problem assuming you've dedicated storage just to that cluster. We've been running quorums using Redhat Cluster Suite for years on top of CLVM SAN backed storage and it has proven to be very difficult to manage as our infrastructure has grown. You really want to keep your hosts as simple as possible. Now, if the CS agent was leveraged to provide a deeper view into what was going on with the host (and the attached storage), it may be you could gather enough information to make a determination of what should be done with a given host that appeared to be misbehaving. You could then fence it remotely using IPMI and that's what I was indicating above. That would simulate the principals of a quorum without having to add a complicated clustering layer onto the hosts. > KVM HA is broken, let's fix it > -- > > Key: CLOUDSTACK-8943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8943 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Environment: Linux distros with KVM/libvirt >Reporter: Nux > > Currently KVM HA works by monitoring an NFS based heartbeat file and it can > often fail whenever this network share becomes slower, causing the > hypervisors to reboot. > This can be particularly annoying when you have different kinds of primary > storages in place which are working fine (people running CEPH etc). > Having to wait for the affected HV which triggered this to come back and > declare it's not running VMs is a bad idea; this HV could require hours or > days of maintenance! > This is embarrassing. How can we fix it? Ideas, suggestions? How are other > hypervisors doing it? > Let's discuss, test, implement. :) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8943) KVM HA is broken, let's fix it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14953017#comment-14953017 ] Simon Weller commented on CLOUDSTACK-8943: -- Perhaps one of the easiest ways to deal with this would be to introduce IPMI functionality into Cloudstack, so a KVM host could be fenced via an out-of-band IPMI interface. Upon successful fencing, CS MGMT could mark the host as disabled. I know deleting a host is enough to force CS MGMT to attempt to restart affected VMs on other hosts, but I'm not sure whether disabling a host will at this point in time. There are other considerations that will need to be made as well, especially around storage locking (e.g. CEPH). > KVM HA is broken, let's fix it > -- > > Key: CLOUDSTACK-8943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8943 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Environment: Linux distros with KVM/libvirt >Reporter: Nux > > Currently KVM HA works by monitoring an NFS based heartbeat file and it can > often fail whenever this network share becomes slower, causing the > hypervisors to reboot. > This can be particularly annoying when you have different kinds of primary > storages in place which are working fine (people running CEPH etc). > Having to wait for the affected HV which triggered this to come back and > declare it's not running VMs is a bad idea; this HV could require hours or > days of maintenance! > This is embarrassing. How can we fix it? Ideas, suggestions? How are other > hypervisors doing it? > Let's discuss, test, implement. :) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14143170#comment-14143170
]
Simon Weller commented on CLOUDSTACK-6460:
--
I added some debugging into getStoragePool, and createPhysicalDisk.
Agent logs in debug:
2014-09-22 07:03:50,164{GMT} DEBUG [cloud.agent.Agent]
(agentRequest-Handler-4:) Request:Seq 3-192151576: { Cmd , MgmtId:
144343444026, via: 3, Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.CreateObjectCommand:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:a8dbbcb0-5f27-470a-a482-e00ac0e68a75,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:076d1cd7-9c80-4302-8e13-ea8187a9a96b,id:201,poolType:CLVM,host:localhost,path:/csstore01,port:0,url:CLVM://localhost//csstore01/?ROLE=PrimarySTOREUUID=076d1cd7-9c80-4302-8e13-ea8187a9a96b}},name:test10_2,size:5368709120,volumeId:17461,accountId:6,id:17461,hypervisorType:KVM}},wait:0}}]
}
2014-09-22 07:03:50,165{GMT} DEBUG [cloud.agent.Agent]
(agentRequest-Handler-4:) Processing command:
org.apache.cloudstack.storage.command.CreateObjectCommand
2014-09-22 07:03:50,172{GMT} DEBUG [kvm.storage.LibvirtStorageAdaptor]
(agentRequest-Handler-4:) getStoragePool: logical
2014-09-22 07:03:52,044{GMT} DEBUG [kvm.storage.LibvirtStorageAdaptor]
(agentRequest-Handler-4:) createPhysicalDisk format is raw
2014-09-22 07:03:52,045{GMT} DEBUG [kvm.storage.LibvirtStorageAdaptor]
(agentRequest-Handler-4:) volume
namea8dbbcb0-5f27-470a-a482-e00ac0e68a75/name
capacity5368709120/capacity
target
format type='raw'/
permissionsmode0744/mode/permissions/target
/volume
Mgmt logs:
2014-09-22 07:03:50,133 DEBUG [c.c.s.StorageManagerImpl]
(Job-Executor-7:ctx-e61f9a16 ctx-e997a276) Checking pool: 201 for volume
allocation [Vol[17461|vm=null|DATADISK]], maxSize : 1099507433472,
totalAllocatedSize : 83823165440, askingSize : 5368709120, allocated disable
threshold: 0.85
2014-09-22 07:03:50,133 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-7:ctx-e61f9a16 ctx-e997a276) ClusterScopeStoragePoolAllocator
returning 1 suitable storage pools
2014-09-22 07:03:50,133 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(Job-Executor-7:ctx-e61f9a16 ctx-e997a276) Trying to create
org.apache.cloudstack.storage.volume.VolumeObject@76e38e5e on
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@5597fa4c
2014-09-22 07:03:50,147 DEBUG
[o.a.c.s.d.d.CloudStackPrimaryDataStoreDriverImpl] (Job-Executor-7:ctx-e61f9a16
ctx-e997a276) Creating volume:
org.apache.cloudstack.storage.volume.VolumeObject@53789cfc
2014-09-22 07:03:50,151 DEBUG [c.c.a.t.Request] (Job-Executor-7:ctx-e61f9a16
ctx-e997a276) Seq 3-192151576: Sending { Cmd , MgmtId: 144343444026, via:
3(csh01-lab.zone01.nsvltn.cloud.ena.net), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.CreateObjectCommand:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:a8dbbcb0-5f27-470a-a482-e00ac0e68a75,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:076d1cd7-9c80-4302-8e13-ea8187a9a96b,id:201,poolType:CLVM,host:localhost,path:/csstore01,port:0,url:CLVM://localhost//csstore01/?ROLE=PrimarySTOREUUID=076d1cd7-9c80-4302-8e13-ea8187a9a96b}},name:test10_2,size:5368709120,volumeId:17461,accountId:6,id:17461,hypervisorType:KVM}},wait:0}}]
}
2014-09-22 07:03:52,871 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-7:null) SeqA 9-1551798: Processing Seq 9-1551798: { Cmd
, MgmtId: -1, via: 9, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:22358,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2014-09-22 07:03:52,873 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-7:null) SeqA 9-1551798: Sending Seq 9-1551798: { Ans: ,
MgmtId: 144343444026, via: 9, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2014-09-22 07:03:53,145 DEBUG [c.c.a.ApiServlet] (catalina-exec-4:ctx-27d5d351)
===START=== 172.27.2.190 -- GET
command=queryAsyncJobResultjobId=3b9a0e48-cca9-49bd-8ba5-f3ee34fecd0aresponse=jsonsessionkey=7fKPZgeg1u%2Bw7dPiPjqnCTze56k%3Dprojectid=729be1b4-429f-410c-b4fb-a9f5bfa3ec50_=1411387433075
2014-09-22 07:03:53,154 DEBUG [c.c.a.ApiServlet] (catalina-exec-4:ctx-27d5d351
ctx-01bf906b) ===END=== 172.27.2.190 -- GET
command=queryAsyncJobResultjobId=3b9a0e48-cca9-49bd-8ba5-f3ee34fecd0aresponse=jsonsessionkey=7fKPZgeg1u%2Bw7dPiPjqnCTze56k%3Dprojectid=729be1b4-429f-410c-b4fb-a9f5bfa3ec50_=1411387433075
2014-09-22 07:03:53,613 DEBUG [c.c.a.t.Request] (AgentManager-Handler-1:null)
Seq 3-192151576: Processing: { Ans: , MgmtId: 144343444026, via: 3, Ver: v1,
Flags: 10,
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14138882#comment-14138882
]
Simon Weller commented on CLOUDSTACK-6460:
--
Some more debugging of the database issue:
org.apache.cloudstack.storage.command.AttachCommand:
{disk:
{data:
{org.apache.cloudstack.storage.to.VolumeObjectTO:
{uuid:558b0140-8d98-429c-9de3-44dc7ec96f51,volumeType:DATADISK,dataStore:
{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:
{uuid:076d1cd7-9c80-4302-8e13-ea8187a9a96b,id:201,poolType:CLVM,host:localhost,path:/csstore01,port:0,url:CLVM://localhost//csstore01/?ROLE=PrimarySTOREUUID=076d1cd7-9c80-4302-8e13-ea8187a9a96b
}
},name:test7_2,size:5368709120,path:558b0140-8d98-429c-9de3-44dc7ec96f51,volumeId:17456,accountId:6,format:QCOW2,id:17456,hypervisorType:KVM
}
}
,diskSeq:5,path:558b0140-8d98-429c-9de3-44dc7ec96f51,type:DATADISK,_details:
{managed:false,storagePort:0,storageHost:localhost,volumeSize:5368709120
}
},vmName:i-6-22370-VM,inSeq:false,wait:0}}]
}
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: CLOUDSTACK-6460-darrentang.patch,
CLOUDSTACK-6460-darrentang_2.patch, cloudstack-6460.patch,
cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136210#comment-14136210 ] Simon Weller commented on CLOUDSTACK-6460: -- I've been digging into this a lot today, and I think I've narrowed the problem down to the attachVolume functionality. It appears that during the attacheVolume operation, the volume format is being set to QCOW2 in the database. Steps to reproduce this: 1. Create a new volume either via GUI or API. Database shows format field to be NULL. 2. Attach volume to VM. At this point the format field is set to QCOW2, even though it's really RAW. How's the database table data: After Volume Creation: mysql select * from volumes where id='17451'; +---++---+-+--+-+---+-+--+++--++++-+-+---+--+-++-+-+--+-+-+---++--+---+++++--+--+---+ | id| account_id | domain_id | pool_id | last_pool_id | instance_id | device_id | name| uuid | size | folder | path | pod_id | data_center_id | iscsi_name | host_ip | volume_type | pool_type | disk_offering_id | template_id | first_snapshot_backup_uuid | recreatable | created | attached | updated | removed | state | chain_info | update_count | disk_type | vm_snapshot_chain_size | iso_id | display_volume | format | min_iops | max_iops | hv_ss_reserve | +---++---+-+--+-+---+-+--+++--++++-+-+---+--+-++-+-+--+-+-+---++--+---+++++--+--+---+ | 17451 | 6 | 1 |NULL | NULL |NULL | NULL | testnew | 9fc165e4-d383-4367-ab0a-9a55e5566110 | 5368709120 | NULL | NULL | NULL | 2 | NULL | NULL| DATADISK| NULL |3 |NULL | NULL | 0 | 2014-09-16 20:14:25 | NULL | 2014-09-16 20:14:25 | NULL| Allocated | NULL |0 | NULL | NULL | NULL | 1 | NULL | NULL | NULL | NULL | +---++---+-+--+-+---+-+--+++--++++-+-+---+--+-++-+-+--+-+-+---++--+---+++++--+--+---+ 1 row in set (0.00 sec) mysql select * from storage_pool; +-+---+--+---+--++++---++--+---++-+-+-++---+-++-+---+ | id | name | uuid | pool_type | port | data_center_id | pod_id | cluster_id | used_bytes| capacity_bytes | host_address | user_info | path | created | removed | update_time | status | storage_provider_name | scope | hypervisor | managed | capacity_iops | +-+---+--+---+--++++---++--+---++-+-+-++---+-++-+---+ | 201 | clvm1 | 076d1cd7-9c80-4302-8e13-ea8187a9a96b | CLVM |0 | 2 | 2 | 2 | 1022336434176 | 1099507433472 | localhost | NULL | /csstore01 | 2014-01-15 22:02:18 | NULL| NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 202 | csstore02 | 8f624e46-33fe-473c-9d05-62aebc151d1b | CLVM |0 | 2 | 2 | 2 | 1019077459968 | 1099507433472 | localhost | NULL |
[jira] [Updated] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Weller updated CLOUDSTACK-6460:
-
Attachment: CLOUDSTACK-6460-darrentang_2.patch
New patch for darrentang.
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: CLOUDSTACK-6460-darrentang.patch,
CLOUDSTACK-6460-darrentang_2.patch, cloudstack-6460.patch,
cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14134040#comment-14134040
]
Simon Weller commented on CLOUDSTACK-6460:
--
darrentang,
Please use the new patch I just uploaded (CLOUDSTACK-6460-darrentang_2.patch).
qemu-img is no longer being used, as the code is now detecting its raw to raw,
so it's using cp instead.
The issue here seems to be that for some reason .raw is being appended onto the
path, and rather than using qemu-img to determine the file type, the code makes
as assumption based on the incorrect file extension that it's a raw file, when
it fact it was a QCOW2 file. This patch should get you going, although really a
hack. The entire code based around this functionality needs to be re-factored,
as it's using lots of (bad) assumptions, and numerous ugly conditional
statements that have been jacked into the code via different developers for new
features.
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: CLOUDSTACK-6460-darrentang.patch,
CLOUDSTACK-6460-darrentang_2.patch, cloudstack-6460.patch,
cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131507#comment-14131507
]
Simon Weller commented on CLOUDSTACK-6460:
--
darrentang,
We're running 4.3 with this patch. Can you be a bit more specific when you say
it doesn't work?
Are you having problems applying the patch, or does a successful patch and
rebuild not fix the problem for you?
- Si
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: cloudstack-6460.patch, cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131620#comment-14131620
]
Simon Weller commented on CLOUDSTACK-6460:
--
I'll take a look and see if I can figure out what's going on.
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: cloudstack-6460.patch, cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
[jira] [Updated] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Weller updated CLOUDSTACK-6460:
-
Attachment: CLOUDSTACK-6460-darrentang.patch
Test patch for darrentang.
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: CLOUDSTACK-6460-darrentang.patch, cloudstack-6460.patch,
cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14132110#comment-14132110
]
Simon Weller commented on CLOUDSTACK-6460:
--
darrentang,
I've uploaded a patch for you to test. All I've tested thus far is that is
compiles, but I haven't done a feature test yet with your issue. I'll try and
get to that this weekend, but I didn't want to hold you up if you have time to
test yourself.
The patch is against the 4.3 source tarball.
- Si
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: CLOUDSTACK-6460-darrentang.patch, cloudstack-6460.patch,
cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14042381#comment-14042381
]
Simon Weller commented on CLOUDSTACK-6460:
--
I've submitted a patch for review against master for this issue.
https://reviews.apache.org/r/22939/
- Si
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: cloudstack-6460.patch, cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
[jira] [Updated] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Weller updated CLOUDSTACK-6460:
-
Attachment: cloudstack-6460_44.patch
Patch for 4.4
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: cloudstack-6460.patch, cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14039847#comment-14039847
]
Simon Weller commented on CLOUDSTACK-6460:
--
I wrote a patch for this yesterday that is identical to yours. I've been
testing it, and it does seem to address the problem. I agree that source will
always be raw, so unless we're missing something very obvious here, this should
take care of the problem.
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
[jira] [Updated] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Weller updated CLOUDSTACK-6460:
-
Attachment: cloudstack-6460.patch
CS 4.3 patch attached
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: cloudstack-6460.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14038795#comment-14038795
]
Simon Weller commented on CLOUDSTACK-6460:
--
This issue also affects 4.3 and 4.4 from what I can tell during my testing.
Affected versions needs to be changed so this gets some attention.
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14018502#comment-14018502 ] Simon Weller commented on CLOUDSTACK-6464: -- After reading the comments from Marcus on the vlan table, I took a look at my vlan table in my lab, and noticed the vlan_id just displayed the vlan (22). So I changed that to vlan://22, restarted the management server, then restarted a project virtual router pair. The network assignments appeared to be normal on router startup. I then acquired a new ip to the network assigned it to a LB rule and added a VM. The alias was correctly assigned to eth2 (my public interface). I then removed the ip, and the ip was correctly removed from eth2. I'll do a bit more testing after I get back from vacation, but at the current time this certainly appears to fix the issue I was experiencing. - Si [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used -- Key: CLOUDSTACK-6464 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464 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: sadhu suresh Priority: Critical Fix For: 4.4.0 Steps: 1. create a KVM basic zone with 2 nics on host (pre 4.3 build) 2.use cloudbr0 for management and cloudbr1 for guest by specifying the traffic labels in the physical networks. 3.deploy few vms 4.upgrade to felton GA build as per the Upgrade instructions. actual result: Upgrade successful but all the vnets that were attached to cloudbr1 before upgrade are attached to cloudbr0. Due to this network connectivity is lost. Expected result: Even after upgrade ,all the vnets should be attached to the same bridge as before upgrade. ex: before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after upgrade and VM stop/start. the network rules are getting programmed in cloudbr0 .check below output ,984 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Executing: /usr/share/cloudstack-common/scripts/vm/network/security_group.py default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0: dumpxml output for i-5-616-VM after upgrade( after VM restart) * virsh # dumpxml 38 domain type='kvm' id='38' namei-5-616-VM/name uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid descriptionOther CentOS (64-bit)/description memory unit='KiB'2097152/memory currentMemory unit='KiB'2097152/currentMemory vcpu placement='static'1/vcpu cputune shares1000/shares /cputune os type arch='x86_64' machine='rhel6.2.0'hvm/type boot dev='cdrom'/ boot dev='hd'/ /os features acpi/ apic/ pae/ /features cpu /cpu clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashdestroy/on_crash devices emulator/usr/libexec/qemu-kvm/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/ target dev='hda' bus='ide'/ alias name='ide0-0-0'/ address type='drive' controller='0' bus='0' target='0' unit='0'/ /disk disk type='file' device='cdrom' driver name='qemu' type='raw' cache='none'/ target dev='hdc' bus='ide'/ readonly/ alias name='ide0-1-0'/ address type='drive' controller='0' bus='1' target='0' unit='0'/ /disk controller type='usb' index='0' alias name='usb0'/ address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller controller type='ide' index='0' alias name='ide0'/ address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller interface type='bridge' mac address='06:14:48:00:00:7f'/ source bridge='cloudbr0'/ target dev='vnet15'/ model type='e1000'/ bandwidth inbound average='25600' peak='25600'/ outbound average='25600' peak='25600'/ /bandwidth alias name='net0'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' source path='/dev/pts/12'/ target port='0'/ alias name='serial0'/ /serial console type='pty' tty='/dev/pts/12' source path='/dev/pts/12'/ target type='serial' port='0'/ alias name='serial0'/ /console input type='tablet' bus='usb' alias name='input0'/ /input input type='mouse' bus='ps2'/ graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3' listen type='address'
[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13993653#comment-13993653 ] Simon Weller commented on CLOUDSTACK-6464: -- We are experiencing the exact same issue as Serg noted above using vlan isolation (traffic labels) in KVM with advanced networking on 6.3. What's also interesting is that releasing an ip appears to add an additional interface to the VR, as if it doesn't think a usable interface currently exists, so it hot-plugs a duplicate via libvirtd. It looks like the multiple interfaces are causing ARP problems. Please also look at https://issues.apache.org/jira/browse/CLOUDSTACK-5282 as that references a similar issue, but claims that it was related to https://issues.apache.org/jira/browse/CLOUDSTACK-5280 and resolved. It may be in our case that this is the same issue, but with traffic labels in use being the difference. Note that our platform was upgraded from 4.1.x. I'm more than happy to supply any required logs, and I have a lab platform to test on. - Si [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used -- Key: CLOUDSTACK-6464 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464 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: sadhu suresh Priority: Critical Fix For: 4.3.1 Steps: 1. create a KVM basic zone with 2 nics on host (pre 4.3 build) 2.use cloudbr0 for management and cloudbr1 for guest by specifying the traffic labels in the physical networks. 3.deploy few vms 4.upgrade to felton GA build as per the Upgrade instructions. actual result: Upgrade successful but all the vnets that were attached to cloudbr1 before upgrade are attached to cloudbr0. Due to this network connectivity is lost. Expected result: Even after upgrade ,all the vnets should be attached to the same bridge as before upgrade. ex: before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after upgrade and VM stop/start. the network rules are getting programmed in cloudbr0 .check below output ,984 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Executing: /usr/share/cloudstack-common/scripts/vm/network/security_group.py default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0: dumpxml output for i-5-616-VM after upgrade( after VM restart) * virsh # dumpxml 38 domain type='kvm' id='38' namei-5-616-VM/name uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid descriptionOther CentOS (64-bit)/description memory unit='KiB'2097152/memory currentMemory unit='KiB'2097152/currentMemory vcpu placement='static'1/vcpu cputune shares1000/shares /cputune os type arch='x86_64' machine='rhel6.2.0'hvm/type boot dev='cdrom'/ boot dev='hd'/ /os features acpi/ apic/ pae/ /features cpu /cpu clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashdestroy/on_crash devices emulator/usr/libexec/qemu-kvm/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/ target dev='hda' bus='ide'/ alias name='ide0-0-0'/ address type='drive' controller='0' bus='0' target='0' unit='0'/ /disk disk type='file' device='cdrom' driver name='qemu' type='raw' cache='none'/ target dev='hdc' bus='ide'/ readonly/ alias name='ide0-1-0'/ address type='drive' controller='0' bus='1' target='0' unit='0'/ /disk controller type='usb' index='0' alias name='usb0'/ address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller controller type='ide' index='0' alias name='ide0'/ address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller interface type='bridge' mac address='06:14:48:00:00:7f'/ source bridge='cloudbr0'/ target dev='vnet15'/ model type='e1000'/ bandwidth inbound average='25600' peak='25600'/ outbound average='25600' peak='25600'/ /bandwidth alias name='net0'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' source path='/dev/pts/12'/ target port='0'/ alias name='serial0'/ /serial console type='pty' tty='/dev/pts/12' source path='/dev/pts/12'/ target type='serial' port='0'/ alias name='serial0'/ /console input
[jira] [Commented] (CLOUDSTACK-6065) No HA for shutdown VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897849#comment-13897849 ] Simon Weller commented on CLOUDSTACK-6065: -- Animesh mentioned in the CLOUDSTACK-5731 notes that the new vmsync code isn't in the 4.3 release. The NPE looks virtually identical though. Can someone clarify this? This is a blocker in my opinion. No HA for shutdown VM - Key: CLOUDSTACK-6065 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: 4.3.0 Environment: CentOS 6.5 Mgmt HVs, KVM Reporter: Nux Assignee: Kelven Yang Priority: Critical Labels: ha, kvm I create a service offering with HA, launch a VM with it. I stop the VM from its console or SSH by issuing `poweroff` and the VM is not started back on. This is what I see in the management log: http://fpaste.org/75667/67633139/raw/ The UI keeps showing this VM as Running. However, if I force a reboot of its hypervisor ACS does do the right thing and starts the VM on another HV. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CLOUDSTACK-6065) No HA for shutdown VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897849#comment-13897849 ] Simon Weller edited comment on CLOUDSTACK-6065 at 2/11/14 1:44 PM: --- Animesh mentioned in the CLOUDSTACK-5713 notes that the new vmsync code isn't in the 4.3 release. The NPE looks virtually identical though. Can someone clarify this? This is a blocker in my opinion. was (Author: sweller): Animesh mentioned in the CLOUDSTACK-5731 notes that the new vmsync code isn't in the 4.3 release. The NPE looks virtually identical though. Can someone clarify this? This is a blocker in my opinion. No HA for shutdown VM - Key: CLOUDSTACK-6065 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: 4.3.0 Environment: CentOS 6.5 Mgmt HVs, KVM Reporter: Nux Assignee: Kelven Yang Priority: Critical Labels: ha, kvm I create a service offering with HA, launch a VM with it. I stop the VM from its console or SSH by issuing `poweroff` and the VM is not started back on. This is what I see in the management log: http://fpaste.org/75667/67633139/raw/ The UI keeps showing this VM as Running. However, if I force a reboot of its hypervisor ACS does do the right thing and starts the VM on another HV. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-3716) NPE triggered in DownloadListener
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Weller closed CLOUDSTACK-3716.
NPE triggered in DownloadListener
-
Key: CLOUDSTACK-3716
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3716
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.1.0, 4.2.0
Environment: RHEL 6.3 platform.
Reporter: Simon Weller
Assignee: Min Chen
Priority: Blocker
Fix For: 4.2.0
Attachments: DownloadMonitorImpl.4.1.patch
NPE thrown in DownLoadListener process:
2013-07-22 11:46:51,670 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873733: Received: { Ans: ,
MgmtId: 159090354809909, via: 30, Ver: v1, Flags: 110, { ListTemplateAnswer }
}
2013-07-22 11:46:51,670 DEBUG [agent.manager.AgentManagerImpl]
(AgentConnectTaskPool-2323:null) Details from executing class
com.cloud.agent.api.storage.ListTemplateCommand: success
2013-07-22 11:46:51,682 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found routing-3 already in the
template host table
2013-07-22 11:46:51,685 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found centos55-x86_64 already
in the template host table
2013-07-22 11:46:51,688 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync did not find
centos56-x86_64-xen ready on server 11, will request download to start/resume
shortly
2013-07-22 11:46:51,689 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync did not find centos53-x64
ready on server 11, will request download to start/resume shortly
2013-07-22 11:46:51,693 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
225-19-353032af-fd13-33d5-843b-1f7b1c321182 already in the template host table
2013-07-22 11:46:51,696 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
226-19-08172144-a8e2-3377-9d76-9a6231de5060 already in the template host table
2013-07-22 11:46:51,699 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
7686af3e-34f7-4ae3-ac69-0d089bcbd55e already in the template host table
2013-07-22 11:46:51,702 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
5e0726a4-73db-45d6-be2a-003c6ce8ff6e already in the template host table
2013-07-22 11:46:51,705 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
a647c887-59ef-4b81-aa54-1d15bba5272a already in the template host table
2013-07-22 11:46:51,708 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
272-9-699a6075-54fb-3505-aa5b-68191614286e already in the template host table
2013-07-22 11:46:51,711 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
273-19-ffa343f8-6933-384c-846a-cf150a970791 already in the template host table
2013-07-22 11:46:51,714 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
a2b9fcd7-2f19-48dd-affa-a60c574a75b1 already in the template host table
2013-07-22 11:46:51,716 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
5545c5fb-1b45-4dbc-8b1d-3cdac2c6394e already in the template host table
2013-07-22 11:46:51,729 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873734: Sending { Cmd , MgmtId:
159090354809909, via: 30, Ver: v1, Flags: 100111,
[{storage.ListVolumeCommand:{secUrl:nfs://172.27.68.201/secondarystorage,wait:0}}]
}
2013-07-22 11:46:51,832 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 30-1100873734: Processing: { Ans: ,
MgmtId: 159090354809909, via: 30, Ver: v1, Flags: 110,
[{storage.ListVolumeAnswer:{secUrl:nfs://172.27.68.201/secondarystorage,templateInfos:{215:{templateName:deviis01_1,installPath:volumes/215//82c2d426-3361-347c-93f4-c355d49fc7e2.qcow2,size:21487961088,physicalSize:8349614080,id:215,isPublic:true,isCorrupted:false}},result:true,details:success,wait:0}}]
}
2013-07-22 11:46:51,832 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-9:null) Seq 30-1100873734: No more commands found
2013-07-22 11:46:51,832 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873734: Received: { Ans: ,
MgmtId: 159090354809909, via: 30, Ver: v1, Flags: 110, { ListVolumeAnswer }
[jira] [Updated] (CLOUDSTACK-3716) NPE triggered in DownloadListener
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Weller updated CLOUDSTACK-3716:
-
Attachment: DownloadMonitorImpl.4.1.patch
Back ported patch for 4.1
NPE triggered in DownloadListener
-
Key: CLOUDSTACK-3716
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3716
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.1.0, 4.2.0
Environment: RHEL 6.3 platform.
Reporter: Simon Weller
Assignee: Min Chen
Priority: Blocker
Fix For: 4.2.0
Attachments: DownloadMonitorImpl.4.1.patch
NPE thrown in DownLoadListener process:
2013-07-22 11:46:51,670 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873733: Received: { Ans: ,
MgmtId: 159090354809909, via: 30, Ver: v1, Flags: 110, { ListTemplateAnswer }
}
2013-07-22 11:46:51,670 DEBUG [agent.manager.AgentManagerImpl]
(AgentConnectTaskPool-2323:null) Details from executing class
com.cloud.agent.api.storage.ListTemplateCommand: success
2013-07-22 11:46:51,682 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found routing-3 already in the
template host table
2013-07-22 11:46:51,685 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found centos55-x86_64 already
in the template host table
2013-07-22 11:46:51,688 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync did not find
centos56-x86_64-xen ready on server 11, will request download to start/resume
shortly
2013-07-22 11:46:51,689 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync did not find centos53-x64
ready on server 11, will request download to start/resume shortly
2013-07-22 11:46:51,693 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
225-19-353032af-fd13-33d5-843b-1f7b1c321182 already in the template host table
2013-07-22 11:46:51,696 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
226-19-08172144-a8e2-3377-9d76-9a6231de5060 already in the template host table
2013-07-22 11:46:51,699 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
7686af3e-34f7-4ae3-ac69-0d089bcbd55e already in the template host table
2013-07-22 11:46:51,702 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
5e0726a4-73db-45d6-be2a-003c6ce8ff6e already in the template host table
2013-07-22 11:46:51,705 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
a647c887-59ef-4b81-aa54-1d15bba5272a already in the template host table
2013-07-22 11:46:51,708 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
272-9-699a6075-54fb-3505-aa5b-68191614286e already in the template host table
2013-07-22 11:46:51,711 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
273-19-ffa343f8-6933-384c-846a-cf150a970791 already in the template host table
2013-07-22 11:46:51,714 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
a2b9fcd7-2f19-48dd-affa-a60c574a75b1 already in the template host table
2013-07-22 11:46:51,716 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
5545c5fb-1b45-4dbc-8b1d-3cdac2c6394e already in the template host table
2013-07-22 11:46:51,729 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873734: Sending { Cmd , MgmtId:
159090354809909, via: 30, Ver: v1, Flags: 100111,
[{storage.ListVolumeCommand:{secUrl:nfs://172.27.68.201/secondarystorage,wait:0}}]
}
2013-07-22 11:46:51,832 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 30-1100873734: Processing: { Ans: ,
MgmtId: 159090354809909, via: 30, Ver: v1, Flags: 110,
[{storage.ListVolumeAnswer:{secUrl:nfs://172.27.68.201/secondarystorage,templateInfos:{215:{templateName:deviis01_1,installPath:volumes/215//82c2d426-3361-347c-93f4-c355d49fc7e2.qcow2,size:21487961088,physicalSize:8349614080,id:215,isPublic:true,isCorrupted:false}},result:true,details:success,wait:0}}]
}
2013-07-22 11:46:51,832 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-9:null) Seq 30-1100873734: No more commands found
2013-07-22 11:46:51,832 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873734: Received:
[jira] [Commented] (CLOUDSTACK-3716) NPE triggered in DownloadListener
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13716398#comment-13716398
]
Simon Weller commented on CLOUDSTACK-3716:
--
Min,
I've added a patch for review for 4.1 to this issue.
NPE triggered in DownloadListener
-
Key: CLOUDSTACK-3716
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3716
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.1.0, 4.2.0
Environment: RHEL 6.3 platform.
Reporter: Simon Weller
Assignee: Min Chen
Priority: Blocker
Fix For: 4.2.0
Attachments: DownloadMonitorImpl.4.1.patch
NPE thrown in DownLoadListener process:
2013-07-22 11:46:51,670 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873733: Received: { Ans: ,
MgmtId: 159090354809909, via: 30, Ver: v1, Flags: 110, { ListTemplateAnswer }
}
2013-07-22 11:46:51,670 DEBUG [agent.manager.AgentManagerImpl]
(AgentConnectTaskPool-2323:null) Details from executing class
com.cloud.agent.api.storage.ListTemplateCommand: success
2013-07-22 11:46:51,682 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found routing-3 already in the
template host table
2013-07-22 11:46:51,685 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found centos55-x86_64 already
in the template host table
2013-07-22 11:46:51,688 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync did not find
centos56-x86_64-xen ready on server 11, will request download to start/resume
shortly
2013-07-22 11:46:51,689 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync did not find centos53-x64
ready on server 11, will request download to start/resume shortly
2013-07-22 11:46:51,693 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
225-19-353032af-fd13-33d5-843b-1f7b1c321182 already in the template host table
2013-07-22 11:46:51,696 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
226-19-08172144-a8e2-3377-9d76-9a6231de5060 already in the template host table
2013-07-22 11:46:51,699 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
7686af3e-34f7-4ae3-ac69-0d089bcbd55e already in the template host table
2013-07-22 11:46:51,702 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
5e0726a4-73db-45d6-be2a-003c6ce8ff6e already in the template host table
2013-07-22 11:46:51,705 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
a647c887-59ef-4b81-aa54-1d15bba5272a already in the template host table
2013-07-22 11:46:51,708 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
272-9-699a6075-54fb-3505-aa5b-68191614286e already in the template host table
2013-07-22 11:46:51,711 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
273-19-ffa343f8-6933-384c-846a-cf150a970791 already in the template host table
2013-07-22 11:46:51,714 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
a2b9fcd7-2f19-48dd-affa-a60c574a75b1 already in the template host table
2013-07-22 11:46:51,716 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
5545c5fb-1b45-4dbc-8b1d-3cdac2c6394e already in the template host table
2013-07-22 11:46:51,729 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873734: Sending { Cmd , MgmtId:
159090354809909, via: 30, Ver: v1, Flags: 100111,
[{storage.ListVolumeCommand:{secUrl:nfs://172.27.68.201/secondarystorage,wait:0}}]
}
2013-07-22 11:46:51,832 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 30-1100873734: Processing: { Ans: ,
MgmtId: 159090354809909, via: 30, Ver: v1, Flags: 110,
[{storage.ListVolumeAnswer:{secUrl:nfs://172.27.68.201/secondarystorage,templateInfos:{215:{templateName:deviis01_1,installPath:volumes/215//82c2d426-3361-347c-93f4-c355d49fc7e2.qcow2,size:21487961088,physicalSize:8349614080,id:215,isPublic:true,isCorrupted:false}},result:true,details:success,wait:0}}]
}
2013-07-22 11:46:51,832 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-9:null) Seq 30-1100873734: No more commands found
2013-07-22 11:46:51,832 DEBUG [agent.transport.Request]
[jira] [Commented] (CLOUDSTACK-3716) NPE triggered in DownloadListener
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13715854#comment-13715854
]
Simon Weller commented on CLOUDSTACK-3716:
--
I've been working on trying to reproduce this in our lab environment, and have
so far failed. I'm going to continue looking at it this evening.
As you can probably see in the debug, we're running KVM. This NPE also existed
in 4.0.x.
NPE triggered in DownloadListener
-
Key: CLOUDSTACK-3716
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3716
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.1.0, 4.2.0
Environment: RHEL 6.3 platform.
Reporter: Simon Weller
Assignee: Min Chen
Priority: Blocker
NPE thrown in DownLoadListener process:
2013-07-22 11:46:51,670 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873733: Received: { Ans: ,
MgmtId: 159090354809909, via: 30, Ver: v1, Flags: 110, { ListTemplateAnswer }
}
2013-07-22 11:46:51,670 DEBUG [agent.manager.AgentManagerImpl]
(AgentConnectTaskPool-2323:null) Details from executing class
com.cloud.agent.api.storage.ListTemplateCommand: success
2013-07-22 11:46:51,682 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found routing-3 already in the
template host table
2013-07-22 11:46:51,685 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found centos55-x86_64 already
in the template host table
2013-07-22 11:46:51,688 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync did not find
centos56-x86_64-xen ready on server 11, will request download to start/resume
shortly
2013-07-22 11:46:51,689 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync did not find centos53-x64
ready on server 11, will request download to start/resume shortly
2013-07-22 11:46:51,693 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
225-19-353032af-fd13-33d5-843b-1f7b1c321182 already in the template host table
2013-07-22 11:46:51,696 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
226-19-08172144-a8e2-3377-9d76-9a6231de5060 already in the template host table
2013-07-22 11:46:51,699 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
7686af3e-34f7-4ae3-ac69-0d089bcbd55e already in the template host table
2013-07-22 11:46:51,702 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
5e0726a4-73db-45d6-be2a-003c6ce8ff6e already in the template host table
2013-07-22 11:46:51,705 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
a647c887-59ef-4b81-aa54-1d15bba5272a already in the template host table
2013-07-22 11:46:51,708 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
272-9-699a6075-54fb-3505-aa5b-68191614286e already in the template host table
2013-07-22 11:46:51,711 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
273-19-ffa343f8-6933-384c-846a-cf150a970791 already in the template host table
2013-07-22 11:46:51,714 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
a2b9fcd7-2f19-48dd-affa-a60c574a75b1 already in the template host table
2013-07-22 11:46:51,716 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
5545c5fb-1b45-4dbc-8b1d-3cdac2c6394e already in the template host table
2013-07-22 11:46:51,729 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873734: Sending { Cmd , MgmtId:
159090354809909, via: 30, Ver: v1, Flags: 100111,
[{storage.ListVolumeCommand:{secUrl:nfs://172.27.68.201/secondarystorage,wait:0}}]
}
2013-07-22 11:46:51,832 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 30-1100873734: Processing: { Ans: ,
MgmtId: 159090354809909, via: 30, Ver: v1, Flags: 110,
[{storage.ListVolumeAnswer:{secUrl:nfs://172.27.68.201/secondarystorage,templateInfos:{215:{templateName:deviis01_1,installPath:volumes/215//82c2d426-3361-347c-93f4-c355d49fc7e2.qcow2,size:21487961088,physicalSize:8349614080,id:215,isPublic:true,isCorrupted:false}},result:true,details:success,wait:0}}]
}
2013-07-22 11:46:51,832 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-9:null) Seq 30-1100873734: No more
[jira] [Commented] (CLOUDSTACK-3716) NPE triggered in DownloadListener
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13715954#comment-13715954
]
Simon Weller commented on CLOUDSTACK-3716:
--
Min,
Thanks for the extremely fast work on this bug. Are you able to back port this
to the 4.1.1 branch as well?
Thanks.
NPE triggered in DownloadListener
-
Key: CLOUDSTACK-3716
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3716
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.1.0, 4.2.0
Environment: RHEL 6.3 platform.
Reporter: Simon Weller
Assignee: Min Chen
Priority: Blocker
Fix For: 4.2.0
NPE thrown in DownLoadListener process:
2013-07-22 11:46:51,670 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873733: Received: { Ans: ,
MgmtId: 159090354809909, via: 30, Ver: v1, Flags: 110, { ListTemplateAnswer }
}
2013-07-22 11:46:51,670 DEBUG [agent.manager.AgentManagerImpl]
(AgentConnectTaskPool-2323:null) Details from executing class
com.cloud.agent.api.storage.ListTemplateCommand: success
2013-07-22 11:46:51,682 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found routing-3 already in the
template host table
2013-07-22 11:46:51,685 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found centos55-x86_64 already
in the template host table
2013-07-22 11:46:51,688 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync did not find
centos56-x86_64-xen ready on server 11, will request download to start/resume
shortly
2013-07-22 11:46:51,689 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync did not find centos53-x64
ready on server 11, will request download to start/resume shortly
2013-07-22 11:46:51,693 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
225-19-353032af-fd13-33d5-843b-1f7b1c321182 already in the template host table
2013-07-22 11:46:51,696 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
226-19-08172144-a8e2-3377-9d76-9a6231de5060 already in the template host table
2013-07-22 11:46:51,699 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
7686af3e-34f7-4ae3-ac69-0d089bcbd55e already in the template host table
2013-07-22 11:46:51,702 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
5e0726a4-73db-45d6-be2a-003c6ce8ff6e already in the template host table
2013-07-22 11:46:51,705 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
a647c887-59ef-4b81-aa54-1d15bba5272a already in the template host table
2013-07-22 11:46:51,708 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
272-9-699a6075-54fb-3505-aa5b-68191614286e already in the template host table
2013-07-22 11:46:51,711 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
273-19-ffa343f8-6933-384c-846a-cf150a970791 already in the template host table
2013-07-22 11:46:51,714 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
a2b9fcd7-2f19-48dd-affa-a60c574a75b1 already in the template host table
2013-07-22 11:46:51,716 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
5545c5fb-1b45-4dbc-8b1d-3cdac2c6394e already in the template host table
2013-07-22 11:46:51,729 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873734: Sending { Cmd , MgmtId:
159090354809909, via: 30, Ver: v1, Flags: 100111,
[{storage.ListVolumeCommand:{secUrl:nfs://172.27.68.201/secondarystorage,wait:0}}]
}
2013-07-22 11:46:51,832 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 30-1100873734: Processing: { Ans: ,
MgmtId: 159090354809909, via: 30, Ver: v1, Flags: 110,
[{storage.ListVolumeAnswer:{secUrl:nfs://172.27.68.201/secondarystorage,templateInfos:{215:{templateName:deviis01_1,installPath:volumes/215//82c2d426-3361-347c-93f4-c355d49fc7e2.qcow2,size:21487961088,physicalSize:8349614080,id:215,isPublic:true,isCorrupted:false}},result:true,details:success,wait:0}}]
}
2013-07-22 11:46:51,832 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-9:null) Seq 30-1100873734: No more commands found
2013-07-22 11:46:51,832 DEBUG [agent.transport.Request]
[jira] [Created] (CLOUDSTACK-3716) NPE triggered in DownloadListener
Simon Weller created CLOUDSTACK-3716:
Summary: NPE triggered in DownloadListener
Key: CLOUDSTACK-3716
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3716
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.1.0
Environment: RHEL 6.3 platform.
Reporter: Simon Weller
NPE thrown in DownLoadListener process:
2013-07-22 11:46:51,670 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873733: Received: { Ans: , MgmtId:
159090354809909, via: 30, Ver: v1, Flags: 110, { ListTemplateAnswer } }
2013-07-22 11:46:51,670 DEBUG [agent.manager.AgentManagerImpl]
(AgentConnectTaskPool-2323:null) Details from executing class
com.cloud.agent.api.storage.ListTemplateCommand: success
2013-07-22 11:46:51,682 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found routing-3 already in the
template host table
2013-07-22 11:46:51,685 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found centos55-x86_64 already in
the template host table
2013-07-22 11:46:51,688 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync did not find centos56-x86_64-xen
ready on server 11, will request download to start/resume shortly
2013-07-22 11:46:51,689 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync did not find centos53-x64 ready
on server 11, will request download to start/resume shortly
2013-07-22 11:46:51,693 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
225-19-353032af-fd13-33d5-843b-1f7b1c321182 already in the template host table
2013-07-22 11:46:51,696 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
226-19-08172144-a8e2-3377-9d76-9a6231de5060 already in the template host table
2013-07-22 11:46:51,699 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
7686af3e-34f7-4ae3-ac69-0d089bcbd55e already in the template host table
2013-07-22 11:46:51,702 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
5e0726a4-73db-45d6-be2a-003c6ce8ff6e already in the template host table
2013-07-22 11:46:51,705 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
a647c887-59ef-4b81-aa54-1d15bba5272a already in the template host table
2013-07-22 11:46:51,708 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
272-9-699a6075-54fb-3505-aa5b-68191614286e already in the template host table
2013-07-22 11:46:51,711 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
273-19-ffa343f8-6933-384c-846a-cf150a970791 already in the template host table
2013-07-22 11:46:51,714 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
a2b9fcd7-2f19-48dd-affa-a60c574a75b1 already in the template host table
2013-07-22 11:46:51,716 INFO [storage.download.DownloadMonitorImpl]
(AgentConnectTaskPool-2323:null) Template Sync found
5545c5fb-1b45-4dbc-8b1d-3cdac2c6394e already in the template host table
2013-07-22 11:46:51,729 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873734: Sending { Cmd , MgmtId:
159090354809909, via: 30, Ver: v1, Flags: 100111,
[{storage.ListVolumeCommand:{secUrl:nfs://172.27.68.201/secondarystorage,wait:0}}]
}
2013-07-22 11:46:51,832 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 30-1100873734: Processing: { Ans: , MgmtId:
159090354809909, via: 30, Ver: v1, Flags: 110,
[{storage.ListVolumeAnswer:{secUrl:nfs://172.27.68.201/secondarystorage,templateInfos:{215:{templateName:deviis01_1,installPath:volumes/215//82c2d426-3361-347c-93f4-c355d49fc7e2.qcow2,size:21487961088,physicalSize:8349614080,id:215,isPublic:true,isCorrupted:false}},result:true,details:success,wait:0}}]
}
2013-07-22 11:46:51,832 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-9:null) Seq 30-1100873734: No more commands found
2013-07-22 11:46:51,832 DEBUG [agent.transport.Request]
(AgentConnectTaskPool-2323:null) Seq 30-1100873734: Received: { Ans: , MgmtId:
159090354809909, via: 30, Ver: v1, Flags: 110, { ListVolumeAnswer } }
2013-07-22 11:46:51,832 DEBUG [agent.manager.AgentManagerImpl]
(AgentConnectTaskPool-2323:null) Details from executing class
com.cloud.agent.api.storage.ListVolumeCommand: success
2013-07-22 11:46:51,836 ERROR [agent.manager.AgentManagerImpl]
(AgentConnectTaskPool-2323:null) Monitor DownloadListener says there is an
error in the connect process for 30 due
