Red Hat Bugzilla – Bug 1282846
libvirt can not start a VM with non-ACSII or long names: Invalid machine name (from systemd)
Last modified: 2016-11-03 14:31:01 EDT
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@us.ibm.com 2015-06-02 13:44 EDT------- On the Kimchi side, we've gone with the suggested workaround. Thanks.
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@redhat.com> 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@redhat.com> 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@redhat.com> Date: Mon Feb 1 16:50:54 2016 +0100 systemd: Modernize machine naming
Also needed: commit a3b168d01a6254a5972d4eda87d7cbc3d9cdb3ef Author: Michal Privoznik <mprivozn@redhat.com> 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