[AIX] Cloned Servers Sharing UUIDs

[micoolpaul]

Case ID: 06005433

Hi,

I've been working through this with support today but was hoping to get some additional insights on this topic.

Client has historically duplicated a disk image for their AIX servers, and hasn't had any issues with their applications to date.
They've then pivoted to using AIX NIM mksysb restores recently, but this is after the build of all but about 2-3 of their servers.

Surprise surprise, the duplicated disk image is where the trouble lies. When installing Veeam Agent, instead of VBR presenting a list of approximately 25-30 servers within my protection group, I have 4.
This is because Veeam keeps recognising each server that was made with a duplicated disk image as an identical UUID, overwriting its configuration with a different hostname & IP address, depending on which server registers with VBR last.

We were supplied the guidance from KB4205:

Linux OS

Stop the veeamservice service.
Delete or rename the existing /var/lib/veeam/veeam_db.sqlite
Generate a random UUID and specify it in /etc/veeamagentid
The UUID value in the veeamagentid file must be in curly braces.
Start the veeamservice service.

We've tried this (including making sure that the UUID in the /etc/veeamagentid has {} encapsulating it, and when then subsequently running /opt/veeam/bin/veeamagentid, I still see the identical ID being returned.

My question is:
Where is the Veeam Agent generating this UUID from? As ultimately this guidance from Veeam is a workaround, but I need to look at where Veeam is seeing these servers as one and the same, to ensure they are presenting as unique servers. Especially as I'm not confident yet that these Linux instructions are identical for AIX.

Additional notes: Customer isn't ready for the jump to VBR v12, so this is VBR v11a with Veeam Agent for AIX v3, both on latest patches.

[PTide]

We look at the disk that holds root filesystem and then we look closer on the disk's first partition. In all cases this is going to be some LVM logical volume.
Then we get the LV's ID and calculate its MD5 hash. The result is the UUID. Generating a new LV ID for cloned machines would resolve the issue completely.

Thanks!

[micoolpaul]

Thank you for such a swift and comprehensive answer! Follow up question if you’ll permit me, does the KB article I referenced above also work with Veeam Agent for AIX? Basically, should I proceed to troubleshoot generating a UUID at /etc/veeamagentid as a workaround whilst getting appropriate changes raised for permanent resolution, or should I disregard this and push on with getting the AIX team to amend the LV UUIDs as the sole fix?

[PTide]

Place "agentIdFilePath" parameter in veeam.ini [Core] section.
The parameter defines a path to a file where system UUID is stored.

That is, you can use either of the methods, it's up to you.

[micoolpaul]

Thanks, afterwards do I need to restart services or create a new package for installation? As it’s the pre-installed package option only for AIX.

Just wondering how adjusting an INI on VBR then collates with the agent as I need to document the process for handover to customer

[micoolpaul]

Sorry I appreciate on reflection that the above message didn't make the most sense and I can't edit.

I understand there's a Veeam.ini file on the AIX server. That's fine.
I'm wondering if the Veeam.ini file can be adjusted in the package so I can pre-mitigate this risk. My scenario I foresee is:

- Generate UUID in /etc/veeamagentid
- Deploy package with modified ini included so upon installation it finds its ID from this location and initial registration with VBR is with this ID.
- Success!

[micoolpaul]

Tested this.

stopped veeamsvc
generated new UUID with surrounding {} within /var/lib/veeam/veeamagentid
modified /etc/veeam/veeam.ini - added agentIdFilePath = /var/lib/veeam/veeamagentid under the [Core] section
started veeamsvc - no success.

Did the same again with renaming the sqlite db file during the stopped services. No success
tried to run veeamconfig mode setvbrsettings --cfg <Configfile.xml>. No success
I've also tried the above but running veeamconfig mode syncnow afterwards, this command fails. I'll have to go and dig out the error message again though...

[PTide]

ok, try it again. This time don't add or modify parameters. Instead, do the following:

Code: Select all

echo '{04bfcddc-ea86-c59b-4877-32f0dd1318d5}' > /var/lib/veeam/veeamagentid
cat /var/lib/veeam/veeamagentid
{04bfcddc-ea86-c59b-4877-32f0dd1318d5}

then check whether veeamagentid returns you the same UUID:

Code: Select all

/opt/veeam/bin/veeamagentid
{04bfcddc-ea86-c59b-4877-32f0dd1318d5}

If still does not work, try to delete the parameter from veeam.ini (if deleted the agent will assume the default value "/var/lib/veeam/veeamagentid".
Also check /var/log/veeam/veeamagentid.log for records on how UUID is retrieved.

Thanks!

[micoolpaul]

Hi PTide,

I was given a workaround that appears to fix this problem.

Code: Select all

#Stop Veeam Service
Stopsrc -s veeamsvc
#Create veeamagentid backup
cp /opt/veeam/bin/veeamagentid /opt/veeam/bin/veeamagentid.bak 
#Create a new veeamagentid script
echo "echo {YOURGUIDHERE}" > /opt/veeam/bin/veeamagentid
#Add execution permissions
chmod +x /opt/veeam/bin/veeamagentid
#Start Veeam Service
startsrc -s veeamsvc
#Reset Agent to standalone mode
veeamconfig mode reset -force
#Re-register Agent with VBR
veeamconfig mode setvbrsettings --cfg <ConfigFile.xml>

This has worked for all agents