Bug 1790409

Summary: Provisioning of VM fails with "ERROR (cli:257) Invalid machine name"
Product: [Fedora] Fedora Reporter: Radek Vykydal <rvykydal>
Component: libvirtAssignee: Ján Tomko <jtomko>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 32CC: agedosier, berrange, clalancette, crobinso, itamar, jforbes, jtomko, laine, libvirt-maint, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-05-27 21:39:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
virt-install.log.1 from /root/.cache/virt-manager/
none
virt-install.log from /root/.cache/virt-manager/ none

Description Radek Vykydal 2020-01-13 10:27:22 UTC 
Created attachment 1651807 [details]
virt-install.log.1 from /root/.cache/virt-manager/

Description of problem:

Provisioning of virtual machines in Anaconda nightly kickstart tests (nested virtualization in OpenStack) sometimes (~10/180 cases) fails with

ERROR (cli:257) Invalid machine name

Version-Release number of selected component (if applicable):

Updated Fedora-Cloud-Base-30 image
libivrt-daemon-5.1.0-9

How reproducible:

Sometimes

Steps to Reproduce:
1. See the attached logs (virt-install.log) for virt-install command causing the fail:

[Fri, 10 Jan 2020 14:09:57 virt-install 31418] DEBUG (cli:203) Launched with command line: /usr/share/virt-manager/virt-install -n kstest-network-device-default-httpks_(c9eed63e-981e-48ec-acdc-56b3f8c5f678) -r 2048 --noautoconsole --vcpus 1 --rng /dev/random --noreboot --graphics vnc --disk path=/var/tmp/kstest-network-device-default-httpks.lshs63b_/disk-a.img,cache=unsafe,bus=sata --disk path=/var/tmp/kstest-network-device-default-httpks.lshs63b_/boot.kstest.iso,device=cdrom,readonly=on,shareable=on --extra-args  debug=1 inst.debug text rd.shell=0 rd.emergency=poweroff ip=enp1s0:dhcp inst.ks=http://10.0.137.173:40001/ks.cfg inst.kernel.hung_task_timeout_secs=1200 stage2=hd:CDLABEL=Fedora-E-dvd-x86_64-rawh --location /var/tmp/kstest-network-device-default-httpks.lshs63b_/boot.kstest.iso,kernel=isolinux/vmlinuz,initrd=isolinux/initrd.img --channel tcp,host=127.0.0.1:40163,mode=connect,target_type=virtio,name=org.fedoraproject.anaconda.log.0

2.
3.

Actual results:

Traceback:

[Fri, 10 Jan 2020 14:09:58 virt-install 31418] DEBUG (cli:256)   File "/usr/share/virt-manager/virt-install", line 964, in <module>
    sys.exit(main())
  File "/usr/share/virt-manager/virt-install", line 958, in main
    start_install(guest, installer, options)
  File "/usr/share/virt-manager/virt-install", line 635, in start_install
    fail(e, do_exit=False)
  File "/usr/share/virt-manager/virtinst/cli.py", line 256, in fail
    logging.debug("".join(traceback.format_stack()))

[Fri, 10 Jan 2020 14:09:58 virt-install 31418] ERROR (cli:257) Invalid machine name
[Fri, 10 Jan 2020 14:09:58 virt-install 31418] DEBUG (cli:259).
Traceback (most recent call last):
  File "/usr/share/virt-manager/virt-install", line 608, in start_install
    transient=options.transient)
  File "/usr/share/virt-manager/virtinst/installer.py", line 415, in start_install
    doboot, transient)
  File "/usr/share/virt-manager/virtinst/installer.py", line 358, in _create_guest
    domain = self.conn.createXML(install_xml or final_xml, 0)
  File "/usr/lib64/python3.7/site-packages/libvirt.py", line 3743, in createXML
    if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirt.libvirtError: Invalid machine name
Fri, 10 Jan 2020 14:09:58 virt-install 31418] DEBUG (cli:270) Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
  virsh --connect qemu:///system start kstest-network-device-default-httpks_(c9eed63e-981e-48ec-acdc-56b3f8c5f678)
otherwise, please restart your installation.


Expected results:


Additional info:

We don't hit this issue of updates "Fedora 29" cloud image (libvirt-daemon-4.7.0-5).

We were thinking it might be realated to length of the name, but for example a longer name 
"kstest-geolocation-off-by-default-with-ks_(d2a2444d-0e15-47e5-be08-56829d558294)" 
succeeds (see virt-install.log.1 attached in the next comment).
Comment 1 Radek Vykydal 2020-01-13 10:35:07 UTC 
Created attachment 1651812 [details]
virt-install.log from /root/.cache/virt-manager/

Attaching the other log - the references to the log names in the Description are correct, but unlike promised in the Description, virt-install.log is attached in this comment while virt-install.log.1 is attached in the Description.
Comment 2 Ján Tomko 2020-01-13 12:00:37 UTC 
Interesting - it seems systemd does not accept machine names ending with a hyphen.

(This happens because the maximum machine name length is 64 characters so libvirt has to truncate it.)
Comment 3 Ján Tomko 2020-01-14 07:35:49 UTC 
Upstream patches removing the hyphens:
https://www.redhat.com/archives/libvir-list/2020-January/msg00623.html
Comment 4 Ján Tomko 2020-01-15 16:10:45 UTC 
Pushed upstream right after the 6.0.0 release as:
commit 45464db8ba502764cf37ec9335770248bdb3d9a8
Author:     Ján Tomko <jtomko>
CommitDate: 2020-01-15 17:10:20 +0100

    conf: do not generate machine names ending with a dash
    
    As of systemd commit:
    
    commit d65652f1f21a4b0c59711320f34266c635393c89
    Author:     Zbigniew Jędrzejewski-Szmek <zbyszek.pl>
    CommitDate: 2018-12-10 09:56:56 +0100
    
        Partially unify hostname_is_valid() and dns_name_is_valid()
    
    Dashes are no longer allowed at the end of machine names.
    
    Trim the trailing dashes from the generated name before passing
    it to machined.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1790409
    
    Signed-off-by: Ján Tomko <jtomko>
    Reviewed-by: Erik Skultety <eskultet>

git describe: v6.0.0-8-g45464db8ba
Comment 5 Cole Robinson 2020-05-27 21:39:32 UTC 
Backporting this is a bit of a pain because it requires new virbuffer.c infrastructure that was added on top of other cleanups. It's fixed in f32 though. Option is to use virt-preview repo to get newer libvirt, or rework the VM name length to not tickle this issue. Closing against F32
Comment 6 Radek Vykydal 2020-06-04 07:24:57 UTC 
(In reply to Cole Robinson from comment #5)
> Backporting this is a bit of a pain because it requires new virbuffer.c
> infrastructure that was added on top of other cleanups. It's fixed in f32
> though. Option is to use virt-preview repo to get newer libvirt, or rework
> the VM name length to not tickle this issue. Closing against F32

Thank you for the fix. We have just switched to using F32 hosts so it seems not to be problem for us. Also I can confirm the problem is fixed for us with F32.