Comprehensive data protection for all workloads
Post Reply
odge
Veeam ProPartner
Posts: 76
Liked: 7 times
Joined: Apr 14, 2011 3:20 pm
Full Name: Matthew Ogden
Contact:

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

Post by odge » Aug 20, 2013 10:16 pm

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
SVP, Product Management
Posts: 24446
Liked: 3410 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: upgrade run ins feedback.

Post by Gostev » Aug 20, 2013 10:39 pm

odge wrote: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
Lurker
Posts: 2
Liked: never
Joined: Aug 06, 2013 3:06 pm
Full Name: Jon Roulston
Contact:

Re: upgrade run ins feedback.

Post by Jon - MMIT » Aug 28, 2013 5:10 pm

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
Veeam Software
Posts: 18029
Liked: 1532 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: upgrade run ins feedback.

Post by foggy » Aug 28, 2013 10:06 pm

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
Expert
Posts: 259
Liked: 8 times
Joined: Sep 18, 2009 9:56 am
Full Name: Andrew
Location: Adelaide, Australia
Contact:

Re: upgrade run ins feedback.

Post by Bunce » Sep 26, 2013 11:19 pm

Gostev wrote: 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
SVP, Product Management
Posts: 24446
Liked: 3410 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: upgrade run ins feedback.

Post by Gostev » Sep 26, 2013 11:37 pm

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
Expert
Posts: 162
Liked: 10 times
Joined: Sep 01, 2012 2:53 pm
Full Name: Josue Maldonado
Contact:

[MERGED] Replication fail after disk change in the source VM

Post by JosueM » Sep 27, 2013 8:21 pm

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
Product Manager
Posts: 16689
Liked: 1393 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

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

Post by veremin » Sep 30, 2013 8:06 am 1 person likes this post

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
Expert
Posts: 162
Liked: 10 times
Joined: Sep 01, 2012 2:53 pm
Full Name: Josue Maldonado
Contact:

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

Post by JosueM » Sep 30, 2013 7:28 pm

v.Eremin thanks! that did the trick.

sebastian.mair
Novice
Posts: 8
Liked: never
Joined: Apr 11, 2013 12:24 pm
Contact:

veeam v7 replication error on changing source virtual disk

Post by sebastian.mair » Sep 30, 2013 8:12 pm

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
SVP, Product Management
Posts: 24446
Liked: 3410 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: veeam v7 replication error on changing source virtual di

Post by Gostev » Sep 30, 2013 9:59 pm

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
Expert
Posts: 259
Liked: 8 times
Joined: Sep 18, 2009 9:56 am
Full Name: Andrew
Location: Adelaide, Australia
Contact:

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

Post by Bunce » Oct 01, 2013 5:41 am

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
Veeam Software
Posts: 18029
Liked: 1532 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

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

Post by foggy » Oct 01, 2013 9:33 am

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
Veeam Software
Posts: 44
Liked: 1 time
Joined: Jan 16, 2011 9:47 pm
Full Name: Jess Fuquay

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

Post by jess.fuquay » Oct 02, 2013 3:47 pm

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

foggy
Veeam Software
Posts: 18029
Liked: 1532 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

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

Post by foggy » Oct 02, 2013 3:50 pm

No, it is not.

Gostev
SVP, Product Management
Posts: 24446
Liked: 3410 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

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

Post by Gostev » Oct 02, 2013 4:12 pm

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

Erhardt
Influencer
Posts: 18
Liked: never
Joined: Aug 23, 2013 2:25 pm
Full Name: Erhardt
Contact:

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

Post by Erhardt » Oct 09, 2013 10:25 pm

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

When will Patch #2 be available?

Gostev
SVP, Product Management
Posts: 24446
Liked: 3410 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

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

Post by Gostev » Oct 09, 2013 11:43 pm

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

dellock6
Veeam Software
Posts: 5684
Liked: 1604 times
Joined: Jul 26, 2009 3:39 pm
Full Name: Luca Dell'Oca
Location: Varese, Italy
Contact:

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

Post by dellock6 » Oct 10, 2013 4:58 pm

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.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software

@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2019
Veeam VMCE #1

Gostev
SVP, Product Management
Posts: 24446
Liked: 3410 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

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

Post by Gostev » Oct 10, 2013 10:34 pm

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
Veeam Software
Posts: 5684
Liked: 1604 times
Joined: Jul 26, 2009 3:39 pm
Full Name: Luca Dell'Oca
Location: Varese, Italy
Contact:

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

Post by dellock6 » Oct 11, 2013 3:38 pm

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.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software

@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2019
Veeam VMCE #1

liviu.tutuianu
Enthusiast
Posts: 40
Liked: never
Joined: Jul 09, 2012 8:17 am
Full Name: Liviu Tutuianu
Contact:

[MERGED] : What should we do if we change the partition size

Post by liviu.tutuianu » Oct 23, 2013 7:40 am

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
Product Manager
Posts: 16689
Liked: 1393 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

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

Post by veremin » Oct 23, 2013 8:12 am

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
Enthusiast
Posts: 40
Liked: never
Joined: Jul 09, 2012 8:17 am
Full Name: Liviu Tutuianu
Contact:

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

Post by liviu.tutuianu » Oct 23, 2013 11:39 am

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
Product Manager
Posts: 16689
Liked: 1393 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

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

Post by veremin » Oct 23, 2013 11:48 am

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
Novice
Posts: 6
Liked: 1 time
Joined: Nov 02, 2012 3:21 pm
Full Name: Dave O.
Contact:

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

Post by doslager » Nov 17, 2013 11:17 pm

v.Eremin wrote: 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
Novice
Posts: 6
Liked: 1 time
Joined: Nov 02, 2012 3:21 pm
Full Name: Dave O.
Contact:

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

Post by doslager » Nov 18, 2013 4:15 am

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
Product Manager
Posts: 16689
Liked: 1393 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

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

Post by veremin » Nov 18, 2013 6:46 pm

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
Influencer
Posts: 10
Liked: never
Joined: Aug 15, 2013 7:51 am
Full Name: Daniel Fehse
Contact:

[MERGED] : Replication doesn't work anymore after disk expan

Post by dfehse » Feb 10, 2014 6:44 am

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
Product Manager
Posts: 16689
Liked: 1393 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

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

Post by veremin » Feb 10, 2014 9:11 am

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.

Post Reply

Who is online

Users browsing this forum: Baidu [Spider], Dima P., RubinCompServ and 35 guests