NAUbackup / VmBackup

XenServer simple backup script
228 stars 62 forks source link

*** ERROR: duplicate VM name found #93

Closed ilium007 closed 4 years ago

ilium007 commented 5 years ago

Getting the " *** ERROR: duplicate VM name found" when running script. There is only 1 VM by the name "prd_win10_01".


[root@citrix01 NAUbackup]#  xe vm-list
uuid ( RO)           : e6c68bdb-a9f2-d16d-456d-1cc70fb44916
     name-label ( RW): Windows Server 2019 (64-bit)
    power-state ( RO): running

uuid ( RO)           : c5e06878-6927-5b33-08df-6b9802195805
     name-label ( RW): prd_win10_01
    power-state ( RO): running

uuid ( RO)           : 20974601-ae83-46d3-ad1d-ad3216504362
     name-label ( RW): Control domain on host: citrix01
    power-state ( RO): running

[root@citrix01 NAUbackup]# ./VmBackup.py xxxxpassword "prd_win10_01" preview
2019-06-30-(16:52:37) - VmBackup config loaded from: prd_win10_012019-06-30-(16:52:37) - VmBackup.py running with these settings:
2019-06-30-(16:52:37) -   backup_dir        = /snapshots/BACKUPS
2019-06-30-(16:52:37) -   status_log        = /snapshots/NAUbackup/status.log
2019-06-30-(16:52:37) -   compress          = False
2019-06-30-(16:52:37) -   max_backups       = 4
2019-06-30-(16:52:37) -   vdi_export_format = raw
2019-06-30-(16:52:37) -   pool_db_backup    = 0
2019-06-30-(16:52:37) -   exclude (cnt)= 0
2019-06-30-(16:52:37) -   exclude: 
2019-06-30-(16:52:37) -   vdi-export (cnt)= 0
2019-06-30-(16:52:37) -   vdi-export: 
2019-06-30-(16:52:37) -   vm-export (cnt)= 1
2019-06-30-(16:52:37) -   vm-export: prd_win10_01
2019-06-30-(16:52:37) - Checking all VMs for duplicate names ...
2019-06-30-(16:52:37) - *** ERROR: duplicate VM name found: Windows Server 2019 (64-bit) | ['OpaqueRef:aeb6ea6e-4b17-4726-ab5d-e86b83cf16aa', 'OpaqueRef:9d3a9abd-1f79-4b9c-a396-c699b473e274']
2019-06-30-(16:52:37) - SUCCESS preview of parameters 
[root@citrix01 NAUbackup]# 

IMG_0243

ilium007 commented 5 years ago

When I ran without "preview" it worked

NAUbackup commented 5 years ago

Which release do you see this in 3.23, 3.24, ...? The issue only happens with preview, evidently.

ilium007 commented 5 years ago

Apologies.

V3.24 July 2019

NAUbackup commented 5 years ago

Thanks, that's important to know! To be clear you have defined a single VDI backup and no VM backups, correct?

ilium007 commented 5 years ago

No, it was a VM backup (see above commands)

NAUbackup commented 4 years ago

This is so bizarre. I can duplicate the error on my CH 8.0 test pool, which finally got connected to external backup storage. This may be a limitation of the API call. Note that if you change the name-label to contain instead of 2019 either 2016 or 2008, it still fails, but works if you use 2004 or 2007! There must be some reference to an OS type that's getting in confused is all I can think of for now. Check out: https://docs.citrix.com/en-us/legacy-archive/downloads/xs-sdk-guide-7-2.pdf and look for a comment regarding the call session.xenapi.VM.get_by_name_label and it not necessarily returning a unique reference! Was your VM by chance one you duplicated from that other VM in that pool?

ilium007 commented 4 years ago

No, the VM was built - not duplicated. One is a 2019 Windows Server, the other is a Windows 10 machine.

NAUbackup commented 4 years ago

Try changing the name_label of "Windows Server 2019 (64-bit)" slightly and I think you can get it to work. IMO, this is a Citrix issue.

NAUbackup commented 4 years ago

The issue is that the opaque references are returned for all templates as well as VMs, hence you should not use the name of a template for a VM! This is what I would consider a restriction, and not a bug. Changing the name slightly will avoid this error. The same limitation exists in earlier versions of this code and using the older API calls provided with XenServer 7.X.

I will make sure this goes into the documentation. To see all template names, you can expand the list in XenCenter under the "View" menu at the top to show "Citrix Hypervisor Templates" so that you can avoid using them.

I am therefore closing this issue.