Bug 1308494
Summary: | libvirt can not start a VM with non-ACSII names: Invalid machine name (from systemd) | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Marcel Kolaja <mkolaja> |
Component: | libvirt | Assignee: | Martin Kletzander <mkletzan> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | high | Docs Contact: | |
Priority: | urgent | ||
Version: | 7.1 | CC: | asanders, berrange, bugproxy, clalancette, cristiandeives, danken, dyuan, extras-qa, harald, itamar, jdenemar, jforbes, jherrman, jkurik, jsuchane, lagarcia, laine, libvirt-maint, mgoldboi, michal.skrivanek, mkalinin, mkletzan, mkolaja, mzamazal, rbalakri, shaohef, snagar, systemd-maint-list, veillard, yafu, zhwang |
Target Milestone: | rc | Keywords: | Upstream, ZStream |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-1.2.17-13.el7_2.4 | 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: | 1282846 | Environment: | |
Last Closed: | 2016-03-31 22:08:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1282846 | ||
Bug Blocks: | 1260131 |
Description
Marcel Kolaja
2016-02-15 11:55:11 UTC
Still one detail missing, it was found out in the Fedora BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1062943#c24 The fix has been proposed upstream: https://www.redhat.com/archives/libvir-list/2016-February/msg01369.html The additional fix has been merged upstream as 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 However, that will not be back-ported due to its invasiveness/usefulness ratio. Hence this BZ can be back moved to POST as it will deal with the initial problem and the second one will be reopened. Verify this bug with libvirt-1.2.17-13.el7_2.4 steps 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 Scenario 2 This issue only happen in rhel7 and works well in rhel6, so cover the cross migration scenario 1.Prepare a cross migration env, source machine was rhel6.8, target was rhel7.2.z 2.Prepare a guest which named kīмсhīkīмсhīkīмсhī-∨м in the source host 3.Migrate the guest from the source to the target ,could migrate successfully # virsh migrate --live kīмсhīkīмсhīkīмсhī-∨м qemu+ssh://$target_ip/system --verbose Migration: [100 %] 4check the guest in the target, both the guest agent and vnc sokcet works well # virsh list --all Id Name State ---------------------------------------------------- 26 kīмсhīkīмсhīkīмсhī-∨м running # virsh domtime kīмсhīkīмсhīkīмсhī-∨м --pretty Time: 2016-03-08 11:35:00 # virt-viewer kīмсhīkīмсhīkīмсhī-∨м Hi Martin In comment12, you said that "this bz deal with the initial problem and the second one will be reopened." Did you mean this bz only fix the non-ACSII issue and the name length limitation issue will be tracked by the seperate bz? I also try the name length issue with the patch apply in this bz, found the guest will fail to start while the name length was longer than 65 character(previously, the name length limitation was 59 character, refer bz 1289363), BTW, the name length limitation issue didn't exsit in rhel6, only for rhel7, so this issue may affect the cross migration from rhel6 to rhel7 with the longer guest name. (In reply to zhenfeng wang from comment #15) Yes, this deals only with non-ASCII characters in the name. As a consequence the limitation for long names has changed, but not to a specific number (it all depends on configuration etc.). And the fix for unlimited name length is upstream, but is very intrusive to back-port since we haven't found this problem earlier than in 7.2. Also there will be limitation when migrating from rhel6 but only for certain versions, some of them had length limitation as well until that was fixed. Thanks Martin's response, add the following additional test scenarios scenario 1 1.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/> 2.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 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/RHBA-2016-0555.html |