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).
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.
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.)
Upstream patches removing the hyphens: https://www.redhat.com/archives/libvir-list/2020-January/msg00623.html
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
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
(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.