xfs
[Top] [All Lists]

Re: Help with XFS in VMs on VMFS

To: Jan Perci <jperci@xxxxxxxxx>
Subject: Re: Help with XFS in VMs on VMFS
From: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Thu, 28 Mar 2013 14:50:33 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <CAJoqCq9WhFi8yZnTjh_dJmOte4TWpKg3qsQLpVsZ45M8XoWiaA@xxxxxxxxxxxxxx>
References: <CAJoqCq9WhFi8yZnTjh_dJmOte4TWpKg3qsQLpVsZ45M8XoWiaA@xxxxxxxxxxxxxx>
Reply-to: stan@xxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
On 3/28/2013 8:21 AM, Jan Perci wrote:

> Normally I would use raw mappings and XFS directly on the volumes.  But
> there is a hard requirement to support VM snapshots, so all the data must
> reside within VMDK files on the VMFS datastores.

Since when?  ESX has had LUN snapshot capability back to 3.0, 6 years or
so.  It may have required the VCB add on back then.

Is this simply a limitation of the freebie version?  If so, pony up and
pay for what you need, or switch to a FOSS solution which has no such
limitations.

VMFS volumes are not intended for high performance IO.  Unless things
have changed recently, VMware has always recommended housing only OS
images and the like in VMDKs, not user data.  They've always recommended
using RDMs for everything else.  IIRC VMDKs have a huge block (sector)
size, something like 1MB.  That's going to make XFS alignment difficult,
if not impossible.

I cannot stress emphatically enough that you should not stitch 2TB VMDKs
together and use them in the manner you described.  This is a recipe for
disaster.  Find another solution.

-- 
Stan

<Prev in Thread] Current Thread [Next in Thread>