[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Abhinandan Prateek updated CLOUDSTACK-9586:
-------------------------------------------
             Assignee: Abhinandan Prateek
    Affects Version/s: 4.5.2
        Fix Version/s: 4.5.2.2
          Description: 
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.

  was:

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.


> When using shared storage with Xenserver prepareTemplate does not work
> ----------------------------------------------------------------------
>
>                 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.) 
>    Affects Versions: 4.5.2
>            Reporter: Abhinandan Prateek
>            Assignee: Abhinandan Prateek
>             Fix For: 4.5.2.2
>
>
> 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)

Reply via email to