This issue is happening in premium storage only (SSD-backed storage). This is when attempting to revert a VHD that became corrupted in the last maintenance to a previous snapshot.
This is the request being sent (method StartCopyFromBlob):
PUT https://contoso.blob.core.windows.net/vhds/OS.vhd HTTP/1.1
User-Agent: WA-Storage/4.3.0 (.NET CLR 4.0.30319.34209; Win32NT 6.2.9200.0)
x-ms-version: 2014-02-14
x-ms-copy-source: https://contoso.blob.core.windows.net/vhds/OS.vhd?snapshot=2015-06-04T09%3A00%3A02.0048291Z
x-ms-client-request-id: d09e9c18-07c4-4295-a09e-e6bbe23ea543
x-ms-date: Wed, 10 Jun 2015 21:43:25 GMT
Authorization: XXXXXXXXXXXXXXXXXXXXXXXX
Host: contoso.blob.core.windows.net
Content-Length: 0
And this is the response:
HTTP/1.1 409 This operation is not permitted because the blob has snapshots.
Content-Length: 246
Content-Type: application/xml
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 88411d2c-001c-020d-00c6-a3ce5e000000
x-ms-version: 2014-02-14
Date: Wed, 10 Jun 2015 21:43:23 GMT
<?xml version="1.0" encoding="utf-8"?>
<Error><Code>SnapshotsPresent</Code><Message>This operation is not permitted because the blob has snapshots.
RequestId:88411d2c-001c-020d-00c6-a3ce5e000000
Time:2015-06-10T21:43:24.3527942Z</Message></Error>
At first, I thought it was linked with the blob having a Lease associated to it (since it had been associated to a Disk that I had deleted) but none appear to be associated.
Properties request:
HEAD https://contoso.blob.core.windows.net/vhds/OS.vhd HTTP/1.1
User-Agent: WA-Storage/4.3.0 (.NET CLR 4.0.30319.34209; Win32NT 6.2.9200.0)
x-ms-version: 2014-02-14
x-ms-client-request-id: df75e42b-4733-4ec4-86fd-b073d7353d98
x-ms-date: Wed, 10 Jun 2015 21:47:53 GMT
Authorization: XXXXXXXXXXXXXXXXXXXXXXXX
Host: contoso.blob.core.windows.net
Properties response:
HTTP/1.1 200 OK
Content-Length: 136367309312
Content-Type: binary/octet-stream
Last-Modified: Mon, 08 Jun 2015 19:30:01 GMT
Accept-Ranges: bytes
ETag: "0x8D27038A5E2A5B0"
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-copy-id: 79998710-3eeb-4323-be69-349ec9bf5b68
x-ms-copy-source: XXXXXXXXXXXXXXXXXXXXXXXX
x-ms-copy-progress: 136367309312/136367309312
x-ms-copy-status: success
x-ms-copy-completion-time: Thu, 05 Mar 2015 17:05:45 GMT
x-ms-meta-PIRTag: 1
x-ms-lease-state: available
x-ms-lease-status: unlocked
x-ms-blob-type: PageBlob
x-ms-blob-sequence-number: 101028
x-ms-request-id: 782ffea7-001c-02c3-00c7-a3a811000000
x-ms-version: 2014-02-14
Date: Wed, 10 Jun 2015 21:47:51 GMT
I worked around the issue by restoring the snapshot to another blob name (and restoring my VM to a disk associated to this new location) but I'm still curious if anyone knows a solution to this problem.
This has been addressed. You can now restore a snapshot to the base blob. Change is entirely on Azure service side. You can use the same Azure Storage SDK for executing this (Storage REST API version 2014-02-14 or later). No change needed on the client side.