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
I wonder if this something related to systemd scope names, like https://bugzilla.redhat.com/show_bug.cgi?id=1033369
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 info: I can create an start a VM with "kīмсhī-∨м" name on F17 and F19.
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.
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?
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.
Any updates on this? We'd still like to have the ability to use VMs with unicode characters (as mentioned in Comment #5).
Created attachment 990633 [details] testcase The attached script reproduces this bug. I can reproduce it on Fedora 21 with libvirt-1.2.9.1-2.fc21.x86_64.
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
*** Bug 1191835 has been marked as a duplicate of this bug. ***
------- Comment From clnperez.com 2015-06-02 13:44 EDT------- On the Kimchi side, we've gone with the suggested workaround. Thanks.
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
libvirt-1.2.13.2-1.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-2c9678da8c
libvirt-1.2.13.2-1.fc22 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 From clnperez.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
libvirt-1.2.13.2-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Were you definitely testing with libvirt-1.2.13.2-1.fc22 ? it wasn't even in the stable repository yet
------- Comment From clnperez.com 2016-01-08 16:22 EDT------- (In reply to comment #19) > Were you definitely testing with libvirt-1.2.13.2-1.fc22 ? it wasn't even in > the stable repository yet Yes. I had enabled the testing repository. ------- Comment From clnperez.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 From clnperez.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 libvirt-1.2.13.2-1.fc22.x86_64 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
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
(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 v1.3.1-11-g020135d # 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
There's new patches upstream for this issue: https://www.redhat.com/archives/libvir-list/2016-February/msg00133.html
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 pkginfo libvirt-1.3.2-1.fc24_v1.3.1_292_gd46eb9e.x86_64 <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? STEP 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 STEPS 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'/> </channel> 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'/> </channel> 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
Hi Martain can you also help check the upper comment? thanks
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.
Fix proposed upstream: https://www.redhat.com/archives/libvir-list/2016-February/msg01369.html
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> Date: Fri Feb 26 09:15:55 2016 +0100 qemu: Shorten per-domain directory names
Reopening so we can track backporting this to stable fedora releases
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