Snapshot Size 2TB

[ureitz]

Hi,

we have created an VM with 3 virtual thick Harddisks.

1. 40 GB
2. 2 TB
3. 2 TB

The datastore is VMFS 5 with standard installation (1 MB block size).

Backup not possible. Error: File <unspecified filename> is larger than the maximum size supported by the datastore '<unspecified datastore>.

I red here ,http://kb.vmware.com/kb/1012384, 2 TB ist the maximum in this configuration. But it is 2TB. Or was the error to create a vmdk with exactly 2 TB, should it be 1.99x ?

Is there an easy way to backup this maschine ?

Because of large data and downtime issues, it is difficult to move or convert the vm.

Thanks for help

[Vitaliy S.]

Hi Ulf,

Based on the findings from Espen's research it is not possible to create the snapshot within a vSphere Client for a VM with 2 TB virtual disks even if you're running this VM on VMFS 5. The capacity of the virtual disks should be around 1.99 TB to make snapshots work.

For further details please take a look at this thread: Backup fails- Processing 'Servername'

Thanks!

[dellock6]

Maximum size of a VMDK or a vRDM should be 2Tb - 512 bytes, so choosing 1.99 Tb is a safe move.

Luca.

[Zulaab]

I have an old server and new server.

I have 1 VM I would like to migrate.
The VM is made up of three harddrives
1. 50GB (stored on datastore 1)
2. 50GB (stored on datastore 1)
3. 2TB (stored on datastore 2)

I enter into the quick migration tool

Configuration files to Newdatastore 2 (2TB datastore)
Disk 1 - Newdatastore 1 (1.4 TB free)
Disk 2 - Newdatastore 1 (1.4 TB free)
Disk 3 - Newdatastore 2 (2TB Free)

Validation tool -- passed no issues seen
Run migration. Processing. Fails.
Error : Failed to process VM 'fileserver1' at 2013-03-26T181151 Error: File fileserver1/fileserver1.vmx is larger than the maximum size supported by datastore '[Newdatastore 2]

-- The problem I see is it attempt to move all of the VM's diskdrives to Newdatastore 2 (The store is just big enough to handle the 2TB drive)
-- After it fails I open Newdatastore 2 up in VMware, and I see "Disk 1" , "Disk 2" and "Disk 3" which is why it fails.

-- Is there a way for the quick migration tool to do what it tells you its going to do.. ie put the disks on the datastores that you tell it to go to or does it always attempt to copy everything to one datastore and then move the datastores after the migration to where it is you want them to end up at ? I am not sure because this is the only server I have a problem with because the datastore I want to put one disk on is sized the same.

If I buy the licensed copy is this fixed in this copy ? or is the free version the same when it comes to the quick migration part ?

[foggy]

Jesper, most likely you cannot even snapshot this VM using vSphere Client as it has 2TB disk, which exceeds the maximum allowed size (see above). You can use File Copy job instead to migrate this VM to the new datastore and then register it on the new host.

[dellock6]

The safest maximum size for a VMDK file should be 1.98 Tb or 2027 Gb, here's why: http://www.virtualtothecore.com/en/?p=4129 (sorry for shameless self-promotion )

Luca.

[Zulaab]

Jesper, most likely you cannot even snapshot this VM using vSphere Client as it has 2TB disk, which exceeds the maximum allowed size (see above). You can use File Copy job instead to migrate this VM to the new datastore and then register it on the new host.

Thank you for your insight.. Can you explain to me why then is VeeamZip attempting to put ALL of the datastores (even if you tell it to put them over several datastores) only into the one datastore that you choose where the configuration files are set to ? Because after the failure here is what I see :

Browse datastore on the new server (which ever was set to the folder "configuration files"

Disk 1 = 50GB
DIsk 2 = 50GB
Disk 3 = 2TB.

Datastore is 2TB... not 2.1TB in size which is why it fails. The validator says yes this will work.. because the first two disks are going to be on datastores that have plenty of space for them, but its WAY WAY WAY obvious that VeeamZip first creates all of the disks on one datastore, and then (I assume) is it will vstorage motion the datastores to their final destination. Why not just create the snapshots on the datastores where the final destination is going to be and overcome this issue ?

[Vitaliy S.]

Why not just create the snapshots on the datastores where the final destination is going to be and overcome this issue ?

Snapshot is created where VMware instructs it to be created, if you want to redirect snapshot home directory to another datastore try to use workingDir parameter, should help.

[veremin]

Can you explain to me why then is VeeamZip attempting to put ALL of the datastores?

Are you probably referring to Quick Migration and no to VeeamZIP functionallity?

We’ve just tested it in our environment and disk datastore redirection seems to have worked properly (during migration process corresponding disks were moved rightly to specified datastores).

If you observe different behaviour and/or can reproduce abovementioned situation with the disk less than 2 TB, then, please open a ticket with our support team and let them address this issue directly.

Hope this helps.
Thanks.

[averylarry]

http://kb.vmware.com/selfservice/micros ... Id=1012384

Maximum size for a vmdk file: 2Tb - 512 bytes.
Maximum size for a vmdk file that can have a snapshot: 2Tb - 512 bytes minus ~16Gb possible overhead. Officially 2032 Gb.
Maximum size for a vmdk file that you want Veeam to hotadd: 1.98TB or 2027.52 Gb.


Yes, for hotadd, the max. vmdk file size is even smaller than the snapshot max. This was determined to be the "fault" of VMware's VDDK 5.1 (the VMware module that Veeam uses for hotadd (as I understand it)). The final number was found by trial and error both by myself and Veeam tech support (case # 00154561). It was so annoying because I purposefully created a 2030 Gb vmdk file to allow for snapshots (I actually did my homework) only to have hotadd fail.

Note -- I've been told that direct san mode does not have the additional limitation (it does obviously have the snapshot limitation), but I haven't verified this since I don't use direct san mode.

[dellock6]

Ted, I can confirm you based on several Veeam deployment, on Direct SAN mode 2032 Gb is a working limit for VMDKs, but because you never know if in the future a DirectSAN backup could be changed to hotadd, I usually instruct customers to create VMDKs at 2027 Gb, at the end is only 5 Gb difference out of 2 Tb disk...

Luca.

[averylarry]

What bugs me -- why doesn't VMware just make the VMDK file size limitation 2027Gb? Just like you said -- nobody will realistically care about 21Gb short of 2Tb (only 1%). Then nobody has to run into the 2 separate problems I had -- the first time I created a VMDK that couldn't do a snapshot, and then I created one that could have a snapshot but couldn't use hotadd (I'd love an explanation for that from VMware).