All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Gross <Ralf-Lists@ralfgross.de>
To: xfs@oss.sgi.com
Subject: Re: Help with XFS in VMs on VMFS
Date: Thu, 28 Mar 2013 22:45:50 +0100	[thread overview]
Message-ID: <20130328214550.GA3771@pirx.askja.de> (raw)
In-Reply-To: <51549F09.1090109@hardwarefreak.com>

Stan Hoeppner schrieb:
> 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.

Snapshots are possible with RDM in virtual compatibily mode, not
physical mode (> 2 TB).

http://pubs.vmware.com/vsphere-51/topic/com.vmware.vsphere.storage.doc/GUID-0114693D-94BF-4D0E-9BA4-416D4A51A5A1.html
 
> 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.

No, thats the limit for all versions.

 
> 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 can't remember that I've every found this recommendation on a vmware
page.

http://blogs.vmware.com/vsphere/2013/01/vsphere-5-1-vmdk-versus-rdm.html

 
> 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.

I'm seeing more and more requests for VMs with large disks lately in my
env. Right now the max. is ~2 TB. I'm also thinking about where to go,
 > 2 TB ist only possible with pRDMs which can't be snapshotted. You
have to use the snapshot features of your storage array.

Ralf

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-03-28 21:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-28 13:21 Help with XFS in VMs on VMFS Jan Perci
2013-03-28 14:59 ` Stefan Ring
2013-03-28 19:50 ` Stan Hoeppner
2013-03-28 21:45   ` Ralf Gross [this message]
2013-03-28 22:13     ` Emmanuel Florac
2013-03-29 14:23       ` Ralf Gross
2013-03-29  0:56     ` Stan Hoeppner
2013-03-29  3:30       ` Jan Perci
2013-03-29 20:27         ` Ben Myers
2013-03-30 19:12           ` Stan Hoeppner
2013-03-31  2:04             ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130328214550.GA3771@pirx.askja.de \
    --to=ralf-lists@ralfgross.de \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.