+ Post New Thread
Results 1 to 10 of 10
Thin Client and Virtual Machines Thread, VMWare block size for file server in Technical; I'm moving our file server onto virtual soon as part of a shake-up of the folder structure generally but it ...
  1. #1
    gshaw's Avatar
    Join Date
    Sep 2007
    Location
    Essex
    Posts
    2,675
    Thank Post
    168
    Thanked 221 Times in 204 Posts
    Rep Power
    67

    VMWare block size for file server

    I'm moving our file server onto virtual soon as part of a shake-up of the folder structure generally but it poses some interesting questions on how best to store the VMDK files...

    We're not on vSphere 5 yet, waiting for newer version of Veeam first (and potentially an update pack for VMWare) so that means I've got the block size of the VMDK file to think about. If I do 1MB then it's max 256GB for the VMDK file, which is a bit tight as one of the shared folders I'm moving is ~200GB at the moment (splitting up the 600GB physical server into 2-3 VMs to spread the load).

    Then question is whether it's worth making a store with 4MB (or even 8MB) block size when vSphere 5 is so close that can use 1MB for any datastore size you want, although that relies on waiting for the releases above and a bit of work doing the vSphere 5 update.

    Any thoughts from the VMWare users on here?

  2. #2


    Join Date
    Jan 2006
    Posts
    8,202
    Thank Post
    442
    Thanked 1,032 Times in 812 Posts
    Rep Power
    339
    smaller files use more space witha larger blocksize, so diskspace the only real disadvantage. I'd go for 2M if thats what you need.

  3. #3

    Join Date
    Sep 2008
    Location
    Durham
    Posts
    129
    Thank Post
    1
    Thanked 30 Times in 28 Posts
    Rep Power
    25
    As the block size is set when you create the datastore, I would wait until you've implemented vSphere 5. You're only going to be duplicating the workload by moving before then.

  4. #4

    Join Date
    Nov 2010
    Location
    Worcestershire
    Posts
    68
    Thank Post
    11
    Thanked 19 Times in 17 Posts
    Rep Power
    15
    Go for whatever you need in terms of single file size 2MB block files will allow you to create 512GB files, however be careful when creating your virtual disks - DO NOT use the maximum size available as you will not be able to snapshot (which Veeam will require to perform backups through the vStorage API)

    Upgrading your VMFS datastores to version 5 (from version 3) when you update is VERY simple though (regardless of the current block size):

    Upgrade_to_VMFS_5.swf

    Note that the block size remains following the upgrade, to revert to a 1MB block size requires deleting and recreating the datastores
    Last edited by andrew-virtusolve; 7th November 2011 at 09:14 AM.

  5. Thanks to andrew-virtusolve from:

    gshaw (7th November 2011)

  6. #5
    gshaw's Avatar
    Join Date
    Sep 2007
    Location
    Essex
    Posts
    2,675
    Thank Post
    168
    Thanked 221 Times in 204 Posts
    Rep Power
    67
    Thanks for the input, for some bizarre reason 2MB didn't even register with me, was only thinking 1MB, 4MB or 8MB

    Was either going to do 500GB thin or keep the size down lower at 250GB and extend if \ when required (chances are it won't need it but prefer to be able to expand up to ~512GB than have a low limit of 256GB that could get too tight)

    As for the VMFS upgrade, main reason I'm holding back is Veeam as the patch for the current version seems to have a few side effects and would prefer to wait for the new version that's been designed for vSphere 5 rather than patched up to make it work.

  7. #6

    Join Date
    Nov 2010
    Location
    Worcestershire
    Posts
    68
    Thank Post
    11
    Thanked 19 Times in 17 Posts
    Rep Power
    15
    Not too sure on the side effects, but we are running Veeam 5.0.2.230 on at least 5 clients who are running vSphere 5 with very few issues??

    Extending the virtual disks on the fly works well on 2008 and above, not so well on 2003 because of contiguous space on disks, you may need to change the disk type to Dynamic other than basic and that will affect File Level Restores in virtual backup (certainly does on quest vranger, not tried with U-AIR on latest version of veeam yet)

  8. #7
    gshaw's Avatar
    Join Date
    Sep 2007
    Location
    Essex
    Posts
    2,675
    Thank Post
    168
    Thanked 221 Times in 204 Posts
    Rep Power
    67
    Only reason I felt a bit paranoid was this from Veeam on the email susbcription


    There were couple of common issues reported by customers who had applied Veeam Backup & Replication vSphere 5 compatibility patch which can both result in reduced job performance, so I wanted to give you heads up.

    Most customers choose to upgrade to vSphere 5 along with applying said B&R patch. However, it seems that certain strategies our customers employ to move VMs to vSphere 5 brake CBT data on some VMs. Veeam B&R detects CBT data inconsistency, and fails over to legacy "snap&scan" method of determining incremental changes, which is noticeably slower than CBT (as it requires whole VM image to be read). From user pespective, this translates into very slow incremental backups. To fix CBT on affected VM, use vSphere Client to edit advanced VM setting and set all parameters with CTK letters to false. This will reset CBT, and our job will then automatically enable it on each processed VM.

    Also, under certain circumstances, the patched B&R data mover agent may exhibit increased CPU usage. In cases when B&R server lacks available CPU resources, this increase makes CPU to become a bottleneck, which in turn reduces the overall processing performance. We now have the new agent version available through our support addressing this problem. If you don't have unusually high CPU load on your B&R server after vSphere 5 patch (for example, hotadd mode is not affected by this), then you do not need to install the new agent, as it does not change anything else.
    Good to hear it's working OK so gives a bit more confidence, has the vSphere 5 update been quite painless by and large?

    Would be running on 2008 R2 but with thin disks I guess easier to just do it 500GB and avoid any extend issues

  9. #8

    Join Date
    Nov 2010
    Location
    Worcestershire
    Posts
    68
    Thank Post
    11
    Thanked 19 Times in 17 Posts
    Rep Power
    15
    Quote Originally Posted by gshaw View Post
    Good to hear it's working OK so gives a bit more confidence, has the vSphere 5 update been quite painless by and large?

    Would be running on 2008 R2 but with thin disks I guess easier to just do it 500GB and avoid any extend issues
    Has been mostly painless, there are some getting PSOD's when they have a certain patch level on the hosts and upgrade the vCenter first, but we generally have done the hosts individually and then upgraded vCenters afterwards for our clients. We have done approximately 300 hosts out of the 800 or so we actively look after for clients and no major issues yet!

  10. #9
    gshaw's Avatar
    Join Date
    Sep 2007
    Location
    Essex
    Posts
    2,675
    Thank Post
    168
    Thanked 221 Times in 204 Posts
    Rep Power
    67
    A quick update, created a new store on the VNXe expecting to blow it away in vCenter and re-create with a 2MB block size then found the SAN auto created with 8MB block. Not unsurprising in itself apart from the fact the VNXe used to create 1MB stores

    Turns out the last software update changed the default block size from 1MB to 8MB... bit odd considering 1MB is the standard going forward so one to watch out for for VNXe owners going forward. Just deciding if to leave the 8MB block now or put it back to 2MB, which is enough for what we're doing then once upgraded to VMFS5 it won't matter anyway.

    VMWare seem to suggest doing vCenter first from the docs I've seen, did you do the ESXi upgrade from local console (boot CD etc) or using Update Manager? Don't think I'll have that done before I need to make these new file server VMs hence the block size messing about now...
    Last edited by gshaw; 14th November 2011 at 04:08 PM.

  11. #10

    Join Date
    Nov 2010
    Location
    Worcestershire
    Posts
    68
    Thank Post
    11
    Thanked 19 Times in 17 Posts
    Rep Power
    15
    Quote Originally Posted by gshaw View Post
    VMWare seem to suggest doing vCenter first from the docs I've seen, did you do the ESXi upgrade from local console (boot CD etc) or using Update Manager? Don't think I'll have that done before I need to make these new file server VMs hence the block size messing about now...
    Correct - 'best practice', for a large environments and where you need to maintain the cluster sizes is to upgrade vCenter in situe, however these have been the most troublesome upgrade routes - if you are non-clustered and have a small number of hosts (as I imagine is the case in many implementations of folk on edugeek) our recommendation is as described, it will avoid the known issues around PSOD when upgrading the vCenter agent when upgrading ESXi4.0 U2 specifically. See the following KB article:

    VMware KB: ESXi 4.0 hosts may experience a purple screen after vCenter Server is upgraded to 5.0

    Message is, if you cannot go the simple route - patch first, upgrade second

  12. Thanks to andrew-virtusolve from:

    Netman (14th November 2011)

SHARE:
+ Post New Thread

Similar Threads

  1. File level VMWare ESXi VM for Linux on RDM partition.
    By albertwt in forum Thin Client and Virtual Machines
    Replies: 0
    Last Post: 18th October 2009, 02:22 PM
  2. Replies: 3
    Last Post: 26th August 2008, 11:59 AM
  3. Replies: 1
    Last Post: 13th June 2007, 05:09 PM
  4. Reccomendations For a File Server
    By disinfo in forum Hardware
    Replies: 9
    Last Post: 7th February 2007, 02:18 PM
  5. vmware or spare harddisks for "occasional" server?
    By pete in forum Thin Client and Virtual Machines
    Replies: 10
    Last Post: 6th July 2006, 07:58 AM

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •