Bug 1308494 - libvirt can not start a VM with non-ACSII names: Invalid machine name (from systemd)
libvirt can not start a VM with non-ACSII names: Invalid machine name (from s...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
7.1
Unspecified Linux
urgent Severity high
: rc
: ---
Assigned To: Martin Kletzander
Virtualization Bugs
: Upstream, ZStream
Depends On: 1282846
Blocks: 1260131
  Show dependency treegraph
 
Reported: 2016-02-15 06:55 EST by Marcel Kolaja
Modified: 2016-04-26 09:55 EDT (History)
31 users (show)

See Also:
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 18:08:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Marcel Kolaja 2016-02-15 06:55:11 EST
This bug has been copied from bug #1282846 and has been proposed
to be backported to 7.2 z-stream (EUS).
Comment 11 Martin Kletzander 2016-02-26 10:30:12 EST
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
Comment 12 Martin Kletzander 2016-03-01 05:48:34 EST
The additional fix has been merged upstream as 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

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.
Comment 14 zhenfeng wang 2016-03-08 06:44:00 EST
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ī-∨м
Comment 15 zhenfeng wang 2016-03-08 07:01:43 EST
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.
Comment 16 Martin Kletzander 2016-03-08 08:16:54 EST
(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.
Comment 17 zhenfeng wang 2016-03-11 04:13:07 EST
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
Comment 19 errata-xmlrpc 2016-03-31 18:08:23 EDT
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

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