Well, this is not clear whether it's a bug or not.  The only think to do is to remove the auto-generated channel source path and let libvirt generate a new one according to new domain name.

This is not a critical bug, so I'm moving it to rhel-7.3.  Workaround is to edit the xml manually and remove the path, libvirt will generate a new one.

Pavel

Upstream commit:

commit 3a33f3414f473d0396305fa405ce2940076bfc68
Author: Pavel Hrdina <phrdina>
Date:   Mon Nov 2 13:20:15 2015 +0100

    virt-clone: remove socket path for unix channel
    
    Libvirt automatically generates this path with a guest name used as
    directory.  The new conception is to have all sockets for one guest in
    it's own directory and in order to successfully clone a guest, we need
    to remove this path to regenerate it with new guest name.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1270696
    
    Signed-off-by: Pavel Hrdina <phrdina>

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

*** Bug 1339482 has been marked as a duplicate of this bug. ***

I can reproduce this bug with package:
virt-manager-1.2.1-8.el7.noarch

Steps are the same as description above.

Then try to verify with new build:
virt-manager-1.3.2-1.el7.noarch

Steps:
1.Ensure xen server could be access
2.Run virt-manager. Add a new connect to xen host by clicking "File->Add Connection", select "Xen" in Hypervisor, check the "Connect to remote host" and input the hostname, then click "Connect".
3.Create a new guest by clicking the "Create a new virtual machine" icon and select "Local install media(ISO or CDROM)" then click forward and select rhel7.2.iso, then keep all the settings default until finish.
4.Enter into installation interface and click option "Install Red Hat Enterprise Linux 7.2".

Results:
After step4 , black screen doesn't occur and the guest can be installed successfully.

I'm so sorry to paste a wrong verification steps on comment9. The correct reproduce steps is as follows.

I can reproduce this bug with package:
virt-manager-1.2.1-8.el7.noarch

Steps are the same as description above.

Then try to verify with new build:
virt-manager-1.3.2-1.el7.noarch

Steps:
1. Prepare a health guest(Install this guest via virt-manger by default setting)
#virsh dumpxml rhel6.6-testclone
...
<channel type='unix'>
<source mode='bind'/>
<target type='virtio' name='org.qemu.guest_agent.0'/>
<address type='virtio-serial' controller='0' bus='0' port='2'/>
</channel>
...

2. Use virt-clone to create a new guest:
#virt-clone -o rhel6.6-testclone --auto-clone
Allocating 'rhel6.6-testclone-clone.qcow2' | 20 GB 01:18
Clone 'rhel6.6-testclone-clone' created successfully.

3. Start new created guest 'rhel6.6-testclone-clone'.

Result:
The new cloned guest starts successfully.

According to the result above in the latest version of virt-manager, move this bug from ON_QA to VERIFIED.

My personal workaround: upgrade to virt-manager-* as of FC24 :-)

My personal solution was:

1.- In graphical enviroment,  I remove  "Channel qemu-ga" component on "Show virtual hardware details"
2.- Then, i cloned the VM
3.-run the new VM and thats all!

Clone VM starts sucesfully.

You can do it, in command line with virsh.

And if original vm started then vm's clone start without any problems...

My strange solution is to delete <channel>-section from clone's config:
1. virsh edit vm-clone
2. delete text from <channel type='unix'> to </channel>
3. virsh start vm-clone

It fixes the problem.

# rpm -q libvirt
libvirt-1.2.17-13.el7_2.5.x86_64
# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)

I reproduced the same problem using virt-clone

$ virt-install --os-type=linux --os-variant=rhel7 --network bridge:virbr0 --name vm01 --ram=1024 --vcpus=1 --disk path=/vm-images/rhel-guest-image-7.2-20160302.0.x86_64.qcow2 --graphics none --import
$ virt-clone --original vm01 --name vm02 --file /vm-images/vm02
Allocating 'vm02'                                                                             |  10 GB  00:00:05     

Clone 'vm02' created successfully
$ virsh start vm02
error: Failed to start domain vm02
error: internal error: process exited while connecting to monitor: 2016-10-21T14:31:43.057831Z qemu-kvm: -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-vm01/org.qemu.guest_agent.0,server,nowait: Failed to bind socket: No such file or directory
2016-10-21T14:31:43.057870Z qemu-kvm: -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-vm01/org.qemu.guest_agent.0,server,nowait: chardev: opening backend "socket" failed

As mentioned in the above notes, the fix is to edit the guest xml file and change the path.


$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.2 (Maipo)
$ uname -a
Linux kvm-host 3.10.0-327.36.2.el7.x86_64 #1 SMP Tue Sep 27 16:01:21 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -q libvirt
libvirt-1.2.17-13.el7_2.5.x86_64

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://rhn.redhat.com/errata/RHBA-2016-2269.html

*** Bug 1448791 has been marked as a duplicate of this bug. ***