Bug 1282846

This works perfectly fine without systemd, so I believe it must be a limitation of systemd/machined or anything related to the machine cgroup creation.  So I'm re-assigning this to systemd for futher triage.

No, this is a bug in libvirt - it is failing to escape the machine name in virSystemdMakeMachineName

I managed to fix this fact (intentionally not saying bug, because why couldn't we talk in utf-8 in 21st century) in libvirt, but it still didn't work.  After discussion with systemd engineers, there's also bug in machined, so I'm cloning this BZ for systemd to make sure both issues are fixed.

Fixed upstream with v1.2.21-144-ge24eda48cfae:

commit e24eda48cfae84a9003456b68eaf753a26123639
Author: Martin Kletzander <mkletzan>
Date:   Tue Nov 24 15:56:12 2015 +0100

    systemd: Escape machine name for machined

One more fix needed is v1.2.21-164-g0e0149ce91d8:

commit 0e0149ce91d84f40b98acf4c4bb0da6e29b9c15c
Author: Martin Kletzander <mkletzan>
Date:   Fri Nov 27 14:24:38 2015 +0100

    systemd: Escape only needed characters for machined

could reproduce this issue with libvirt-1.2.17-13.el7_2.2.x86_64

1.Prepare a vm with non-ACSII chars name
#cat vm.xml
<domain type='kvm'>
  <name>"kīмсhī-∨м</name>
--

#virsh define vm.xml
# virsh list --all
 Id    Name                           State
----------------------------------------------------
 -     kīмсhī-∨м               shut off

2.Start the vm, but the vm will fail to start

# virsh start kīмсhī-∨м 
error: Failed to start domain kīмсhī-∨м
error: Invalid machine name

check the vm's log, got the following error info
#cat /var/log/libvirt/qemu/kīмсhī-∨м.log
--
libvirt:  error : libvirtd quit during handshake: Input/output error

check the libvirtd's log, got the following info
--
2015-12-09 05:08:56.243+0000: 1665: info : virDBusCall:1554 : DBUS_METHOD_ERROR: 'org.freedesktop.machine1.Manager.CreateMachineWithNetwork' on '/org/freedesktop/machine1' at 'org.freedesktop.machine1' error org.freedesktop.DBus.Error.InvalidArgs: Invalid machine name
2015-12-09 05:08:56.243+0000: 1665: error : virSystemdCreateMachine:289 : Invalid machine name

We're still waiting for a discussion in systemd as to how to handle this because the design is still not clear yet.  We're trying to move on as soon as possible.

(In reply to Martin Kletzander from comment #8)
> We're still waiting for a discussion in systemd as to how to handle this
> because the design is still not clear yet.  We're trying to move on as soon
> as possible.

so, since that bug was just closed as won'tfix...why exactly we need systemd for that in libvirt? Can it be removed from libvirt? Can libvirt work around that stupid limitation?

(In reply to Michal Skrivanek from comment #9)
Well, that is what I've done, but that was a last resort.  We needed the systemd bug to be fixed, even by documentation update.  We couldn't do that blindly before.  I'll update this BZ with new info later today.

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

Disregard comment #4, new fix has been posted upstream:


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

Fixed upstream by v1.3.1-125-gc3bd0019c0e3:

commit c3bd0019c0e3f080dbf0d4bd08245ffb2daa2765
Author: Martin Kletzander <mkletzan>
Date:   Mon Feb 1 16:50:54 2016 +0100

    systemd: Modernize machine naming

Also needed:

commit a3b168d01a6254a5972d4eda87d7cbc3d9cdb3ef
Author: Michal Privoznik <mprivozn>
Date:   Fri Feb 5 17:17:45 2016 +0100

    virSystemdGetMachineNameByPID: Initialize @reply

Scenario1
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

5.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/>

6.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

The upper steps verified with 
libvirt-1.3.2-1.el7.x86_64
qemu-kvm-rhev-2.5.0-2.el7.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/RHSA-2016-2577.html