RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1282846 - libvirt can not start a VM with non-ACSII or long names: Invalid machine name (from systemd)
Summary: libvirt can not start a VM with non-ACSII or long names: Invalid machine name...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.1
Hardware: Unspecified
OS: Linux
urgent
high
Target Milestone: rc
: ---
Assignee: Martin Kletzander
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1062943 1285720
Blocks: 1203710 1260131 1291360 1308494
TreeView+ depends on / blocked
 
Reported: 2015-11-17 15:49 UTC by Dan Kenigsberg
Modified: 2019-10-10 10:30 UTC (History)
30 users (show)

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.
Clone Of: 1062943
: 1285720 1308494 (view as bug list)
Environment:
Last Closed: 2016-11-03 18:31:01 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1289363 0 high CLOSED 59-character name-length limitation when creating VMs 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHSA-2016:2577 0 normal SHIPPED_LIVE Moderate: libvirt security, bug fix, and enhancement update 2016-11-03 12:07:06 UTC

Internal Links: 1289363

Description Dan Kenigsberg 2015-11-17 15:49:30 UTC 
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) 1.1.3.2

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 0.0.0.0:0 -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-1.2.9.1-2.fc21.x86_64.

--- 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.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 15:57:20 UTC 
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 Berrangé 2015-11-18 16:13:57 UTC 
No, this is a bug in libvirt - it is failing to escape the machine name in virSystemdMakeMachineName
Comment 3 Martin Kletzander 2015-11-26 10:23:56 UTC 
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 14:38:56 UTC 
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
Comment 6 Martin Kletzander 2015-11-27 15:42:06 UTC 
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
Comment 7 zhenfeng wang 2015-12-09 05:36:37 UTC 
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
Comment 8 Martin Kletzander 2016-01-23 15:11:25 UTC 
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 12:51:33 UTC 
(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 20:08:32 UTC 
(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 20:14:33 UTC 
*** Bug 1289363 has been marked as a duplicate of this bug. ***
Comment 13 Martin Kletzander 2016-02-02 20:37:31 UTC 
Disregard comment #4, new fix has been posted upstream:


https://www.redhat.com/archives/libvir-list/2016-February/msg00133.html
Comment 15 Martin Kletzander 2016-02-05 15:18:21 UTC 
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
Comment 16 Martin Kletzander 2016-02-06 10:43:31 UTC 
Also needed:

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

    virSystemdGetMachineNameByPID: Initialize @reply
Comment 25 zhenfeng wang 2016-03-24 10:49:34 UTC 
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
Comment 26 zhenfeng wang 2016-03-24 10:51:24 UTC 
The upper steps verified with 
libvirt-1.3.2-1.el7.x86_64
qemu-kvm-rhev-2.5.0-2.el7.x86_64
Comment 28 errata-xmlrpc 2016-11-03 18:31:01 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.