Bug 1062943 - libvirt can not start a VM with non-ACSII chars name: Invalid machine name (from systemd)
Summary: libvirt can not start a VM with non-ACSII chars name: Invalid machine name (f...
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 24
Hardware: Unspecified
OS: Linux
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
: 1191835 (view as bug list)
Depends On:
Blocks: 1282846
TreeView+ depends on / blocked
Reported: 2014-02-09 03:39 UTC by Shaohe Feng
Modified: 2016-04-26 13:37 UTC (History)
17 users (show)

Fixed In Version: libvirt-1.3.2.fc22
Doc Type: Bug Fix
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:
: 1282846 (view as bug list)
Last Closed: 2016-03-17 20:34:38 UTC
Type: Bug

Attachments (Terms of Use)
testcase (418 bytes, text/x-python)
2015-02-11 20:47 UTC, Crístian Deives
no flags Details

Description Shaohe Feng 2014-02-09 03:39:39 UTC
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

Comment 1 Cole Robinson 2014-02-09 14:09:39 UTC
I wonder if this something related to systemd scope names, like https://bugzilla.redhat.com/show_bug.cgi?id=1033369

Comment 2 Shaohe Feng 2014-02-09 14:59:02 UTC
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).

Comment 3 Shaohe Feng 2014-02-09 15:01:20 UTC
Additional info:
I can create an start a VM with "kīмсhī-∨м" name on F17 and F19.

Comment 4 Cole Robinson 2014-02-09 16:09:15 UTC
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.

Comment 5 Shaohe Feng 2014-02-10 03:20:19 UTC
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?

Comment 6 Laine Stump 2014-02-10 09:58:10 UTC
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.

Comment 7 Christy Norman 2015-02-11 19:31:59 UTC
Any updates on this? We'd still like to have the ability to use VMs with unicode characters (as mentioned in Comment #5).

Comment 8 Crístian Deives 2015-02-11 20:47:08 UTC
Created attachment 990633 [details]

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

Comment 9 Cole Robinson 2015-04-02 17:53:12 UTC
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

Comment 10 Cole Robinson 2015-05-31 19:41:21 UTC
*** Bug 1191835 has been marked as a duplicate of this bug. ***

Comment 11 IBM Bug Proxy 2015-06-02 13:50:46 UTC
------- 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 12 Martin Kletzander 2015-11-26 14:38:52 UTC
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 13 Martin Kletzander 2015-11-27 16:06:39 UTC
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 14 Fedora Update System 2015-12-24 00:50:12 UTC
libvirt- has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-2c9678da8c

Comment 15 Fedora Update System 2015-12-30 20:56:21 UTC
libvirt- has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-2c9678da8c

Comment 16 IBM Bug Proxy 2016-01-04 18:10:26 UTC
------- Comment From clnperez@us.ibm.com 2016-01-04 18:14 EDT-------
I'm still seeing this.

I created the machine with Kimchi, and couldn't start it there, so I tried using virsh to make sure the error wasn't coming from Kimchi.

~> sudo virsh list --all | grep k???h?-??
-     k???h?-??               shut off
~> sudo virsh start k???h?-??
error: Failed to start domain k???h?-??
error: Invalid machine name

From the systems logs:
Jan 04 12:04:54 christy-toshiba libvirtd[7110]: Invalid machine name

Comment 17 Fedora Update System 2016-01-08 03:24:42 UTC
libvirt- has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Comment 18 Cole Robinson 2016-01-08 15:55:36 UTC
Were you definitely testing with libvirt- ? it wasn't even in the stable repository yet

