-
- 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
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.
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.
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: upgrade run ins feedback.
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).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.
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Aug 06, 2013 3:06 pm
- Full Name: Jon Roulston
- Contact:
Re: upgrade run ins feedback.
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.
-
- Veeam Software
- Posts: 21139
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: upgrade run ins feedback.
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)?
-
- Veteran
- Posts: 259
- Liked: 8 times
- Joined: Sep 18, 2009 9:56 am
- Full Name: Andrew
- Location: Adelaide, Australia
- Contact:
Re: upgrade run ins feedback.
What's the current workaround Anton?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).
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: upgrade run ins feedback.
Basically the same, just manual (delete all restore points, and map into the existing replica VM to avoid the new full sync over WAN).
-
- Expert
- Posts: 187
- Liked: 12 times
- Joined: Sep 01, 2012 2:53 pm
- Full Name: Josue Maldonado
- Contact:
[MERGED] Replication fail after disk change in the source VM
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
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
-
- Product Manager
- Posts: 20415
- Liked: 2302 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
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.
-
- Expert
- Posts: 187
- Liked: 12 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
v.Eremin thanks! that did the trick.
-
- Influencer
- Posts: 12
- Liked: never
- Joined: Apr 11, 2013 12:24 pm
- Contact:
veeam v7 replication error on changing source virtual disk
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
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
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
is this normal?
any ideas?
sebastian
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: veeam v7 replication error on changing source virtual di
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!
-
- Veteran
- 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
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.
We then have at least some idea what to expect and can use this in our planning.
-
- Veeam Software
- Posts: 21139
- Liked: 2141 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
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.
-
- Veeam Software
- Posts: 47
- 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
Since I am with a client who is experiencing this problem today, is this problem addressed in Patch 1?
-
- Veeam Software
- Posts: 21139
- Liked: 2141 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
No, it is not.
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: v7 GUID was not found, Declared and actual sizes of the
I've seen it documented as fixed in the latest Patch #2 build though.
-
- 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
I've the same problem. Fixed it as explained above (workaround).
When will Patch #2 be available?
When will Patch #2 be available?
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: v7 GUID was not found, Declared and actual sizes of the
Later this quarter, as soon as vSphere 5.5 and Hyper-V 2012 R2 support is ready and fully tested.
-
- VeeaMVP
- Posts: 6166
- Liked: 1971 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
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.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: v7 GUID was not found, Declared and actual sizes of the
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).
-
- VeeaMVP
- Posts: 6166
- Liked: 1971 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
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.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Principal EMEA Cloud Architect @ Veeam Software
@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
-
- 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
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
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
-
- Product Manager
- Posts: 20415
- Liked: 2302 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
Hi, Liviu,
As per release note, there is currently a known issue with changing the disk size of replicated VM:
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.
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).Changing the disk size of the protected VM makes the subsequent replication cycles fail with the “Declared and actual sizes of the disk” error.
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.
-
- 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
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?
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?
-
- Product Manager
- Posts: 20415
- Liked: 2302 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
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.
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.
-
- 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
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?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 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.
-
- 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
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.
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.
-
- Product Manager
- Posts: 20415
- Liked: 2302 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
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.
-
- Influencer
- Posts: 14
- Liked: 1 time
- Joined: Aug 15, 2013 7:51 am
- Full Name: Daniel Fehse
- Contact:
[MERGED] : Replication doesn't work anymore after disk expan
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
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
-
- Product Manager
- Posts: 20415
- Liked: 2302 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
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.
Thanks.
Who is online
Users browsing this forum: No registered users and 48 guests