You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/11/27 14:14:00 UTC

[jira] [Commented] (CLOUDSTACK-9586) When using local storage with Xenserver prepareTemplate does not work with multiple primary store

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16266853#comment-16266853 ] 

ASF GitHub Bot commented on CLOUDSTACK-9586:
--------------------------------------------

borisstoyanov opened a new pull request #2342: CLOUDSTACK-9586: Adding local storage test
URL: https://github.com/apache/cloudstack/pull/2342
 
 
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> When using local storage with Xenserver prepareTemplate does not work with multiple primary store
> -------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-9586
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9586
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Secondary Storage, XenServer
>    Affects Versions: 4.5.2
>         Environment: XenServer 6.5 SP1
> Local Storage
>            Reporter: Abhinandan Prateek
>            Assignee: Abhinandan Prateek
>            Priority: Critical
>             Fix For: 4.9.1.0, 4.8.2.0, 4.10.1.0
>
>
> 2016-11-09 15:05:15,876 DEBUG [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-29:ctx-8d890b55) Failed to destroy pbd
> SR_BACKEND_FAILURE_40The SR scan failed  [opterr=['INTERNAL_ERROR', 'Db_exn.Uniqueness_constraint_violation("VDI", "uuid", "703f59ca-6e5e-38d3-bbef-707b5b14c704")']]
> 	at com.xensource.xenapi.Types.checkResponse(Types.java:2021)
> 	at com.xensource.xenapi.Connection.dispatch(Connection.java:395)
> 	at com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:462)
> 	at com.xensource.xenapi.SR.scan(SR.java:1257)
> 	at com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSR(Xenserver625StorageProcessor.java:113)
> 	at com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.createFileSr(Xenserver625StorageProcessor.java:139)
> 	at com.cloud.hypervisor.xenserver.resource.Xenserver625StorageProcessor.copyTemplateToPrimaryStorage(Xenserver625StorageProcessor.java:173)
> Root Cause: CloudPlatform creates a SR on each host, which points to the template location on the secondary storage (secondary_Storage/template/tmpl/<account_id>/<template_id>). This causes the database unique constraint violation when each XenServer tries to scan the SR created on each host. The host that scans the SR last, throws the exception because VDI was recognized already from the SR scan of the first host.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)