Bug 1282846 - libvirt can not start a VM with non-ACSII or long names: Invalid machine name (from systemd)
libvirt can not start a VM with non-ACSII or long names: Invalid machine name...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
Unspecified Linux
urgent Severity high
: rc
: ---
Assigned To: Martin Kletzander
Virtualization Bugs
: Upstream, ZStream
Depends On: 1062943 1285720
Blocks: 1203710 1260131 1291360 1308494
  Show dependency treegraph
Reported: 2015-11-17 10:49 EST by Dan Kenigsberg
Modified: 2016-11-03 14:31 EDT (History)
30 users (show)

See Also:
Fixed In Version: libvirt-1.3.2-1.el7
Doc Type: Enhancement
Doc Text:
In a prior update, systemd introduced strict requirements for machine names. As an unintended effect, this caused starting virtual domains with non-ASCII characters in their name or with a long name to fail. With this update, libvirt introduces an escaping mechanism that allows such virtual machines to start as expected.
Story Points: ---
Clone Of: 1062943
: 1285720 1308494 (view as bug list)
Last Closed: 2016-11-03 14:31:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dan Kenigsberg 2015-11-17 10:49:30 EST
Apparently this bug has propagated to el7 and now affects RHEV-3.5 and 3.6 when deployed over RHEL-7. I assume it would block live migration of VMs with non-ascii names from el6 to el7 (which is an important feature of RHEV-3.5).

+++ This bug was initially created as a clone of Bug #1062943 +++

Description of problem:
libvirt can define and undefine a VM with a non-ACSII char name.
but it can not start this VM.

Version-Release number of selected component (if applicable):
$ libvirtd --version
libvirtd (libvirt)

How reproducible:
create a VM with with a non-ACSII chars name, such as "kīмсhī-∨м" and start this VM.

Steps to Reproduce:
1. define a VM with a non-ACSII chars name. we can define it by virsh.
2. start this VM.
3. undefine this VM.

Actual results:
failed to start VM for invalid argument.

Expected results:
it should start the VM successfully.

Additional info:

the libvirtd.log report
2014-02-09 03:05:35.001+0000: 11376: error : virDBusCallMethod:1173 : Invalid argument

/var/log/libvirt/qemu/kīмсhī-∨м.log reports
2014-02-08 15:31:03.391+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -name kīмсhī-∨м -S -machine pc-i440fx-1.6,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 6e8233dd-0c00-4c78-b4a6-bffcd1ced26c -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/kīмсhī-∨м.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=25,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:00:3f:27:31,bus=pci.0,addr=0x3 -vnc -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
2014-02-08 15:31:03.398+0000libvirt:  error : libvirtd quit during handshake: Input/output error

--- Additional comment from Cole Robinson on 2014-02-09 16:09:39 IST ---

I wonder if this something related to systemd scope names, like https://bugzilla.redhat.com/show_bug.cgi?id=1033369

--- Additional comment from Shaohe Feng on 2014-02-09 16:59:02 IST ---

The name of the VM I create is "kīмсhī-∨м", less than 60 characters.

but the "Invalid argument" error also comes from dbus api call (virDBusCallMethod).

--- Additional comment from Shaohe Feng on 2014-02-09 17:01:20 IST ---

Additional info:
I can create an start a VM with "kīмсhī-∨м" name on F17 and F19.

--- Additional comment from Cole Robinson on 2014-02-09 18:09:15 IST ---

Please re-read my comment: I was suggesting that the non-ascii limitation may be another thing introduced by systemd scope usage, which is new in f20.

--- Additional comment from Shaohe Feng on 2014-02-10 05:20:19 IST ---

I'm not sure it is another limit on scope names. Any doc about the systemd scope usage?
If it is, it is not good to our project kimchi.https://github.com/kimchi-project/kimchi/

international is an important feature of kimchi.
kimchi do want different users from different country can manage their VMs by their local language.

If f20 insists on this limit, can kimchi work aroud it?

