Declared and actual sizes of the disk are different

[fabu]

I attempted to restore a VM from backup and received this error. I ended up rebuilding the VM, which was unnecessary because I could have just restored all the VM files from the backup and registered the VM in vCenter manually as a workaround. I went through a number of troubleshooting steps to resolve the issue, but could not get a backup of the VM that I could actually restore from. Veeam support has seen this error before with VMs on NFS storage, but it was mostly applicable to servers that were p2v'd and was related to the fact that the disk size was not an even number. This server is on NFS storage, but was built from a VM template, not p2v, and the disk size was an even number.

I had a theory that the affected VMs were those that had their disk aligned using NetApp's mbralign tool. So, I took a server with a misaligned disk and confirmed that I could back it up and restore it with no issues. I then aligned the disk with NetApp's mbralign tool, backed up the server, and attempted to restore it. It failed with the error "declared and actual sizes of the disk are different". So that confirmed that the mbralign process is what is causing this issue.

Fortunately the fix is an easy one. Just add 1 GB of space to the affected disk and back it up again.

[veremin]

Hi, Lisa. Thank you for sharing information with community, highly appreciated.

[homerjnick]

Hi,

We are still on Veeam 6.5 and we have a Netapp SAN. We had a few Server 2003 VM's on the SAN that our ESXi environment were using in Production and these VM's were misaligned and needed to be realigned.

Using Netapp's MBRALIGN tool I realigned the vmdk's of the VM's. The next backup had a warning about CBT which I expected but the second backup was fine.

Replication however seems stuffed...when I try and replicate I get this error:

Code: Select all

05/09/2013 09:20:02 :: Error: Client error: Declared and actual sizes of the disk [vddk://<vddkConnSpec><viConn name="spp-wickvc64" authdPort="443" vicPort="443" /><vmxPath vmRef="vm-241" datacenterRef="datacenter-21" datacenterInventoryPath="SPP-DR-DATACENTER" snapshotRef="snapshot-42119" datastoreName="WICKESX-FC1" path="VRT-FTP_replica/VRT-FTP.vmx" /><vmdkPath datastoreName="WICKESX-FC1" path="VRT-FTP_replica/VRT-FTP-000002.vmdk" /><transports seq="hotadd;nbd" hotAddRedirection="1" /><readBuffer size="4194304" /></vddkConnSpec

I really can't afford to start replication again from scratch and to get a seed would be a pain as the DR site is far, far away from me.

Any guru's know what could be done? The SAN at the other end is not a Netapp SAN.

I have not logged a support call with Veeam as it is not really an issue with the product, it is just that I ran a tool that realigned the vmdk to be optimized for Netapp SAN's.

[veremin]

Most likely, mbralign process has broken replication jobs. Instead of performing completely new replication job or seeding it through the WAN bandwidth, it might be worth re-creating job and mapping it to already existing replica VM. Assuming that not a lot of changes have occurred since the latest replication run, the initial synchronization process shouldn’t take that long. Thanks.

[homerjnick]

I edited the job to re-add the VM and remapped it but still got the same error...but I never tried creating a new replication job and remapping it...I'll try that...

[veremin]

Might do the trick; though, please, be aware that previous restore points will be merged, and after the initial replication run, there will be only two available. Thanks.

[homerjnick]

A new job mapped to an existing replica gives the same error....what a shame...

[foggy]

Is there a chance that the size of those VMs disks has changed after alignment? Then you probably can perform the same change on the replica VMs at the target site and remap the job before running it.

[homerjnick]

Case Number: 00445745

I backed up the VM's to a NAS, transported it to my DR site, added it as a reposititry and rescanned it. I then created a NEW replication job after deleting the old replica and used the backup from the NAS as a seed and the job fails with the same error:

16/09/2013 15:56:35 :: Error: Client error: Declared and actual sizes of the disk [vddk://<vddkConnSpec><viConn name="spp-wickvc64" authdPort="443" vicPort="443" /><vmxPath vmRef="vm-42360" datacenterRef="datacenter-21" datacenterInventoryPath="SPP-DR-DATACENTER" snapshotRef="snapshot-42362" datastoreName="WICKESX-FC1" path="VRT-SPPDC01_replica/VRT-SPPDC01.vmx" /><vmdkPath datastoreName="WICKESX-FC1" path="VRT-SPPDC01_replica/VRT-SPPDC01.vmdk" /><transports seq="hotadd;nbd" hotAddRedirection="1" /><readBuffer size="4194304" /></v

Now I'm lost, the VM's backup fine but I wonder if they restore fine...I'll need to test that. Replication for now is bust after running the Netapp tool MBRALIGN...

[homerjnick]

Is there a chance that the size of those VMs disks has changed after alignment? Then you probably can perform the same change on the replica VMs at the target site and remap the job before running it.

I have not manually changed anything but because the tool realigns at the block level starting at block 63 and moves everything one block so it starts at 64 it is possible that the disk's have grown by one block?

But I am confused, creating a new backup as a seed and creating a new replica job gives the same results....

[davidb1234]

Just wanted to let you guys know I used partition magic to align a windows 2003 VM last week. I got a CBT error during the next run but other than that both my backup and replication jobs seem to be running ok for this VM. This is with version 6.5.

[foggy]

Nick, what if you try to manually restore the VM from that new backup to the DR host and map the new replica job to it?

[homerjnick]

Great idea!

Tried that and the restore fails with exactly the same error...this now worries me...I need to test a restore in my Production environment...the severity of this case might just have gone up!

[homerjnick]

Confirmed...I cannot restore a VM in my Production environment that has had its vmdk realigned by the Netapp MBRALIGN tool.

I will update my case to say so...the severity of this issue needs to increase...

[foggy]

Oops.. My occasional forum search led me to the topic I'm merging you into right now. Worth trying the solution proposed by Lisa above.

[homerjnick]

I can't restore any of these VM's by choosing the restore VM option that registers the VM in the environment but naturally I can restore the individual VMDK's from backups so that is not bad...

Veeam support wanted me to export my logs and since I'm on 6.5 I cannot choose a time period (v7 option only?) and at 13% of the export of my logs it was at 1.8GB...no way I can FTP that...

[Vitaliy S.]

Nick, usually only 2-3 log files are required, so please ask your engineer to inform you what he needs to investigate it further.

[foggy]

Nick, could you try the solution provided above:

Fortunately the fix is an easy one. Just add 1 GB of space to the affected disk and back it up again.

I.e. add some space to the source VM and perform a job run. This will cause the entire drive read and deletion of all replica restore points except the most recent one, but you can map the job to the replica VM to avoid sending all the data over the WAN.

[homerjnick]

Yes, Tier 2 support suggested the same thing and it works....resizing the vmdk by a little causes it to be rescanned and thus the error goes away...

[foggy]

Glad it helped. Thanks for confirming!