Bug 1790409 - Provisioning of VM fails with "ERROR (cli:257) Invalid machine name"
Summary: Provisioning of VM fails with "ERROR (cli:257) Invalid machine name"
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ján Tomko
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-13 10:27 UTC by Radek Vykydal
Modified: 2020-06-04 07:24 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-27 21:39:32 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
virt-install.log.1 from /root/.cache/virt-manager/ (1016.14 KB, text/plain)
2020-01-13 10:27 UTC, Radek Vykydal
no flags Details
virt-install.log from /root/.cache/virt-manager/ (706.45 KB, text/plain)
2020-01-13 10:35 UTC, Radek Vykydal
no flags Details

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.


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