TSM4V Error

illllm

ADSM.ORG Member
Joined
Jan 9, 2018
Messages
153
Reaction score
2
Points
0
PREDATAR Control23

Hello All, Greetings on a Monday morning !

Our VMware admins deleted and rebuilt a few VMs and now we get this error:

04/01/2018 22:10:14 ANS1715E A file space already exists for virtual machine (xxxxxxxx), but with a different virtual machine UUID (l73gyru734gg) than the current virtual machine UUID (bf73f7aigfi37).
04/01/2018 22:10:14 ANS4174E Full VM backup of VMware Virtual Machine 'xxxxxxxx' failed with RC=4379 mode=Incremental Forever - Incremental, target node name='TARGETNAME', data mover node name='DMFRNODE'
04/01/2018 22:10:14 ANS1228E Sending of object 'xxxxxxx' failed.
04/01/2018 22:10:14 ANS5226E The virtual machine backup operation failed.

From reading a few TSM resources, the only way to fix this is to shutdown the VM and manually change its UUID to the old one, or delete the file space and create a new one ( old backups lost ).

Is there a better way to clean this up?

Many thanks!
 
PREDATAR Control23

YES!
You need to update the GUID.
Add the -VMBACKUPUPDATEGUID to your backup vm command.

**Edit, make sure you read the doc around the VMBACKUPUPDATEGUID
 
PREDATAR Control23

Awesome ! Thank you !

-VMBACKUPUPDATEGUIDThis option updates the globally unique identifier (GUID) for the virtual machine that you are backing up. This parameter is intended for use only in the following scenario:
You want to restore an already backed up virtual machine named ORION. But, before you shut down and replace the copy of ORION that is running in your production environment, you want to verify the configuration of the restored virtual machine before you use it to replace the existing ORION.
  1. You restore the ORION virtual machine and give it a new name: dsmc restore vm Orion -vmname=Orion2
  2. You update and verify the ORION2 virtual machine and determine that it is ready to replace the existing virtual machine that is named ORION.
  3. You power down and delete ORION.
  4. You rename ORION2 so it is now named ORION.
  5. The next time that you backup ORION, by using either an incremental-forever full, or incremental-forever-incremental backup, you add the -VMBACKUPUPDATEGUID parameter to the backup vm command. This option updates the GUID, on the Tivoli® Storage Manager server, so the new GUID is associated with the stored backups for the ORION virtual machine. The chain of incremental backups is preserved; there is no need to delete existing backups and replace them with new backups.
 
PREDATAR Control23

so using -VMBACKUPUPDATEGUID didnt do any good. It just created a new filespace and backed up the VM as a new server while the old VM shows up as not backed up.
 
PREDATAR Control23

Weird, I assume this is all under the same datacenter name?

I just had an example today where I had to run the VMBACKUPUPDATEGUID option:
Code:
Protect> backup vm <<VM-NAME>> -VMBACKUPUPDATEGUID
Full BACKUP VM of virtual machines '<<VM-NAME>>'.


Backup VM command started.  Total number of virtual machines to process: 1
Accessing as node: <<DATACENTER-NAME>>
ANS1715E A file space already exists for virtual machine (<<VM-NAME>>), but w
ith a different virtual machine UUID (420bee94-2b52-d8ca-ae04-9589ffdbd9d1) than
 the current virtual machine UUID (420bf02d-39b2-42f6-824e-8a59c280c2e9).

Starting Full VM backup of VMware Virtual Machine '<<VM-NAME>>'
        mode:                        'Incremental Forever - Incremental'
        target node name:            '<<DATACENTER-NAME>>'
        data mover node name:        '<<DATACENTER-NAME>>-DATAMOVER01'
        application protection type: 'VMware'
        application(s) protected:    'n/a'
Creating "VMware Tools" snapshot for virtual machine '<<VM-NAME>>'
Backing up Full VM configuration information for '<<VM-NAME>>'
         18,504 VM Configuration [Sent]
Removing snapshot for virtual machine '<<VM-NAME>>'
ANS9387W An incremental backup for virtual machine '<<VM-NAME>>' is not possi
ble because changed block information cannot be obtained. A full VM backup is at
tempted instead.
Creating "VMware Tools" snapshot for virtual machine '<<VM-NAME>>'
Backing up Full VM configuration information for '<<VM-NAME>>'
         18,504 VM Configuration [Sent]
Processing snapshot
        disk:         [SSD-06] <<VM-NAME>>/<<VM-NAME>>-000003.vmdk (Hard
Disk 1)
        Capacity:     85,899,345,920
        Data to Send: 21,677,408,256
        Transport:     (hotadd)[sending]

The backup did finish successfully. Before running the backup I took a peek at q fi <datacenter>, the old machine was FSID 144. After the backup completed, it is still showing up as FSID 144.

Take a peek at your datamover logs and see if anything stands out.
 
PREDATAR Control23

so using -VMBACKUPUPDATEGUID didnt do any good. It just created a new filespace and backed up the VM as a new server while the old VM shows up as not backed up.
We did this recently and noticed the same thing. We opened a ticket with IBM and this was their response:
"Actually, This is normal and working as designed, the new file space should be created for the newly built VM; however after updating the GUID during the backups. these file spaces will be available along with the old file spaces already existing on the TSM server under that VM for any restore operation."
 
PREDATAR Control23

Thats interesting - thats word for word what they told us. Must be L1 support copying and pasting from a template.
 
PREDATAR Control23

So is IBM suggesting that you can add this parameter permanently to dsm.opt file to resolve these issues moving forward?? It does no harm to VM's that don't need updating??
 
PREDATAR Control23

So is IBM suggesting that you can add this parameter permanently to dsm.opt file to resolve these issues moving forward?? It does no harm to VM's that don't need updating??

I don't think so. This is a command you type at the dsmc prompt and you have to specify a vm name when you run the command.
 
PREDATAR Control23

Couldn't you add it to options parameter in the schedule??
 
Top