[jira] [Updated] (CLOUDSTACK-5096) [VMware] Corrupt template is left behind after the copy of a template from secondary to primary fails.

["Likitha Shetty (JIRA)" <ji...@apache.org>]

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

Likitha Shetty updated CLOUDSTACK-5096:
---------------------------------------

    Description: 
When template copy from secondary to primary doesn't go through, VM does not bootup.
1. Monitor the state of HttpNfcLease (object returned by the import task) and check if it goes into ERROR state. This will handle lease initialization erros
2. Monitor the progress of VMDKs upload and catch exceptions if any (Already handled)

In case of failure perform cleanup by,
- Throw an error with the message containing the task fault
- Abort the HttpNfcLease which will in turn handle the removal of all objects including VMDKs that were created during import   
- Retry in case of upload failure (Already handled)
- Remove the CloudStack DB entry for the template in the primary store. Since the entry is removed during the next VM launch from the same template fresh COPY command will be issued (Already handled)


  was:
When template copy from secondary to primary doesn't go through, VM does not bootup. Also, the subsequent VM creations from the same template fails because it continues to use the corrupt template that was left behind.
1. Monitor the state of HttpNfcLease (object returned by the import task) and check if it goes into ERROR state. This will handle vCenter operation timeout issue
2. Monitor the progress of VMDKs upload and catch exceptions if any (Already handled)

In case of failure perform cleanup by,
- Throw an error with the message containing the task fault
- Abort the HttpNfcLease which will in turn handle the removal of all objects including VMDKs that were created during import   
- Retry in case of upload failure (Already handled)
- Remove the CloudStack DB entry for the template in the primary store. Since the entry is removed during the next VM launch from the same template fresh COPY command will be issued (Already handled)
- Today, if a corrupt template is left behind then during the next VM deployment even though the COPY command has been issued, vCenter will reuse the template that has been left behind.
Hence, if management server request for a copy based on no DB entry for the template in that store then delete the old template if present (vCenter identifies the template present in the store based on the unique uuid name) and import the template from secondary to primary.



> [VMware] Corrupt template is left behind after the copy of a template from secondary to primary fails.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-5096
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5096
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: VMware
>    Affects Versions: 4.2.0
>            Reporter: Likitha Shetty
>            Assignee: Likitha Shetty
>             Fix For: 4.2.1
>
>
> When template copy from secondary to primary doesn't go through, VM does not bootup.
> 1. Monitor the state of HttpNfcLease (object returned by the import task) and check if it goes into ERROR state. This will handle lease initialization erros
> 2. Monitor the progress of VMDKs upload and catch exceptions if any (Already handled)
> In case of failure perform cleanup by,
> - Throw an error with the message containing the task fault
> - Abort the HttpNfcLease which will in turn handle the removal of all objects including VMDKs that were created during import   
> - Retry in case of upload failure (Already handled)
> - Remove the CloudStack DB entry for the template in the primary store. Since the entry is removed during the next VM launch from the same template fresh COPY command will be issued (Already handled)



--
This message was sent by Atlassian JIRA
(v6.1#6144)