Comment 19 IBM Bug Proxy 2016-01-08 16:20:24 UTC
------- Comment From clnperez@us.ibm.com 2016-01-08 16:22 EDT-------
(In reply to comment #19)
> Were you definitely testing with libvirt- ? it wasn't even in
> the stable repository yet

Yes. I had enabled the testing repository.

------- Comment From clnperez@us.ibm.com 2016-01-08 16:24 EDT-------
Well, let me double-check. That's not the version I have installed now and I don't think I downgraded after I tested.

Comment 20 IBM Bug Proxy 2016-01-08 18:40:55 UTC
------- Comment From clnperez@us.ibm.com 2016-01-08 18:43 EDT-------
Confirmed. (The other recreate had been done on another fedora 22 system I have.)

> rpm -qa | grep libvirt-1
i> sudo virsh list --all
Id    Name                           State
-     docker-15.10                   shut off
-     docker-ubuntu-14.04            shut off
-     k???h?-??               shut off

> sudo virsh start k???h?-??
error: Failed to start domain k???h?-??
error: Invalid machine name

Comment 21 Cole Robinson 2016-01-15 19:40:45 UTC
I'm curious if anyone can confirm this is still an issue on f23? wondering if it's some systemd difference on f22, or an incomplete backport

Comment 22 Fangge Jin 2016-01-21 10:23:33 UTC
(In reply to Cole Robinson from comment #21)
> I'm curious if anyone can confirm this is still an issue on f23? wondering
> if it's some systemd difference on f22, or an incomplete backport

I test on f23 using latest libvirt version, it still doesn't work
# git describe 

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

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

Comment 23 Cole Robinson 2016-02-02 20:43:48 UTC
There's new patches upstream for this issue:


Comment 24 zhenfeng wang 2016-02-18 08:18:00 UTC
Hi Cole
Currently, the guest could start successfully no matter we define a guest with non-ACSII chars name or the guest name-length was longer than 59-character, however, still have the following 2 issues, please help check it, thanks


<1>.The guest will start successfully while the guest name-length was longer than 59-character, but will fail to start while the name-length was longer than 65-character, is it expect result?

1.Define a guest which guest name-length is 66-character

# virsh list --all
 Id    Name                           State
 -     012345678901234567890123456789012345678901234567890123456789012345 shut off

2.Start the guest, the guest will fail to start with the following error
# virsh start 012345678901234567890123456789012345678901234567890123456789012345
error: Failed to start domain 012345678901234567890123456789012345678901234567890123456789012345
error: internal error: Monitor path /var/lib/libvirt/qemu/domain-012345678901234567890123456789012345678901234567890123456789012345/monitor.sock too big for destination


<2> The guest agent can't be used while the guest name length longer than 40-characters, this limite will block we use guest agent

1.Define a guest which guest name-length is 41-character and have guest agent configured in the guest's xml and guest inside
#virsh list --all
# virsh list --all
 Id    Name                           State
 -     01234567890123456789012345678901234567890 shut off

# virsh dumpxml 01234567890123456789012345678901234567890
   <channel type='unix'>
      <source mode='bind'/>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>

2.Start the guest, after guest start completely, check the guest agent state in both guest's xml and inside guest
# virsh start 01234567890123456789012345678901234567890
Domain 01234567890123456789012345678901234567890 started

#virsh dumpxml 01234567890123456789012345678901234567890
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-01234567890123456789012345678901234567890/org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>

login guest and check the guest agent status
guest# systemctl status qemu-guest-agent
● qemu-guest-agent.service - QEMU Guest Agent
   Loaded: loaded (/usr/lib/systemd/system/qemu-guest-agent.service; static; vendor preset: enabled)
   Active: active (running) since Thu 2016-02-18 16:02:07 CST; 1min 31s ago
 Main PID: 723 (qemu-ga)

3.Run a virsh command which depends on guest agent, will get the following error 
# virsh domtime 01234567890123456789012345678901234567890
error: Guest agent is not responding: QEMU guest agent is not available due to an error

check the log info in libvirtd.log
#cat /var/log/libvirt/libvirtd.log
2016-02-18 08:01:46.207+0000: 9691: info : libvirt version: 1.3.2, package: 1.fc24_v1.3.1_292_gd46eb9e (Unknown, 2016-02-18-07:03:58, localhost.localdomain)
2016-02-18 08:01:46.207+0000: 9691: info : hostname: localhost.localdomain
2016-02-18 08:01:46.207+0000: 9691: error : qemuAgentOpenUnix:206 : internal error: Agent path /var/lib/libvirt/qemu/channel/target/domain-01234567890123456789012345678901234567890/org.qemu.guest_agent.0 too big for destination
2016-02-18 08:01:46.207+0000: 9691: warning : qemuProcessReconnect:3489 : Cannot connect to QEMU guest agent for 01234567890123456789012345678901234567890
2016-02-18 08:02:08.021+0000: 9816: error : qemuAgentOpenUnix:206 : internal error: Agent path /var/lib/libvirt/qemu/channel/target/domain-01234567890123456789012345678901234567890/org.qemu.guest_agent.0 too big for destination
2016-02-18 08:05:00.213+0000: 9635: error : qemuDomainAgentAvailable:3594 : Guest agent is not responding: QEMU guest agent is not available due to an error

Comment 25 zhenfeng wang 2016-02-23 08:55:40 UTC
Hi Martain
can you also help check the upper comment? thanks

Comment 26 Martin Kletzander 2016-02-23 11:46:53 UTC
That seems like a problem and I know where it's coming from.  That one more thing we'll need to deal with, unfortunately.  I'll have a look at that later today.

Comment 27 Martin Kletzander 2016-02-26 15:30:56 UTC
Fix proposed upstream:


Comment 28 Martin Kletzander 2016-03-01 09:31:38 UTC
This should be fixed now in 1.3.2, very long names might have a problem, but the fix is in place and will be in the next release as well.  That is v1.3.2-1-ga89f05ba8df0:

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

    qemu: Shorten per-domain directory names

Comment 29 Cole Robinson 2016-03-01 15:04:37 UTC
Reopening so we can track backporting this to stable fedora releases

Comment 30 Cole Robinson 2016-03-17 20:34:38 UTC
Unfortunately the patches fixing the non-ASCII issue is pretty invasive, they are difficult to backport. So just closing this against F24 where these patches are already present

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