Fix qvm-backup-restore --rename-conflicing handling

[marmarek]

[user@dom0 appvms]$ qvm-backup-restore --skip-dom0-home --rename-conflicting
-e /media/secdrv/qubes-backup/qubes-2016-05-01T125532 anon-whonix
Please enter the pass phrase to decrypt/verify the backup:
Checking backup content...
Extracting data: 1.0 MiB to restore

The following VMs are included in the backup:

-------------+------+------------+-------+-------------+-------+
name | type | template | updbl | netvm | label |
-------------+------+------------+-------+-------------+-------+
anon-whonix | App | whonix-ws1 | | sys-whonix1 | red |

The above VMs will be copied and added to your system.
Exisiting VMs will not be removed.
Do you want to proceed? [y/N] y
Extracting data: 491.6 MiB to restore
-> Restoring QubesAppVm anon-whonix...
ERROR: VM root image file doesn't exist:
/var/lib/qubes/appvms/anon-whonix/root.img
*** Skipping VM: anon-whonix
-> Completed with errors!

Really strange - there shouldn't be any root.img expected. That should
be part of template (which you already have). But, I see the template
name is changed to whonix-ws1, which looks like an effect of
--rename-conflicting. If you've already removed anon-whonix, skip
--rename-conflicting option.

????? why is it complaining about that file not being there, it should
restore it from the backup! Running the same command without
"--rename-conflicting" resolves the restore without any problems, but I
truly don't understand why.

Ah, you've already done so.

Could it be that "--rename-conflicting" is causing numerous unforeseen
side-effects?

It looks so...
The one case I see wrong here is usage of --rename-conflicting to
restore a single VM, where it's template exists in both backup and
target system. Then template name is modified by --rename-conflicting,
even if that template isn't going to be restored.