You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we use OVMF guest (<os firmware='efi'>) by default in RHEL 9.1, some auto cases happens to vm start time out error. The reason is that there are some steps as below in our test scripts:
When starting OVMF guest after above steps, the script emulates a key input, then the guest enters the BIOS (any key could lead to this state) and stay at 'Reset system' menu item. If no enter key is input, the guest will not continue booting and stay there forever. So it causes the case timeout error.
See the failure:
2022-08-02 07:48:51,144 virt_vm L1389 DEBUG| Attempting to log into 'avocado-vt-vm1' via serial console (timeout 240s)
2022-08-02 07:48:51,650 output L0702 DEBUG| [stderr] DEBUG:aexpect.remote:Got console prompt, send return to show login
2022-08-02 07:48:55,264 env_process L2130 DEBUG| avocado-vt-vm1 alive now. Used to failed to get register info from guest 1 times
2022-08-02 07:49:49,627 ip_sniffing L0060 DEBUG| Updated HWADDR (34:48:ed:f9:e2:20)<->(10.73.178.188) IP pair into address cache
2022-08-02 07:53:04,515 iface_hotplug L0412 INFO | Restoring vm...
2022-08-02 07:53:04,552 libvirt_vm L2218 DEBUG| Destroying VM
2022-08-02 07:53:05,037 libvirt_vm L2252 WARNI| Requested MAC address release from persistent vm avocado-vt-vm1. Ignoring.
2022-08-02 07:53:05,133 virsh L1589 DEBUG| Undefine VM avocado-vt-vm1
2022-08-02 07:53:05,154 virsh L1574 DEBUG| Define VM from /tmp/xml_utils_temp_eho4kx7x.xml
2022-08-02 07:53:05,206 stacktrace L0039 ERROR|
2022-08-02 07:53:05,206 stacktrace L0041 ERROR| Reproduced traceback from: /var/tmp/libvirt-ci/runtest/avocado-vt/avocado-vt/avocado_vt/test.py:274
2022-08-02 07:53:05,207 stacktrace L0045 ERROR| Traceback (most recent call last):
2022-08-02 07:53:05,207 stacktrace L0045 ERROR| File "/var/lib/avocado/data/avocado-vt/virttest/test-providers.d/downloads/io-github-autotest-libvirt/libvirt/tests/src/virtual_network/iface_hotplug.py", line 294, in run
2022-08-02 07:53:05,207 stacktrace L0045 ERROR| session = vm.wait_for_serial_login(username=username,
2022-08-02 07:53:05,207 stacktrace L0045 ERROR| File "/var/tmp/libvirt-ci/runtest/avocado-vt/avocado-vt/virttest/virt_vm.py", line 1405, in wait_for_serial_login
2022-08-02 07:53:05,207 stacktrace L0045 ERROR| raise remote.LoginTimeoutError('exceeded %s s timeout' %
2022-08-02 07:53:05,207 stacktrace L0045 ERROR| aexpect.remote.LoginTimeoutError: Login timeout expired (output: 'exceeded 240 s timeout')
There are different possible solutions to work out with this issue:
Ask developer if a feature could be provided that vm could have a timeout (like 4 seconds) in staying at 'reset system' menu item, and could automatically continue booting.
Add one more ENTER in virt_vm.wait_for_serial_login() to workaround the 'reset system' and make vm continue booting
Match 'Reset system' keyword in aexpect.remote.handle_prompts() and enter newline to make it continue.
We will try 3 or 4 or other ways to see which solution is best. But at first phase, we will use the simplest way to workaround the failures because this issue failed too many cases now.
The text was updated successfully, but these errors were encountered:
When we use OVMF guest (
<os firmware='efi'>
) by default in RHEL 9.1, some auto cases happens to vm start time out error. The reason is that there are some steps as below in our test scripts:When starting OVMF guest after above steps, the script emulates a key input, then the guest enters the BIOS (any key could lead to this state) and stay at 'Reset system' menu item. If no enter key is input, the guest will not continue booting and stay there forever. So it causes the case timeout error.
See the failure:
There are different possible solutions to work out with this issue:
We will try 3 or 4 or other ways to see which solution is best. But at first phase, we will use the simplest way to workaround the failures because this issue failed too many cases now.
The text was updated successfully, but these errors were encountered: