Azure Cloud Recovery Problem

Last post 03-15-2019, 8:15 PM by Wwong. 3 replies.
Sort Posts: Previous Next
  • Azure Cloud Recovery Problem
    Posted: 03-05-2019, 11:17 PM

    Tried to recover a VM to Azure today.  Everything seemed to work OK, but at last minute (94%), it failed with the following error. (v11 SP12).

    Unable to write data to the Virtual Disk [<C:\Program Files\CommVault\Simpana\iDataAgent\JobResults\AzureMountPoint\0ddkk472-5527-4cx7-ba7d-2df2815xdfb16\Resource Manager\something\vhds\server1-20190305-211950.vhd>].  Please ensure that the proxy is able to communicate with the virtual machine host and that there is sufficient disk space available.  Details: [Invalid argument (ErrNo.22) (CV.0x1)] 

    I can drill down to the files in Job Results folder and see the VHD files, and they look OK intact.

    Digging into the logs I see a message in the vscloudfs.log.  Now I've looked for the error and it seems like there might a timeout that needs to be set in the Azure API call on the client side (i.e. Commvault)?  Anyone have any experience with this?

    https://docs.microsoft.com/en-us/dotnet/api/microsoft.windowsazure.storage.blob.blobrequestoptions.maximumexecutiontime?redirectedfrom=MSDN&view=azure-dotnet#Microsoft_WindowsAzure_Storage_Blob_BlobRequestOptions_MaximumExecutionTime

    8636  1b88  03/05 22:08:04 ### Exception- Microsoft.WindowsAzure.Storage.StorageException: The client could not finish the operation within specified timeout. ---> System.TimeoutException: The client could not finish the operation within specified timeout.

       --- End of inner exception stack trace ---

       at Microsoft.WindowsAzure.Storage.Core.Executor.Executor.ExecuteSync[T](RESTCommand`1 cmd, IRetryPolicy policy, OperationContext operationContext)

       at Microsoft.WindowsAzure.Storage.Blob.CloudBlob.DownloadRangeToStream(Stream target, Nullable`1 offset, Nullable`1 length, AccessCondition accessCondition, BlobRequestOptions options, OperationContext operationContext)

       at Microsoft.WindowsAzure.Storage.Blob.CloudBlob.DownloadRangeToByteArray(Byte[] target, Int32 index, Nullable`1 blobOffset, Nullable`1 length, AccessCondition accessCondition, BlobRequestOptions options, OperationContext operationContext)

       at AzureSDKWrapper.AzureStorage`2.DownloadBlobPageToBuffer(String storageAccountName, String containerName, String blobName, Int64 page, Int64 bufferSize, Byte[]& buffer)

    Request Information

    RequestID:8f65ef50-401e-013c-4bc8-d3166a000000

    RequestDate:Wed, 06 Mar 2019 02:58:04 GMT

    StatusMessage:Partial Content

    8636  1b88  03/05 22:08:04 ### CVSAzureFSFile::DownloadPageToBuffer() - Failed to download page [213], Error [The client could not finish the operation within specified timeout.]

  • Re: Azure Cloud Recovery Problem
    Posted: 03-15-2019, 7:53 PM

    Hi bkpadm3000 

    As the API calls are directly included in the CommVault Binary, I would recommend opening a support Ticket to confirm the above behavior and see if there is an available hot fix or a known issue when doing VM restore from Azure.

    Regards

    Winston

  • Re: Azure Cloud Recovery Problem
    Posted: 03-15-2019, 8:03 PM

    Got it figured out I think.  The issue was that there was a VM proxy media agent that was just being used for DR that is always offline in Commvault, since it lives in Azure and the customer doesn't want to pay for it to be on until needed (which makes a lot of sense).   It wasn't set to maintenance mode, just offline.  For other testing, it was also turned on in Azure.

    For some unknown reason even though we weren't using it for recovery, Commvault was still polling it in some fashion.  Setting it to maintenance mode and/or powering it off seemed to fix this issue.  Problem is the errors above show nothing that points to that.  

    Restores now work just fine.

  • Re: Azure Cloud Recovery Problem
    Posted: 03-15-2019, 8:15 PM

    Hi bkpadm3000

    Thanks for the update and sharing the solution. 

    Great to know everything is sorted, and detail troubleshooting will definitely help others when they face similar issue.

    Regards

    Winston

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Close
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy