[
https://issues.apache.org/jira/browse/CLOUDSTACK-9586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15721822#comment-15721822
]
ASF subversion and git services commented on CLOUDSTACK-9586:
-------------------------------------------------------------
Commit 20aea27dc0dd2a212acd830d47945ea5ea579f0c in cloudstack's branch
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=20aea27 ]
Merge pull request #1765 from shapeblue/CLOUDSTACK-9586
Cloudstack 9586: When using local storage with Xenserver prepareTemplate does
not work with multiple primary storeThe race condition will happen whenever
there are multiple primary storages and the CS tries to mount the secondary
store to xenserver host simultaneously.
Due to synchronised block one mount will be successful and other thread will
get the already mounted SR. Without the fix the two thread will try to mount it
parallely and one will fail on Xenserver.
* pr/1765:
Cloudstack 9586: When using local storage with Xenserver prepareTemplate does
not work with multiple primary store The race condition will happen whenever
there are multiple primary storages and the CS tries to mount the secondary
store to xenserver host simultaneously. Due to synchronised block one mount
will be successful and other thread will get the already mounted SR. Without
the fix the two thread will try to mount it parallely and one will fail on
Xenserver.
Signed-off-by: Rohit Yadav <rohit.ya...@shapeblue.com>
> 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.10.0.0, 4.9.1.0, 4.8.2.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.3.4#6332)
