検証タスクには複数の仮想マシンが含まれていましたが、単一の仮想マシンの処理に失敗しました。 さらに、検証タスクはバックアップタスクに基づいており、エラーなしで動作し、このVM自体のバックアップを実行しました。
猫の下で私たちの調査について読んでください。
焦点が合っている
実際、このようなエラーはいくつかの理由で発生する可能性があります。たとえば、無料のFree ESXiハイパーバイザーの機能には多くの制限があります（したがって、サポートしていません）。 しかし、そうではありませんでした-ハイパーバイザーは明らかにフリーではなく、他のすべてのマシンはSureBackupタスクによって完全に処理され、問題のマシンは通常バックアップタスクでバックアップされました。
それでも、このマシンはSureBackupタスクの障害になったため、より綿密に検討することは理にかなっています。
最初に目を引いたのは、このマシン（VM01と呼びます）のサイズが他のマシンよりも大幅に大きいことです。ドライブの1つが2TBを超えていました。 この事実に留意して、Veeam Backup＆Replicationジョブのログの分析に進みました。 起こったことは次のとおりです。
正直なところ、その時点ではロギングは役に立たなかったが、少なくともVMware vSphere APIがエラーメッセージの生成元であることが明らかになった。
VMwareログの分析
ここで、さらに苦労せずに、元のエラーメッセージの行を入力することにより、検索クエリを実行しました。
見つかったエントリにディスクの名前が表示されました。 2 TBを超える同じVMDKディスクであることが判明し、すでに注目されています。 また、ディスクタイプ-seSparse 、つまりスペース効率の高いスパースも表示されます。
ここで、デルタディスク用に2TBを超えるディスクのスナップショットを作成する場合、VMware vSphereはVMFS（vmfssparse）ではなくseSparse形式のみを使用することを思い出しました。 これは、 VMware KB 2058287ナレッジベースの記事に記載されています。
私たちの問題は、おそらくseSparseタイプのディスクを使用してデルタ（redoログ）を保存することに何らかの関係があります。 しかし、根本的な原因は何でしたか？ そして、ここでもう1つの詳細に注目しました。SureBackupタスクに関係するソースVMと仮想ラボはvSANデータストアにありました。
SureBackup検証テクノロジは、仮想マシンを「持ち上げる」ためにVeeam vPower NFSデータストアを使用し、検証タスクのマシンのREDOログはメインデータストア（この場合はvSAN）にリダイレクトされることはよく知られています。
つまり、NFSデータストアにメインディスクがあり、vSANにデルタ（redoログ）があるストレージシステムが形成されました。 しかし、問題のVM01を除くすべてのマシンについて、このようなシステムは正常に機能したため、 seSparseとvSANの互換性の問題を調査する必要があるという結論に達しました。
調査の結果、VMware vSANのドキュメントにアクセスできました 。 「Virtual SANはSEスパースディスクをサポートしていません。」-仮想SANはSEスパースドライブをサポートしていません 。
ただし、このドキュメントはvSphere v5.5に関連しており、この場合はvSphere 6.0でした。 VMwareの同僚に連絡し、この制限がバージョン6.0とバージョン6.5の両方に適用されることを確認しました。
最後に、パズルのすべてのピースがまとめられました。結果は次のとおりです。メインディスクがNFS / VMFSにあり、deloファイル（redoログ）seSparseがvSANにある場合、ストレージシステムのこのような構成は不可能です。タイプVMFS_typeを継承します。
気配りのある読者は、合理的な質問をします。なぜ大きなディスク（2TB以上）でバックアップが正常に機能したのか？ 結局のところ、seSparseはvSANでサポートされていませんか？ 答えは簡単です。メインディスクがvSANにあるVMスナップショットを作成する場合、VMwareはVSANSPARSEスナップショットタイプを使用してデルタを保存します。
注： VSANSPARSEの詳細については、VMwareの記事（ ダウンロード可能なPDF ）を参照してください。
管理者メモ：
- タイプVSANSPARSEのスナップショットは、vSANディスク上に作成されます。
- VMFS_sparseやseSparseなどのスナップショットは通常のVMFSディスク上に作成され、ディスクのサイズとVMFSのバージョンは重要です（たとえば、VMFS6のスナップショットはサイズに関係なく常にseSparseタイプになります）。
- 別のデータストアへのリダイレクトの場合、スナップショットディスクタイプは親ディスクから継承されます。
ソリューションを提供します
ユーザーに、vSANを使用せずに「サンドボックス」（仮想ラボ）をデータストアに転送することを推奨しました。 この場合、リダイレクト時に、スナップショットのタイプは変更されません。
大きなディスク（> 2TB）を備えたマシンに対してインスタントリカバリインスタントリカバリを実行しようとすると、vSAN上のVMで作業するときに同様の問題が発生する可能性があります。 スナップショットのリダイレクトも実行されるため、上記のソリューションがここで適用されることに注意してください。
この問題をさらに調査すると、場合によっては、ホットアド（仮想アプライアンス）モードで作業しているときに問題が現れることもありました。 いずれにしても、特定の操作にどのデータストアとどのタイプのスナップショットが関係するかを慎重に分析する必要があります。 まだ質問がある場合は、いつでもサポートいたします。
便利なだけでなく、こちらも快適です
冬の休暇を見越して、Veeamは再びプレゼントを贈ります。新しい年に世界のさまざまな地域で開催されるVeeamON 2018カンファレンスに6枚のチケットを配ります。 チケットには、両側へのチケット、会議会場近くの快適な部門の宿泊施設、そしてもちろん、すべての会議イベント（場所を予約する必要があるものを含む）への参加が含まれます。
抽選に参加するために必要なことは、 ここで登録するだけです。
たとえば、オーストラリアやカナダで私たちを読んでいる場合、必要な地域会議のページを開くことができます 。 ここへのリンクです 。
登録は2017年12月31日に終了しますので、お急ぎください。
幸運な6人の名前は、2018年の新年に発表されます。 FBとTwitterの ページでニュースをフォローできます。