--- Additional comment from Laine Stump on 2014-02-10 11:58:10 IST ---

I don't think there was any suggestion of F20, or anything else, insisting on this limitation; Cole was only making a suggestion of a possible root cause of the problem. Once we've determined the root cause, *then* we can figure out how to fix it.

--- Additional comment from  on 2015-02-11 21:31:59 IST ---

Any updates on this? We'd still like to have the ability to use VMs with unicode characters (as mentioned in Comment #5).

--- Additional comment from Crístian Deives on 2015-02-11 22:47:08 IST ---

The attached script reproduces this bug. I can reproduce it on Fedora 21 with libvirt-

--- Additional comment from Cole Robinson on 2015-04-02 20:53:12 IDT ---

Still relevant on F22. I wonder if we can switch to using UUID scope names? Not sure if that's within libvirt's control or if it's dictated by systemd APIs

If this is affecting kimchi I'd recommend you rework the app to use standard ascii for VM names, but keep unicode and pretty text as part of the <title> attribute which doesn't have any restrictions. It's what gnome-boxes does for example

--- Additional comment from Cole Robinson on 2015-05-31 22:41:21 IDT ---

--- Additional comment from IBM Bug Proxy on 2015-06-02 16:50:46 IDT ---

------- Comment From clnperez@us.ibm.com 2015-06-02 13:44 EDT-------
On the Kimchi side, we've gone with the suggested workaround. Thanks.
Comment 1 Martin Kletzander 2015-11-18 10:57:20 EST
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.
Comment 2 Daniel Berrange 2015-11-18 11:13:57 EST
No, this is a bug in libvirt - it is failing to escape the machine name in virSystemdMakeMachineName
Comment 3 Martin Kletzander 2015-11-26 05:23:56 EST
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.
Comment 4 Martin Kletzander 2015-11-26 09:38:56 EST
Fixed upstream with v1.2.21-144-ge24eda48cfae:

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

    systemd: Escape machine name for machined
Comment 6 Martin Kletzander 2015-11-27 10:42:06 EST
One more fix needed is v1.2.21-164-g0e0149ce91d8:

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

    systemd: Escape only needed characters for machined
Comment 7 zhenfeng wang 2015-12-09 00:36:37 EST
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'>

#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
Comment 8 Martin Kletzander 2016-01-23 10:11:25 EST
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.
Comment 9 Michal Skrivanek 2016-01-25 07:51:33 EST
(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?
Comment 11 Martin Kletzander 2016-02-02 15:08:32 EST
(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.
Comment 12 Martin Kletzander 2016-02-02 15:14:33 EST
*** Bug 1289363 has been marked as a duplicate of this bug. ***
Comment 13 Martin Kletzander 2016-02-02 15:37:31 EST
Disregard comment #4, new fix has been posted upstream:

Comment 15 Martin Kletzander 2016-02-05 10:18:21 EST
Fixed upstream by v1.3.1-125-gc3bd0019c0e3:

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

    systemd: Modernize machine naming
Comment 16 Martin Kletzander 2016-02-06 05:43:31 EST
Also needed:

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

    virSystemdGetMachineNameByPID: Initialize @reply
Comment 25 zhenfeng wang 2016-03-24 06:49:34 EDT
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'/>
    <graphics type='vnc' socket='/var/lib/libvirt/qemu/domain-kīмсhīkīмсhīkīмсhī-∨м/vnc.sock'>
      <listen type='address' address=''/>

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
 -          -                    ipv6         ::1/128
 ens3       52:54:00:62:9f:bb    ipv4
 -          -                    ipv6         fe80::5054:ff:fe62:9fbb/64
 virbr0     52:54:00:dc:98:bf    ipv4
 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ī-∨м

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

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
Comment 26 zhenfeng wang 2016-03-24 06:51:24 EDT
The upper steps verified with 
Comment 28 errata-xmlrpc 2016-11-03 14:31:01 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.