"The file is too big for the filesystem" error

[virtualesxer]

Best I put this in the proper forum. Quote:

When you create the VMFS filesystem, the block size you choose determines how big of a file (or disk) you can create. See below, but you'll need a 2 MB block size.Block Size = Max File Size

1 MB = 256 GB

2 MB = 512 GB

4 MB = 1024 GB

8 MB = 2048 GB[/i]

I ran into the same issue, wanting to create a 1.6T drive. I read this article:

http://techblog357.blogspot.com/2008/01/esx-server-35-general-system-error.html

Is the procedure mentioned therein accurate? I'm on ESX 3.5 (with an E200 controller), and I'm currently moving my 256G VM to the second store (which takes hours, really; is that normal, btw?); and I don't want to lose all my data, so I'm double-checking here.

Thanks.

[IB_IT]

I had a problem similar to yours last year when I was running with esx 3.0.x. I was moving a VM to a new location, new storage. Got this error...I believe the blocksize of the current datastore of the VM was 2mb. I had lots of free space on the new datastore, so I created a 4MB block size datastore (thinking I would use the extra space for another large volume to create). Again, my migration failed, which surprised me. I figured since the block size was larger than it needed to be, it would be able to handle the size of the VM. It wasn't until I created a new volume which matched the 2MB block size of the original that it worked.

Not sure if my situation was just an anomaly, or if you need to match the block size exactly, but hope this helps...anyone else experience the same, or different results?

[virtualesxer]

Thanks for answering. Not sure I entirely follow, though. I'm not looking to migrate per se (at least not in the 'vmware' sense of the word). I just used the Datastore Browser to move the entire VM folder to disk 2 (same physical disk, but smaller partition). If I understood the article correctly, you should then reformat the first partition (from the psycial console). The layout of that partition is:

Disk 1 vmhba0:0:3 1.95T vmfs3

In my case, seems like I need to reformat it like so:

vmkfstools --createfs vmfs3 --blocksize 8M -S vh-0:Disk 1 vmhba0:0:0:3

Right? Although I'm not sure about the "vh-0" part (not entirely certain how that part is constructed). Or whether the space in the volume label needs to be escaped. Can't VI simply reformat it for me? Also, on FreeBSD, to which I'm used, you can't just reformat a partition ('newfs'), but you need to unmount it first. Can you just skip that step in ESX?

As you can tell, there's many ways to go wrong on this. I'd like to avoid those.

Thanks.

[virtualesxer]

Something must not be right. The Datastore Browser says it's moving the file at 12901 Kbs; well, that's only 1.5MB per second! That seems excessively slow. Can someone please confirm/deny this?

[Rubeck]

Hi..

Do you have Virtual Center installed...?

If, yes,, Just choose Migrate, select the same host as target then select to move VM config. and vmdk files to new datastore.

If you do not have VC, then use "vmkfstools -i /vmfs/volumes/oldSTORAGE/VMFOLKDER/vmname.vmdk /vmfs/volumes/newSTORAGE/VMFOLDER/vmname.vmdk'

Then afterwards copy the vmx file to same folder...

I've never use the databrowser for moving/ copying VMDK files around, so I cant really tell you what speed is to be expected....

Yes, you can use the VI client for formatting.... . Well, you should actually use this as the client will correctly allign the VMFS partitions.. More info: http://www.vmware.com/pdf/esx3_partition_align.pdf

/Rubeck

[virtualesxer]

Hi..

Do you have Virtual Center installed...?

If, yes,, Just choose Migrate, select the same host as target then select to move VM config. and vmdk files to new datastore.

If you do not have VC, then use "vmkfstools -i /vmfs/volumes/oldSTORAGE/VMFOLKDER/vmname.vmdk /vmfs/volumes/newSTORAGE/VMFOLDER/vmname.vmdk'

Then afterwards copy the vmx file to same folder...

I've never use the databrowser for moving/ copying VMDK files around, so I cant really tell you what speed is to be expected....

Yes, you can use the VI client for formatting.... . Well, you should actually use this as the client will correctly allign the VMFS partitions.. More info: http://www.vmware.com/pdf/esx3_partition_align.pdf

/Rubeck[/i]

Thanks for replying. I was really kinda stuck.

Yeah, I used the Datastore Browser only because the guy in that article I mentioned specifically said to use that. And I didn't want to close the VI Client afterwards, in fear of ESX aborting the move action, too, midstream (it's at 92% now).

But no, I don't have Virtual Center installed; just the VI Client.

"vmkfstools -i" does an import, I see. Mmmm, I wonder whether moving the folder with the VM in it (VMFOLKDER in you example) was such a smart move then. But I figure I should be okay, as long as I don't actually try to start the VM before all is done, right? Kinda makes you wonder why a simple 'mv' wouldn't do the trick then.

[Rubeck · Accepted solution]

"mv" would maybe do the trick, yes.... but in cases where you have shared storage among muliple hosts, this is not a good idea as this will end up in a multiple SCS reservations, where "vmkfstools" does not.

I never "move" stuff if I can avoid it... I copy then verifies that it works, and then delete the source afterwards.... Well, this is just me.

Yeah.. You have wait until it's completed before trying to start it.. But Im sure you'll be OK.

/Rubeck

[virtualesxer]

Just to let you know, all is well again. Glad I didn't resort to manual reformatting: VI Client made it a breeze. When starting up the VM servers I got a small message, asking me to recreate a UUID or some such, which I did, but that appeared to be trivial.

And I didn't even bother copying everything back to the 1.9T disk, as it will be used for HD media and such anyway, and I read that, for that alignment thingy, it's best anyway to create the Windows VM just on Disk 2 (the second RAID5 set, with the 1MB block size, where I moved things to), so you can add an extra disk inside Windows, which will then be the 1.9T disk, for which you can then set, in Windows also, a matching stripe size for access speed. That made sense to me.