v7 GUID was not found, Declared and actual sizes of the disk

[odge]

When upgrading one of customers our sites, most of the jobs (but not all), we had to manually go and choose the credentials again. They were giving errors that "credential with id '<GUID>' was not found". it was clearly there though since each credential was created seperately from each job (as indicated it its description). It was not worth logging since the workaround was needed anyway (migrate to using a single copy of the credential).

We also had just a few replicas that would not replicate with odd errors ("Declared and actual sizes of the disks...."). Its possible that those VMs had their disk resized since after the last backup and before we upgraded, but usually that gets handled no problem from one backup to the next. those few, we just removed and restarted since it wasn't a big deal. otherwise the upgrade was smooth.

[Gostev]

Its possible that those VMs had their disk resized since after the last backup and before we upgraded, but usually that gets handled no problem from one backup to the next. those few, we just removed and restarted since it wasn't a big deal. otherwise the upgrade was smooth.

The automated handling of this situation is broken right now, there is a known issue regarding this in the Release Notes. And the handling was not ideal anyway (as we must delete all restore points due to VMware limitation).

[Jon - MMIT]

Can somebody explain "Use a single copy of the credential"? I'm having this same issue, so I went through an removed all of my migrated credentials, and then recreated them from the "Manage Credentials" section. My jobs are still failing with this error.

[foggy]

Jon, have you changed the credentials on all your managed servers under Backup Infrastructure (including hosts, repository and proxy servers) and also within the jobs themselves (guest processing)?

[Bunce]

The automated handling of this situation is broken right now, there is a known issue regarding this in the Release Notes. And the handling was not ideal anyway (as we must delete all restore points due to VMware limitation).

What's the current workaround Anton?

[Gostev]

Basically the same, just manual (delete all restore points, and map into the existing replica VM to avoid the new full sync over WAN).

[JosueM]

Good day everyone,

After increasing the disk size of a source VM the job fails with the following error:

