Error after vSphere update

[Gostev]

You could simply change workingDir VM configuration parameter. This is what defines the snapshot files location. This way you get to keep unique VM ID (otherwise, some VMware managements tools may get affected).

[Daveyd]

Does moving the vmx file and re-inventoring it move the vswap file as well? I know if I change the working directory, the vswap file will be created there as well taking up more space (the VM RAM size) on the datastore

[Gostev]

Not sure about this one. Might be best to check on VMware forums. I am assuming yes.

[Daveyd]

What if I have a VM with 3 separate VMDKs on 3 different datastores with 3 different block sizes? Does the vmx file need to reside on the datastore with the largest block size?

[Gostev]

Correct.

[Daveyd]

So, an easy way to move the config file to a datastore with a larger block size is to do a svMotion with Advanced settings and choose just to svmotion the config file to the Datastore with the larger black size.

The other way would be to reformat the Datastore that the vmx file resides on, in my case a Datastore formatted with 1MB block size, to 8MB block size. However, I did see this question asked about formating a drive to 8MB block size...

The difference would be when talking about changed block tracking (vStorage API) and incremental blockbased backups (correct me if I'm wrong). When changing a 1KB file on a FS with 1MB blocksize, the incremental backup would consist of that 1MB block. When using a 8MB blocksize the backup would need to back up the entire 8MB block.

When dealing with a disk that has lots of small changes here and there throughout the disk (ie. OS disk), a smaller blocksize is preferrable from a backup standpoint. The implications of 1MB vs 8MB block sizes could potentially be a 8 times larger backup.

Does that seem logical? Would Veeam's deduping take care deduping the entire 8MB block causing less space to be taken up in a Veeam backup?

[tsightler]

Veeam's block size is independent of the VMFS block size so there will be no effect on backup size.

[Gostev]

Correct. VMFS block size does not affect anything in our product.

[pburton]

I have a VM with a 40GB (thin provisioned) OS drive and a 256GB (max size on our 1MB block datastore) data drive. I'm getting the same error as everyone else when I try to use Veeam to back it up. Instead of moving the VM to a new datastore with a different block size of reformatting my datastore, can I just shrink my data drive a couple gig? If so, what would be the easiest way to shrink it? The OS is not on this VMDK. I've read that I could use VMware Converter to shrink it, but then that would require moving the VM or renaming it to create the new VM with the smaller volume, right? Is there just a tool that I can use to shrink a vmdk file? I could even do this offline if that is required by some tools.

[pburton]

I came across a website that explained how to manually edit a VMDK descriptor file to change the size of the VMDK. Once you modify the descriptor you have to migrate the VM to a different datastore. I shut down my VM and then used Veeam Fast SCP to connect to my datastore and edited the descriptor file. My VM's data drive was 256GB and I wanted it around 250GB to hopefully fix my inability to create snapshots and backups. See this link for the instructions I followed: http://professionalvmware.com/2009/09/h ... le-in-esx/
My VMDK was 536870912. I wanted to make it roughly 97% as big as it was so after a little math and erring on the side of caution I used the number 520764784. Then since my VM was already shutdown, I cold migrated it from my RAID10 datastore to my RAID5 datastore. I checked the settings of the VM through vCenter and it shows that my data drive on that VM is 248GB... Perfect. Then I cold migrated it back to my RAID10 datastore and booted it up. Everything seems happy.

I do want to note that in Windows my partition on the data volume was not fully provisioned. My data partition on the volume was actually significantly smaller than the total size that Disk Manager in Windows reported the volume to be. I don't know if it would be a problem in Windows if my data partition was the full size of the volume or not, but in Windows Server 2008 you can shrink a partition, so if you have a Windows partition that is the full size of the volume, it might not be a bad idea to go ahead and shrink the partition in Windows down a bit before shrinking the actual VMDK file.

Try all of this at your own risk. It worked for me so I wanted to post it for anyone else who is in this same situation as something to consider trying. It was REALLY quick and easy to do. Even with the moves back and forth between datastores the whole process took less than 15 minutes, and YES, I have run a sucessful Veeam backup on that VM since I performed these steps.

[cby]

[merged]

Hi

I've been running Veeam backup with a number of RHEL5.n VMs. Last week I had to increase the disk size on one of the VMs from 200GB to 256GB (single partition). The VM in question has multiple disks across 2 datastores (1MB block size). When I tried to back up this particular VM Veeam failed with one of the following errors depending on whether backup was run with/without Vmware tools quiescence...

With Vmware tools quiescence:

Code: Select all

Freezing guest operating system
CreateSnapshot failed, vmRef "vm-8017", timeout "1800000", snName "VEEAM BACKUP TEMPORARY SNAPSHOT", snDescription "Please do not delete this snapshot. It is being used by Veeam Backup.", memory "False", quiesce "True"
Cannot create a quiesced snapshot because the create snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine.

Without Vmware tools quiescence:

Code: Select all

Freezing guest operating system
CreateSnapshot failed, vmRef "vm-8017", timeout "1800000", snName "VEEAM BACKUP TEMPORARY SNAPSHOT", snDescription "Please do not delete this snapshot. It is being used by Veeam Backup.", memory "False", quiesce "False"
File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>

I thought that perhaps because the disk size was on the limit of the 1MB block size datastore that if I migrated it to a 2MB block size datastore it would solve the problem, but it made no difference -- same error messages. I also tried excluding the 256GB disk from the backup though, again, this made no difference.

I've trawled through the forum but not found the solution to this rather pressing problem. The same error messages are produced by Veeam versions 4.1.2 and 5.0.2 at the point of creating the VM snapshot with and without Vmware tools quiescence.

Any help appreciated.
cby

[Vitaliy S.]

Your errors are not related to each other, to resolve the the last one please look through this thread, as for the first one, please contact our support team as it is explained when you click New Topic. Thanks.

[Gostev]

Actually, the first one is known issue with VMware Tools quiescence. Disable it, and use the application-aware image processing option in backup job settings instead.

[cby]

Here are couple of things which worked for me:

- Try migrating the .vmx file to the datastore with the largest block size

- If you are running at the optimum file size for the designated block size (i.e. 256GB partition on a 1MB block datastore) try reducing this by 1GB (e.g. 256GB --> 255GB) using a Linux live CD with gparted (e.g. System rescue CD)

If you are familiar with the layout of the .vmx file you can leave it in place but define a different location for snapshots if different from default VM (see http://kb.vmware.com/selfservice/micros ... Id=1002929). I haven't tried this so can't vouch for its efficacy.

I guess others have covered this!

cby

[Gostev]

Changing workingDir is probably the easiest fix. By default, if workingDir is not set, so datastore with VMX file is used to hold snapshots (which is why moving VMX help). No need to edit VMX directly, you can add the setting through vSphere client. Power off VM, then go to vSphere Client > Select VM> Summary > Options > General > Configuration Parameters > Add Row. Add workingDir parameter as per KB above. Power on VM.

The good news is, this whole issue is going away with vSphere 5, because VMFS5 will have the same block size no matter of datastore size.

Thanks!

[Wlacroix]

I just want to be sure I understand this error and how to fix it.
"File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>"

DS3500 using ISCSI
Block size is 4mb, segment size is 128k

Configured server in question is a file server, a big one. Unfortionatly its now in production.

C: 60gb
D: 500gb
E: 500gb
F: 1tb

From my research, the block size on the datastore in question has to be 8mb to accomidate the snap shot file while the back runs. Please correct me if im wrong.

Now....
Can I increase the block size on the DS3500 without a format?

[Gostev]

AFAIK format is required. Keep in mind that instead, you can create the new datastore to hold snapshots, and redirect VM snapshot location there.

[Vitaliy S.]

Hi Wally,

And if you want to redirect the default snapshot location use vSphere Client: Select VM> Summary > Options > General > Configuration Parameters > Add Row. Add workingDir parameter to set a new datastore path for the snapshots.

Thanks.

[Wlacroix]

BUMP, I found it. Thanks guys.

Regards,
Wally

[knhod@notteroy]

[merged]

Trying to back up an exchange server (Exchange 2003) and receiving error:

CreateSnapshot failed, vmRef "vm-10750", timeout "1800000", snName "VEEAM BACKUP TEMPORARY SNAPSHOT", snDescription "Please do not delete this snapshot. It is being used by Veeam Backup.", memory "False", quiesce "False" File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>

Another Exchange server (2010) sorks fine.

Searcing for VM-10750 in the forum or google gives no feedback.

Help....

[X-POSE]

I am having the same issue

Runnin vSphere 5 / Veeam B&R 5.0.2.230 with the 5.0.2.255 hotfix.

I am still getting the error:

Freezing guest operating system\CreateSnapshot failed, vmRef "vm-13", timeout "1800000", snName "VEEAM BACKUP TEMPORARY SNAPSHOT", Description "Please do not delete this snapshot. It is being used by Veeam Backup.", memory "False", quiesce "False"\File BMASBS/BMASBS.vmx is larger than the maximum size supported by datastore '[BMA-SYSTEM]

This is a brand new install of vSphere 5 Essentials and Veeam Essentials.

Any ideas?

[tsightler]

Is this a brand new datastore? Can you create a snapshot via vCenter of this VM? With vSphere 4 this would normally mean that the datastore on which the .vmx file is stored does not have a large enough block size to store the snapshots for the VMDK files on the larger datastores. The easiest fix (without downtime) is to use vMotion to relocate the VM configuration (.vmx file) to a datastore with the largest block size.

That being said, I thought the VMFS5 used a consistent block size, but if these were upgraded VMFS3 datastores it might still be an issue.

[X-POSE]

brand new install and datastores on vmfs5 (no upgrade) - all 1mb block size - Not changable. Maximum size seems to be auto calculated.

All disks needing to be backed up:

Hard Disk 1: 250GB
Hard Disk 2: 600GB
Hard Disk 3: 2TB

[tsightler]

Can you take a snapshot with vCenter? The 2TB disk is somewhat of a concern. How big is the datastore on which that disk is installed? Does it have enough space to store the snapshot? According to VMware a snapshot of a 2TB VMDK requires 16GB of "overhead" meaning that the usable space is 2032GB, plus, with vSphere 5 the snapshots are created on the datastore on which the individual disks are stored so each disk requires enough space to store the snapshot files. See the "Calculating the overhead required by by snapshot files" in the following VMware KB article:

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

They list the approximate required overhead for various VMDK sizes, and then state this:

Note: VMware recommends that you to create virtual disks of size less than the maximum minus the overhead, to enable use of features like Snapshot, Clone, and Independent-nonpersistent disks.

[NYTECJ]

[merged]

Error:
Freezing guest operating system CreateSnapshot failed, vmRef "192", timeout "1800000", snName "VEEAM BACKUP TEMPORARY SNAPSHOT", snDescription "Please do not delete this snapshot. It is being used by Veeam Backup.", memory "False", quiesce "False" File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>

I have a server with two 256gb drives on two separate datastores. One 256gb drive on Datastore0 and the second on datastore1. There is nothing on the second drive. Veeam shows 316gb of space is needed. Even if I exclude the second drive. I am running V5.02.230. This server in question is what Veeam is running. Backup of all other VM servers are successful.

[ahmedrami]

[merged]

Hi,
We use Vmware vSpere 4.1 in our Data Center ,and Veeam for replication.
I am trying to replicate my mail server which is( 1.09 T),but the replication always it fail. And I got this message:
File<unspecified filename> is larger than the maximum size supported by datastore’<unspecified datastore>
Note:The destination DataStore is(1.82 T)
thanks,
Ahmedrami,

[framepool]

[merged]

Hi,

i have this error on 2 of my VM's.
the disk size of the VM is 256gby and the blocksize is 1mb
i'm using ESXi 4.1.0 build 348481 and 4.0.0 build 208167 also Veeam Backup and Replication 6.0.0.153

so my question is, how can i get a backup of this 2 Vm's

can i change the blocksize and keep the VM's?
is there an easyier way to get a b&R of those 2 VM's

Thx in advance even if this question was already asked, but i havent found a solution yet

[LeoJBI]

[merged]

5/2/2012 1:50:00 AM :: Error: File <unspecified filename> is larger than the maximum size supported by datastore '<unspecified datastore>

How do I interrupt this message? Am I looking at the size of my datastore or block size? How do I resolve it? I am attempting to backup a Sharepoint 2010 sever.

Please advise...

[LeoJBI]

[merged]

Hello,

I just received the error telling me that the "File is larger than the max. size supported by the datastore". I just read through the material I could find on the subject, But, I have some confusion.

I am attempting to backup a newly created VM that is hosting my Sharepoint 2010. It currently only occupies 25gb (with 75gb free). However, when I browse the datastore for my vmdk file, I notice that the provision size is 104gb!

My question is; if I reduce the number of Restore points, would this reduce the space provisioned? I am trying to look into a quick solution until I have time to more thoroughly research this dilemma.

Thanks for your help,

Leo

[Vitaliy S.]

Hi Leo, reducing the number of restore points wouldn't help, as the error relates to VMFS datastore block size. Please look through this topic to get more info on the resolution.