web-dev-qa-db-ja.com

vmwarevmdkディスクの問題

VMware ESXi 4サーバーと2つのストレージサーバー（nfs経由でマウント）があります。

ストレージサーバー（Fedora 14）の間には、drbdクラスター（デュアルプライマリ）とocfs2ファイルシステムがあります。また、すべてのサーバーにはext4ファイルシステムを備えたローカルパーティションがあり、どちらもesxiサーバーのnfsを介してマウントされます。

仮想マシン（当然電源がオフになっている）をext4パーティションからocfs2パーティションにコピーしようとすると、vmdkの合計ファイルサイズは異なりますが、md5sumは同じです。

Ext4パーティション：

# ls -la
total 28492228
-rw-------  1 root root 42949672960 Jan 14 14:46 disk-flat.vmdk

# md5sum disk-flat.vmdk
0eaebe3138beb32f54ea5de6dfe5a987

Ocfs2パーティション：

# ls -la
total 13974660
-rw------- 1 root root 42949672960 Jan 14 16:16 disk-flat.vmdk

# md5sum disk-flat.vmdk
0eaebe3138beb32f54ea5de6dfe5a987

Ocfs2パーティションから仮想マシンの電源をオンにすると、機能しません。仮想マシンにウィンドウがあり、ウィンドウのロゴの後にフリーズします。 ext4パーティションから、仮想マシンが機能します。

Linuxでテストしました（ext4パーティションで作成およびインストールしてからocfs2にコピーしました）。同じ問題が発生します。

Ocfs2パーティションから直接仮想マシンを作成する場合、問題はありません。

VSphereクライアント経由でコピーしようとしましたが、同じ問題が発生します。

助言がありますか？

vmware-esxinfsdrbdocfs2
3
dmtr

上で述べたように：vmdkファイルはまばらです。すなわち。それらには「穴」があります。 「du」を使用してファイルサイズを比較してみてください。

2
ibre5041

ファイルをどのようにコピーしていますか？

サポートされている唯一の方法は、vmkfstoolsを使用することです。 cpやmvを含む他の方法では、ディスクが破損し、使用できなくなる可能性があります。

もちろん、私はこれを発見しました 難しい方法 。

1
Massimo

これを診断するための最初の良いテストは、同じOCFSパーティションに新しいVMをプロビジョニングして、VMwareがネイティブに作成されたときにどのように機能するかを確認することです。これは包括的な問題である可能性があります。この特定のVMデータに限定されたものではなく、OCFSまたはNFSアクセス許可。また、VMkernelがNFSoverに接続しているvSwitchと実際のdrbdクラスターの間でMTUの整合性を確保します。

また、貼り付けごとに、ファイルサイズは同じです。上記の「合計」の数値は、使用すべきものではありません。これは、ファイルサイズではなくブロックの合計です。

-ジェームズ

0
jizaymes