Veeam replication started failing on vSphere host with 'Processing VMxxx Error: Cannot replicate disk yyy.vmdk.vmdk because its capacity was reduced
Hi,
I've been using Veeam for years as a back/replication package. I started getting an error a day or so ago that is rather odd.
The first odd thing about it is the suffix: vmdk.vmdk for both virtual disks. Never seen this before. Not sure if it was named that originally as I wouldn't normally check the suffix with a VM that has been running for years (and still is).
And as a production server, I haven't made any changes to the configuration at all. The specific message is:
Processing configuration Error: Cannot replicate disk {LSI-1] ABS64/ABS64_1.vmdk.vmdk because its capacity was reduced.
The capacity of this drive is 60 gig and has been for years. Any suggestions on how to diagnose this?
Running vSphere 6 essentials with current updates applied, and Veeam B&R 9.0.0.1715.
Thanks!
--Ben
I've been using Veeam for years as a back/replication package. I started getting an error a day or so ago that is rather odd.
The first odd thing about it is the suffix: vmdk.vmdk for both virtual disks. Never seen this before. Not sure if it was named that originally as I wouldn't normally check the suffix with a VM that has been running for years (and still is).
And as a production server, I haven't made any changes to the configuration at all. The specific message is:
Processing configuration Error: Cannot replicate disk {LSI-1] ABS64/ABS64_1.vmdk.vmdk because its capacity was reduced.
The capacity of this drive is 60 gig and has been for years. Any suggestions on how to diagnose this?
Running vSphere 6 essentials with current updates applied, and Veeam B&R 9.0.0.1715.
Thanks!
--Ben
ASKER
Hi Jail,
The VM disks haven't been touched. No one here but me even knows how to log on to vSphere Manager, much less know what to do once they got there.
Where would I find the log file(s)? Typically when Veeam support has me generate logs, it is a bucketful that get put in a zip file.
--Ben
The VM disks haven't been touched. No one here but me even knows how to log on to vSphere Manager, much less know what to do once they got there.
Where would I find the log file(s)? Typically when Veeam support has me generate logs, it is a bucketful that get put in a zip file.
--Ben
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
This is a Windows 2008 R2 Standard server that is dedicated to Veeam. Had to enable viewing hidden folders to see that folder.
I had already created a stand-alone replication job and that folder (absrep) was defined.
Are these the files of interest?
Directory of C:\ProgramData\Veeam\Backu
06/18/2017 06:50 AM <DIR> .
06/18/2017 06:50 AM <DIR> ..
06/18/2017 06:49 AM 0 Agent.absrep.Digests.Targe
06/18/2017 06:49 AM 0 Agent.absrep.Source.ABS64.
06/18/2017 06:49 AM 0 Agent.absrep.Source.log
06/18/2017 06:50 AM 0 Agent.absrep.Target.ABS64.
06/18/2017 06:49 AM 0 Agent.absrep.Target.log
06/18/2017 06:50 AM 25,615 Agent.VddkHelper.log
06/18/2017 09:48 AM 60,069 Job.absrep.Replica.log
06/18/2017 09:25 AM 167,180 Task.ABS64.vm-16.log
--Ben
I had already created a stand-alone replication job and that folder (absrep) was defined.
Are these the files of interest?
Directory of C:\ProgramData\Veeam\Backu
06/18/2017 06:50 AM <DIR> .
06/18/2017 06:50 AM <DIR> ..
06/18/2017 06:49 AM 0 Agent.absrep.Digests.Targe
06/18/2017 06:49 AM 0 Agent.absrep.Source.ABS64.
06/18/2017 06:49 AM 0 Agent.absrep.Source.log
06/18/2017 06:50 AM 0 Agent.absrep.Target.ABS64.
06/18/2017 06:49 AM 0 Agent.absrep.Target.log
06/18/2017 06:50 AM 25,615 Agent.VddkHelper.log
06/18/2017 09:48 AM 60,069 Job.absrep.Replica.log
06/18/2017 09:25 AM 167,180 Task.ABS64.vm-16.log
--Ben
Hi,
Is the job name "absrep"?
If yes, then is the Job.absrep.Replica.log that we need to check.
Is the job name "absrep"?
If yes, then is the Job.absrep.Replica.log that we need to check.
ASKER
Excellent. Here you go!
job.absrep.replica2.log
job.absrep.replica2.log
ASKER
Hi Jail,
I wanted this VM to be up and running w/o issues by this morning, so I shut it down late last night and cloned it. That took care of the shrinkage issue as well as Veeam not liking it. Your suggestions were very good and add to how to handle situations like this, so I'm giving you full credit regardless.
Much appreciated!
--Ben
I wanted this VM to be up and running w/o issues by this morning, so I shut it down late last night and cloned it. That took care of the shrinkage issue as well as Veeam not liking it. Your suggestions were very good and add to how to handle situations like this, so I'm giving you full credit regardless.
Much appreciated!
--Ben
Hi Ben,
Sorry yestarday was already 4am and next day was a working day.
But anyway I will take a look at the log and provide here some information about my findings(if I find anything).
Luciano Patrao aka JailBreak
Sorry yestarday was already 4am and next day was a working day.
But anyway I will take a look at the log and provide here some information about my findings(if I find anything).
Luciano Patrao aka JailBreak
Update your answer with the log and remove the file, since I see there is some private information regarding your environemnt. I have made a copy, so you can remove the file.
ASKER
Doesn't look like I'm able to edit it once it is closed. ?
Hi Ben,
Sorry for my late reply.
Yes since is closed, you cannot changed. But if you want, you can contact support to remove the file.
Regarding the log, I dont see anything special that give us 100% the reason for this issue.
The only think i was able to see, is that there was some issues when Veeam was trying to connect to the Replica and agents drop the connection.
Honestly I don't think this is the reason for that error you get.
Question: Was the source VM move from a Datastore to a different one? Some vStorage perhaps?
Jail
Sorry for my late reply.
Yes since is closed, you cannot changed. But if you want, you can contact support to remove the file.
Regarding the log, I dont see anything special that give us 100% the reason for this issue.
The only think i was able to see, is that there was some issues when Veeam was trying to connect to the Replica and agents drop the connection.
Honestly I don't think this is the reason for that error you get.
Question: Was the source VM move from a Datastore to a different one? Some vStorage perhaps?
Jail
ASKER
Hi Luciano,
No, it's been sitting on the same datastore for years. I don't have vMotion or anything like it.
While this wasn't a graceful solution, brute force cloning was probably the quickest fix. I just hate leaving something like that without knowing. But in this case this is the first time in 10+ years this has happened, so I guess I'm good with those odds.
--Ben
No, it's been sitting on the same datastore for years. I don't have vMotion or anything like it.
While this wasn't a graceful solution, brute force cloning was probably the quickest fix. I just hate leaving something like that without knowing. But in this case this is the first time in 10+ years this has happened, so I guess I'm good with those odds.
--Ben
That vmdk.vmdk I am pretty sure is typo of someone did before.
So when we have this: because its capacity was reduced.
This is regarding the source, not the destination. Have the source VM disks been reduce?
Also can you upload the log from that replicate job? It should show more details.
Jail