QA (public) » openQA Project (public) » openQA Tests (public)

Same issue on esxi7 ? https://openqa.suse.de/tests/15133846#step/bootloader_svirt/28

[2024-08-09T10:56:42.262044+02:00] [debug] [pid:32684] [run_ssh_cmd(virsh -c esx://root@esxi7.qa.suse.cz/?no_verify=1\&authfile=/tmp/libvirtauth-Ln28  define /var/lib/libvirt/images/openQA-SUT-8.xml)] stderr:
  2024-08-09 08:56:42.069+0000: 26392: info : libvirt version: 9.0.0
  2024-08-09 08:56:42.069+0000: 26392: info : hostname: vmware-jump.qe.nue2.suse.org
  2024-08-09 08:56:42.069+0000: 26392: warning : esxUtil_ParseUri:144 : Ignoring unexpected query parameter 'authfile'
  error: Failed to define domain from /var/lib/libvirt/images/openQA-SUT-8.xml
  error: internal error: Domain already exists, editing existing domains is not supported yet

@dzedro,

Here comes my update:

I checked with Roy Cai, and he accessed exi7 on 08/05 and copied some image there, and didn't touch the test code.

And now. 'openQA-SUT-8' is not seen anymore.

vmware-jump:~ #  virsh -c esx://root@esxi7.qa.suse.cz/?no_verify=1\&authfile=/tmp/libvirtauth-6YPm list --all |grep openQA-SUT
2024-08-13 12:53:45.732+0000: 5101: info : libvirt version: 9.0.0
2024-08-13 12:53:45.732+0000: 5101: info : hostname: vmware-jump.qe.nue2.suse.org
2024-08-13 12:53:45.732+0000: 5101: warning : esxUtil_ParseUri:144 : Ignoring unexpected query parameter 'authfile'
 417   openQA-SUT-5             running
 -     openQA-SUT-3             shut off

The latest job has passed the worker-35 test.
Investigate why the worker-35 resources are being occupied.
Looking at the code: before creating worker-35, the code will undefine any existing worker-35 by the end of job.

[2024-08-13T14:46:02.761164+02:00] [debug] [pid:41467] [run_ssh_cmd(virsh -c esx://root@unreal7.qe.nue2.suse.org/?no_verify=1&authfile=/tmp/libvirtauth-crvK undefine --snapshots-metadata openQA-SUT-35)] stdout:
The domain 'openQA-SUT-35' has been undefined.

So this situation is quite peculiar, let's observe it further, no one has touched the machine durning testing.

Some additional points:
I reviewed the code from bootloader_svirt.pm. If a VM with the same name already exists and is not explicitly destroyed or undefined before creating a new one, it could lead to conflicts or unexpected behavior. Although the VM is supposed to be destroyed or undefined after the module's execution, if the job is canceled or interrupted prematurely, a resource conflict may occur when the next job tries to start a VM with the same name.

I suggested creating a ticket to investigate the issue. It involves adding the steps to destroy and undefine a VM in the bootloader_svirt.pm module before creating a new one.