-
- Novice
- Posts: 4
- Liked: never
- Joined: Aug 24, 2009 6:49 am
- Full Name: Byron Twilley
- Contact:
Suppress GUID change for replication jobs
I would like to supress Veeam from changing the GUID during replication jobs. This is because I currently use CommVault to backup my virtual machines and it idnetifies virtual machines by GUID. I still use Veeam for replication and it changes the GUID everytime it runs a replication job. Any help is appreciated.
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Suppress GUID change for replication jobs
Hi Byron, please clarify what GUID, and what VMs are you talking about (source or replica VMs). Thanks!
-
- Novice
- Posts: 4
- Liked: never
- Joined: Aug 24, 2009 6:49 am
- Full Name: Byron Twilley
- Contact:
Re: Suppress GUID change for replication jobs
Hi Gostev,
The GUID is the unique identifer for the virtual machine and the Virtual Machines that I'm trying to backup are the Source. Can confirm if Veeam replication changes the GUID of the source VM? The issue may be occuring becasue I'm trying to backup the VM with CommVault at the same time the replication is occuring if Veeam temporarily changes the GUID during replication?
Regards,
Byron
The GUID is the unique identifer for the virtual machine and the Virtual Machines that I'm trying to backup are the Source. Can confirm if Veeam replication changes the GUID of the source VM? The issue may be occuring becasue I'm trying to backup the VM with CommVault at the same time the replication is occuring if Veeam temporarily changes the GUID during replication?
Regards,
Byron
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Suppress GUID change for replication jobs
No, Veeam does not modify GUID of the source VM (why would we, there is no point). Something else is doing this. Thanks.
-
- Novice
- Posts: 4
- Liked: never
- Joined: Aug 24, 2009 6:49 am
- Full Name: Byron Twilley
- Contact:
Re: Suppress GUID change for replication jobs
Thanks for the response, I've got logs from CommVault showing the GUID change for a source server? Please see below:
15468 600c 02/20 18:01:30 1251 vsdisc::AddVMListToSubclient() - Found VM [Server1], GUID [21911131-492c-4d82-af74-3e0f434ab9da], Host [ESX1.gosford.nsw.gov.au]
19592 2e28 02/17 18:01:27 1110 vsdisc::AddVMListToSubclient() - Found VM [Server1], GUID [e7f2ab99-151d-4e77-8e0f-92670c311555], Host [ESX1.gosford.nsw.gov.au]
8952 2a94 02/17 09:39:41 1095 vsdisc::AddVMListToSubclient() - Found VM [Server1], GUID [fff1efc4-4a76-4aa1-8fbd-b16d65ed9b1f], Host [ESX1.gosford.nsw.gov.au]
Seems strange that CommVault is seeing a different GUID for a single source server when Veeam doesn't change the GUID at all?
Byron
15468 600c 02/20 18:01:30 1251 vsdisc::AddVMListToSubclient() - Found VM [Server1], GUID [21911131-492c-4d82-af74-3e0f434ab9da], Host [ESX1.gosford.nsw.gov.au]
19592 2e28 02/17 18:01:27 1110 vsdisc::AddVMListToSubclient() - Found VM [Server1], GUID [e7f2ab99-151d-4e77-8e0f-92670c311555], Host [ESX1.gosford.nsw.gov.au]
8952 2a94 02/17 09:39:41 1095 vsdisc::AddVMListToSubclient() - Found VM [Server1], GUID [fff1efc4-4a76-4aa1-8fbd-b16d65ed9b1f], Host [ESX1.gosford.nsw.gov.au]
Seems strange that CommVault is seeing a different GUID for a single source server when Veeam doesn't change the GUID at all?
Byron
-
- Service Provider
- Posts: 5
- Liked: 1 time
- Joined: Oct 17, 2012 11:38 am
- Full Name: Jeremy Porter
- Contact:
Re: Suppress GUID change for replication jobs
Hi Byron, I'm seeing exactly the same thing when using Veeam and Commvault, did you ever get to the bottom of this?
-
- Novice
- Posts: 4
- Liked: never
- Joined: Aug 24, 2009 6:49 am
- Full Name: Byron Twilley
- Contact:
Re: Suppress GUID change for replication jobs
Hey Jeremy, I came up with a solution. I've PM'd you the basic steps.jeremy.porter wrote:Hi Byron, I'm seeing exactly the same thing when using Veeam and Commvault, did you ever get to the bottom of this?
-
- Veeam Software
- Posts: 21139
- Liked: 2141 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Suppress GUID change for replication jobs
Byron, you could share the solution here just in case someone encounters the same issue in future.
-
- Service Provider
- Posts: 5
- Liked: 1 time
- Joined: Oct 17, 2012 11:38 am
- Full Name: Jeremy Porter
- Contact:
Re: Suppress GUID change for replication jobs
Hi Byron, Thanks for getting back to me, actually logged it with Commvault support and have just closed the case with them earlier this afternoon.
I've done the below combined with the VSA regular expressions you mention to include the servers I want, and exxlude the ones we don't eg the Veeam "_replicas"
Quick blurb to explain.
---
Been working with Commvault support for the VSA servers not found errors (due to changing GUIDs) and a huge amount of job result logs on D: are both related to each other.
Manually deleted 50Gb of job logs back to forever.
Their changing VM GUID's is because of using both Veeam and Commvault VSA.
As Commvault can see two VM's in its auto VM detection (the production VMs and the cloned replication DR VMs done by Veeam) it sees this as an error, eg why are their two VM's with the same unique ID so it corrects this by changing their GUIDs.
Veeam then runs and replicates this new GUID, the next night Commvault again sees two VM's with the same unique ID so it corrects this by changing the GUID again, etc etc.
The fails in the event logs are for the GUID's Commvault VSA already knows about from previous detections and is trying backup but as the GUIDs have been changed they now longer exisit.
This also blows out the job result logs folder as each night it backups up and makes a job results file for effectively a new set of servers as each with new GUIDs.
Then in 7 days when it goes to age of the job results files it ages using the current GUID which of course has changed 7 times since then so is not aged.
So nothing actually gets aged and slowly fills the drive.
Add the following registry key on the VSA host which is where you install the virtual server iDA on.
Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\CommVault Systems\Galaxy\Instance001\VirtualServer
Registry Type: DWORD Registry Name: nDisableFixDuplicateVMGuids
Registry Value: 1 (Decimal)
Then recycle services to apply.
Then ensure that the service account used by Commvault to connect to VMware for the VSA backups is denied access to the DR set of VM's.
In this case serviceCommvault account set in vSphere to have access the Production cluster/hosts/VM's and is denied to the DR cluster/hosts/VM's.
---
I've done the below combined with the VSA regular expressions you mention to include the servers I want, and exxlude the ones we don't eg the Veeam "_replicas"
Quick blurb to explain.
---
Been working with Commvault support for the VSA servers not found errors (due to changing GUIDs) and a huge amount of job result logs on D: are both related to each other.
Manually deleted 50Gb of job logs back to forever.
Their changing VM GUID's is because of using both Veeam and Commvault VSA.
As Commvault can see two VM's in its auto VM detection (the production VMs and the cloned replication DR VMs done by Veeam) it sees this as an error, eg why are their two VM's with the same unique ID so it corrects this by changing their GUIDs.
Veeam then runs and replicates this new GUID, the next night Commvault again sees two VM's with the same unique ID so it corrects this by changing the GUID again, etc etc.
The fails in the event logs are for the GUID's Commvault VSA already knows about from previous detections and is trying backup but as the GUIDs have been changed they now longer exisit.
This also blows out the job result logs folder as each night it backups up and makes a job results file for effectively a new set of servers as each with new GUIDs.
Then in 7 days when it goes to age of the job results files it ages using the current GUID which of course has changed 7 times since then so is not aged.
So nothing actually gets aged and slowly fills the drive.
Add the following registry key on the VSA host which is where you install the virtual server iDA on.
Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\CommVault Systems\Galaxy\Instance001\VirtualServer
Registry Type: DWORD Registry Name: nDisableFixDuplicateVMGuids
Registry Value: 1 (Decimal)
Then recycle services to apply.
Then ensure that the service account used by Commvault to connect to VMware for the VSA backups is denied access to the DR set of VM's.
In this case serviceCommvault account set in vSphere to have access the Production cluster/hosts/VM's and is denied to the DR cluster/hosts/VM's.
---
Who is online
Users browsing this forum: Majestic-12 [Bot] and 27 guests