Still one detail missing, it was found out in the Fedora BZ:

  https://bugzilla.redhat.com/show_bug.cgi?id=1062943#c24

The fix has been proposed upstream:

  https://www.redhat.com/archives/libvir-list/2016-February/msg01369.html

The additional fix has been merged upstream as v1.3.2-1-ga89f05ba8df0:

commit a89f05ba8df095875f5ec8a9065a585af63a010b
Author: Martin Kletzander <mkletzan>
Date:   Fri Feb 26 09:15:55 2016 +0100

    qemu: Shorten per-domain directory names

However, that will not be back-ported due to its invasiveness/usefulness ratio.  Hence this BZ can be back moved to POST as it will deal with the initial problem and the second one will be reopened.

Verify this bug with libvirt-1.2.17-13.el7_2.4
steps
1.Prepare a guest with non-ACSII name
#virsh dumpxml 
   Id        Name                           State
----------------------------------------------------
 -     kīмсhīkīмсhīkīмсhī-∨м              shut off

# virsh start  kīмсhīkīмсhīkīмсhī-∨м
Domain kīмсhīkīмсhīkīмсhī-∨м started
#virsh dumpxml  kīмсhīkīмсhīkīмсhī-∨м
--

    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-kīмсhīkīмсhīkīмсhī-∨м/org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/>
      <alias name='channel1'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
--
    <graphics type='vnc' socket='/var/lib/libvirt/qemu/domain-kīмсhīkīмсhīkīмсhī-∨м/vnc.sock'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>

2.Check the guest agent works well
# virsh domtime kīмсhīkīмсhīkīмсhī-∨м --pretty
Time: 2016-03-08 11:02:56

# virsh domifaddr kīмсhīkīмсhīkīмсhī-∨м --source agent
 Name       MAC address          Protocol     Address
-------------------------------------------------------------------------------
 lo         00:00:00:00:00:00    ipv4         127.0.0.1/8
 -          -                    ipv6         ::1/128
 ens3       52:54:00:62:9f:bb    ipv4         192.168.122.190/24
 -          -                    ipv6         fe80::5054:ff:fe62:9fbb/64
 virbr0     52:54:00:dc:98:bf    ipv4         192.168.124.1/24
 virbr0-nic 52:54:00:dc:98:bf    N/A          N/A

3.connect the guest with the vnc viewer, could connect successfully
# virt-viewer kīмсhīkīмсhīkīмсhī-∨м

4.Do managedsave/restore with the guest, it works well
# virsh managedsave kīмсhīkīмсhīkīмсhī-∨м

Domain kīмсhīkīмсhīkīмсhī-∨м state saved by libvirt

# virsh start kīмсhīkīмсhīkīмсhī-∨м
Domain kīмсhīkīмсhīkīмсhī-∨м started

Scenario 2
This issue only happen in rhel7 and works well in rhel6, so cover the cross migration scenario 
1.Prepare a cross migration env, source machine was rhel6.8, target was rhel7.2.z
2.Prepare a guest which named kīмсhīkīмсhīkīмсhī-∨м in the source host

3.Migrate the guest from the source to the target ,could migrate successfully
# virsh migrate --live kīмсhīkīмсhīkīмсhī-∨м qemu+ssh://$target_ip/system --verbose 
Migration: [100 %]

4check the guest in the target, both the guest agent and vnc sokcet works well
# virsh list --all
 Id    Name                           State
----------------------------------------------------
 26    kīмсhīkīмсhīkīмсhī-∨м running

# virsh domtime kīмсhīkīмсhīkīмсhī-∨м --pretty
Time: 2016-03-08 11:35:00
# virt-viewer kīмсhīkīмсhīkīмсhī-∨м

Hi Martin
In comment12, you said that "this bz deal with the initial problem and the second one will be reopened."  Did you mean this bz only fix the non-ACSII issue and the name length limitation issue will be tracked by the seperate bz?

I also try the name length issue with the patch apply in this bz, found the guest will fail to start while the name length was longer than 65 character(previously, the name length limitation was 59 character, refer bz 1289363), BTW, the name length limitation issue didn't exsit in rhel6, only for rhel7, so this issue may affect the cross migration from rhel6 to rhel7 with the longer guest name.

(In reply to zhenfeng wang from comment #15)
Yes, this deals only with non-ASCII characters in the name.  As a consequence the limitation for long names has changed, but not to a specific number (it all depends on configuration etc.).  And the fix for unlimited name length is upstream, but is very intrusive to back-port since we haven't found this problem earlier than in 7.2.  Also there will be limitation when migrating from rhel6 but only for certain versions, some of them had length limitation as well until that was fixed.

Thanks Martin's response, add the following additional test scenarios
scenario 1
1.Prepare a guest with non-ACSII name and panic device configured
#virsh dumpxml kīмсhīkīмсhīkīмсhī-∨м
--
  <on_crash>coredump-restart</on_crash
--
<panic/>

2.Login guest and crash the guest, could get the dump file in the host and analysis it successfully
guest# echo c >/proc/sysrq-trigger
host# ll /var/lib/libvirt/qemu/dump/
-rw-------. 1 root root 1208100888 Mar 11 13:37 kīмсhīkīмсhīkīмсhī-∨м-2016-03-11-13:37:48

# crash /usr//lib/debug/lib/modules/3.10.0-362.el7.x86_64/vmlinux kīмсhīkīмсhīkīмсhī-∨м-2016-03-11-13\:37\:48

scenario2 

Try other special guest name with the upper all test scenarios, such as following, it could get the same result 
# virsh list
 Id    Name                           State
----------------------------------------------------
 5     1#2%+3_*Bb\                    running


According to the upper steps, mark this bug verifed

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-0555.html