I hit an error similar to this with the UEFI rename patches but was fixed before the release. Basically trying to do a rename if nvram pool didn't exist would fail the first time, but every subsequent time would succeed. See the commit message below for an explanation, maybe this error is something similar:

commit f61e586b7703d8cade5299d6c571e7a31b6dfab7
Author: Cole Robinson <crobinso>
Date:   Wed Mar 8 14:20:41 2017 -0500

    domain: rename: Fix when nvram pool is newly created
    
    We don't have any way at the momemnt to synchronously update cached
    object lists. So if old_nvram will create a pool for the nvram dir
    (/var/lib/libvirt/qemu/nvram), new_nvram won't see that new object
    in our cache, will attempt to create it itself, and raise an error.
    Next attempts succeed though.
    
    We can avoid this by not even setting new_nvram.path, that step was
    redundant anyways since we are setting a vol_install right afterwards.
    This way, new_nvram is getting a reference to the parent_pool object
    via the vol_install, so it doesn't even check the pool object cache.

Upstream commit:

commit 168651188674f35ce4afd8b3c0bac1a6be2317c0
Author: Pavel Hrdina <phrdina>
Date:   Fri May 19 14:26:49 2017 +0200

    virtManager.connection: introduce cb_add_new_pool

Try to verify this bug with new build:
virt-manager-1.4.1-5.el7.noarch
libvirt-3.2.0-6.virtcov.el7.x86_64
qemu-kvm-rhev-2.9.0-6.el7.x86_64

Steps:
1. Prepare a uefi guest on virt-manager with configuration:
# virsh dumpxml rhel7.24ovmf
  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.4.0'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/rhel7.24ovmf_VARS.fd</nvram>
    <boot dev='hd'/>
  </os>
...
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/rhel7.24ovmf.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
    </disk>

2. No pool "nvram" exists.
# virsh pool-list --all  |grep nvram

3.Launch virt-manager ->select guest->right click->Clone-->"Clone virtual machine" pop up-->click "Clone" button.
New guest name: rhel7.24ovmf-clone

4. After clone process finished, check:
4.1 Check new guest xml file configuration for nvram.
# virsh dumpxml rhel7.24ovmf-clone
...
  <os>
    <type arch='x86_64' machine='pc-q35-rhel7.4.0'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
    <nvram>/var/lib/libvirt/qemu/nvram/rhel7.24ovmf-clone_VARS.fd</nvram>
    <boot dev='hd'/>
  </os>
..

Result: 
New nvram file generated while cloning: rhel7.24ovmf-clone_VARS.fd

4.2 Start new cloned guest: rhel7.24ovmf-clone
Result: 
Guest starts successfully.

4.3 Check new dir-pool "nvram" newly created.
# virsh pool-list --all |grep nvram
 nvram                active     yes       


# virsh pool-dumpxml nvram
<pool type='dir'>
  <name>nvram</name>
  <uuid>dd6a50eb-f112-4018-892a-12b5305d2d83</uuid>
  <capacity unit='bytes'>268304384000</capacity>
  <allocation unit='bytes'>41883357184</allocation>
  <available unit='bytes'>226421026816</available>
  <source>
  </source>
  <target>
    <path>/var/lib/libvirt/qemu/nvram</path>
    <permissions>
      <mode>0755</mode>
      <owner>107</owner>
      <group>107</group>
      <label>system_u:object_r:qemu_var_run_t:s0</label>
    </permissions>
  </target>
</pool>


# virsh vol-list --pool nvram
 Name                 Path                                    
------------------------------------------------------------------------------
 rhel7.24ovmf-clone_VARS.fd /var/lib/libvirt/qemu/nvram/rhel7.24ovmf-clone_VARS.fd
 rhel7.24ovmf_VARS.fd /var/lib/libvirt/qemu/nvram/rhel7.24ovmf_VARS.fd


5. Delete new cloned guest: rhel7.24ovmf-clone, then refresh pool "nvram".
Result: 
Guest deletes successfully, and volume "/var/lib/libvirt/qemu/nvram/rhel7.3-uefi-clone_VARS.fd" deleted together.


6. Start original guest "rhel7.24ovmf" again.
Result: 
Guest "rhel7.24ovmf" successfully.

7. Stop original guest "rhel7.3-uefi", delete vram file "/var/lib/libvirt/qemu/nvram/rhel7.3-uefi_VARS.fd" manually, then start again.
 # virsh vol-list --pool nvram
 Name                 Path                                    
------------------------------------------------------------------------------

Result: 
I. Guest starts successfully.
II. New file "/var/lib/libvirt/qemu/nvram/rhel7.3-uefi_VARS.fd" generated while guest starting.

# virsh vol-list --pool nvram
 Name                 Path                                    
------------------------------------------------------------------------------
 rhel7.3-uefi_VARS.fd /var/lib/libvirt/qemu/nvram/rhel7.3-uefi_VARS.fd

8. Stop original guest "rhel7.24ovmf", then stop&delete pool "nvram", clone again.

Result:

a. Clone operation started without error and new guest can cloned successfully.
b. New pool 'nvram' will generate automatically.
c. Both original and new guest can start successfully.

So move this bug from ON_QA to VERIFIED.

The fix for this causes some issues. I've opened a separate bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1472894

I think we should revert this patch and fix this issue in another way.

I can easily reproduce the issue mentioned here by applying this patch:

diff --git a/virtManager/connection.py b/virtManager/connection.py
index 04a084c6..c2075a7b 100644
--- a/virtManager/connection.py
+++ b/virtManager/connection.py
@@ -287,10 +287,12 @@ class vmmConnection(vmmGObject):
         self._backend.cb_fetch_all_vols = fetch_all_vols
 
         def add_new_pool(obj, key):
+            return
             self._new_object_cb(vmmStoragePool(self, obj, key), False, True)
         self._backend.cb_add_new_pool = add_new_pool
 
         def clear_cache(pools=False):
+            return
             if not pools:
                 return
 

* Remove and undefine the 'nvram' pool
* start virt-manager
* clone a UEFI guest
* will fail with RuntimeError: Could not define storage pool: operation failed: Storage source conflict with pool: 'nvram'

However we can side step this issue with the following patch:

diff --git a/virtManager/clone.py b/virtManager/clone.py
index 4728d326..8b8ce60d 100644
--- a/virtManager/clone.py
+++ b/virtManager/clone.py
@@ -852,7 +852,6 @@ class vmmCloneVM(vmmGObjectUI):
                 if poolname not in refresh_pools:
                     refresh_pools.append(poolname)
 
-            self.clone_design.setup()
             self.clone_design.start_duplicate(meter)
 
             for poolname in refresh_pools:

.setup() just redoes some of the bits we already ran in the validate() function which runs right before this, so it's redundant AFAICT. Removing this setup() call avoids the issue here

That cloner change is upstream now:

commit d3074141c8b9186c7881d4e61ce6795b935ec08b
Author: Cole Robinson <crobinso>
Date:   Thu Jul 20 17:18:14 2017 -0400

    cloner: Remove redundant setup() method
    
    The functional callers use the individual setup methods, let's drop the
    helper function and adjust the test suite

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2072