9/26/2013 6:05:46 PM :: Processing 'SAP-PRD' Error: Client error: An existing connection was forcibly closed by the remote host
Exception from server: Declared and actual sizes of the disk [vddk://<vddkConnSpec><viConn name="192.168.0.35" authdPort="443" vicPort="443" /><vmxPath vmRef="vm-28464" datacenterRef="datacenter-21" datacenterInventoryPath="dc5" snapshotRef="snapshot-28819" datastoreName="md34-rd5-7tb" path="SAP-PRD_replica2/SAP-PRD-STD2.vmx" /><vmdkPath datastoreName="md34-rd5-7tb" path="SAP-PRD_replica2/SAP-LSP-000003.


I seems I must erase the replica and make a new full. Wonder if there is way to avoid the full replication again?

Thanks

[veremin]

Hi, Josue. You will have to delete manually all restore points and map replicated VM to the corresponding replica one. This, way only difference between two VMs will be transferred, instead of whole image. Thanks.

[JosueM]

v.Eremin thanks! that did the trick.

[sebastian.mair]

hello,

i have veeam v7 and have replication activated for some vms.

i have no problems since i changed the vmdk file on one vm. i changed the system drive from 50gb to 100gb.

and the i got only errors with this vm.

i only get the following error

Code: Select all

30.09.2013 21:17:00 :: Error: Client error: Eine vorhandene Verbindung wurde vom Remotehost geschlossen
Exception from server: Declared and actual sizes of the disk [vddk://<vddkConnSpec><viConn name="msevc" authdPort="443" vicPort="443" /><vmxPath vmRef="vm-1363" datacenterRef="datacenter-21" datacenterInventoryPath="DataCenter" snapshotRef="snapshot-12000" datastoreName="filer03 esxvmfs05" path=" Exchange2007_replica/MAIL01.vmx" /><vmdkPath datastoreName="filer03 esxvmfs05" path="Exchange2007_rep

i think if i delete the replica from disk, it will work again, but i dont want to start a full backup over wan, because the machine has 350 gb.

is this normal?

any ideas?
sebastian

[Gostev]

Hello, this issue is documented in the release notes. I've already asked the devs to include the fix into the next patch, because this was brought up a few times already. Thanks!

[Bunce]

As found in a number of products, can I recommend that each 'known issue' be accompanied by either a current workaround, link to an applicable KB article that can be updated with up to date information, or a statement to the affect there is 'no current workaround'.

We then have at least some idea what to expect and can use this in our planning.

[foggy]

Andrew, thanks for suggestions. I would note, that if you look into Veeam B&R release notes, you will find that some of the issues already have workarounds and associated KB articles mentioned.

[jess.fuquay]

Since I am with a client who is experiencing this problem today, is this problem addressed in Patch 1?

[foggy]

No, it is not.

[Gostev]

I've seen it documented as fixed in the latest Patch #2 build though.

[Erhardt]

I've the same problem. Fixed it as explained above (workaround).

When will Patch #2 be available?

[Gostev]

Later this quarter, as soon as vSphere 5.5 and Hyper-V 2012 R2 support is ready and fully tested.

[dellock6]

So it would be version 7.1 (or whatever the number) more than a patch #2 for 7.0? Saying it because you usually place only fixes into the patches, and not "hidden" improvements (and is something I totally like, a patch is a patch).

Luca.

[Gostev]

It would be Patch #2 (an exception from the rule, I know). Think of it as a service pack this time though (a few minor enhancement added).

[dellock6]

Oh, well, I don't care even if you call it Enhancement Pack or whatever, only curious right because I was remembering the general rule. Thanks.

Luca.

[liviu.tutuianu]

Hello,

In the last period we got quite many request to modify the size of some partitions from some VMs that are replicated using Veeam. From our past experiences, we know that, in these cases, all previous snapshots will be lost, and a new full backup will be made.

What is the best practice in this case, so those backups will not be lost?

Thanks,
Liviu

[veremin]

Hi, Liviu,

As per release note, there is currently a known issue with changing the disk size of replicated VM:

Changing the disk size of the protected VM makes the subsequent replication cycles fail with the “Declared and actual sizes of the disk” error.

For now you will have to delete manually all restore points and map replicated VM to the corresponding replica one. This should be fixed in one of the next patches, when this will again be performed automatically (just as you explained).

There is no way to keep existing restore points in this case due to VMware limitation (VM snapshots do not currently support changes to base disk size).

Thanks.

[liviu.tutuianu]

Dear Eremin,

I understand your idea. But, as a workaround and to keep the old data safely, couldn't we rename the actual folder where the backup is being kept, unregister that VM_Replica and letting the replication job to run again. In this way, the first replication run will create a full backup. But how could I access the old data in case we will need it?

[veremin]

If you’re willing to keep old replicas, have the ability to access the replication data, and, meanwhile, continue to replicate, may be new job creation would be the best way to go?

Not only will it allow not to register/rename the replica VMs, but also it will provide the access to previous replication data in automatic fashion.

Thanks.

[doslager]

As per release note, there is currently a known issue with changing the disk size of replicated VM: For now you will have to delete manually all restore points and map replicated VM to the corresponding replica one. This should be fixed in one of the next patches, when this will again be performed automatically (just as you explained).

I see that it's documented in the release notes. But there is not a documented workaround or reference to a KB with a workaround. I understand that many people have replied to "manually delete all the restore points", etc. But can someone help me out with what those steps are?

I have this failing for about 4 different jobs now. IMO, this is a pretty big issue. We frequently increase VMs VMDKs as needed. To not be able to replicate these VMs and then to have Veeam reply "it's a known issue...check the release notes" is a pretty lame answer. I would've expected better from Veeam.

Can someone please help me understand the exact steps. I really dont want to delete the wrong data and have to replicate some of these VMs again. I have this failing on over 600GB of VMDKs. That would be a lot of re-replication if I did this incorrectly.

Also, is there a known release date for Patch2. If not, then stating that the issue will be fixed in Patch2 is pretty lame, as well.

Thank you in advance for your help.

[doslager]

Nevermind.

I see that "R2" was released just a few days ago. Downloaded and installed. Will re-run the jobs and see if they complete successfully now.

[veremin]

Yep, this issue is fixed in R2 update, and resizing a virtual disk should no longer result in replication job failures. Let us know if upgrading helps! Thanks.

[dfehse]

After I resized a disk of VM that I replicate I get this error:

10.02.2014 04:33:07 :: Processing 'SERVERXXX' Error: Client error: An existing connection was forcibly closed by the remote host
Exception from server: Declared and actual sizes of the disk [vddk://<vddkConnSpec><viConn name="VC" authdPort="443" vicPort="443" /><vmxPath vmRef="vm-2989" datacenterRef="datacenter-2" datacenterInventoryPath="XXX" snapshotRef="snapshot-7770" datastoreName="ESX2_LOCAL" path="SERVERXXX_replica/OSTGSRVAPP2.vmx" /><vmdkPath datastoreName="ESX2_LOCAL" path="SERVERXXX_replica/

Is there another way the to delete the VM to replicate the VM successfuly again?

Rds Daniel

[veremin]

Hi, Daniel, what product version you're using? I'm wondering since the said issue should have been fixed in R2 update and resizing virtual disk shouldn't be the problem fro replication jobs any longer.

Thanks.