• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

TSM4V Error

illllm

ADSM.ORG Member
#1
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!
 

RecoveryOne

ADSM.ORG Senior Member
#2
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
 

illllm

ADSM.ORG Member
#3
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.
 

illllm

ADSM.ORG Member
#4
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.
 

RecoveryOne

ADSM.ORG Senior Member
#5
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.
 

inovermyhead

Active Newcomer
#6
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."
 

booman55

ADSM.ORG Senior Member
#8
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??
 
#9
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.
 

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 16 18.8%
  • Keep using TSM for Spectrum Protect.

    Votes: 52 61.2%
  • Let's be formal and just say Spectrum Protect

    Votes: 10 11.8%
  • Other (please comement)

    Votes: 7 8.2%

Forum statistics

Threads
31,449
Messages
133,979
Members
21,549
Latest member
idhelmyy
Top