action #50111
closedcoordination #49889: [functional][epic][y] Switch between installation/install shell in specific scenarios (hyperv, ssh,vnc)
[functional][y] Switch between installation/install shell in vnc installation
Added by riafarov about 5 years ago. Updated over 3 years ago.
0%
Description
Motivation¶
Currently There are several cases where we cannot switch to a install shell when we are in an installation, however being able to switch to a console can be very useful.
In the https://openqa.suse.de/tests/latest?arch=x86_64&flavor=Installer-DVD&distri=sle&test=remote_vnc_controller&version=15-SP1&machine=64bit we have completely wrong setup.
In case we want to collect the logs, logs are collected from the image of SLE 12 SP3 instead of SUT, which is wrong and dangerous.
Acceptance criteria¶
- Logs can be collected from the SUT in case of MM VNC installation
Further details¶
This is a change in os_autoinst. select_console is a function in testapi.pm.
The way to swith between consoles is:
select_console 'install-shell';
select_console 'installation';
Possible solutions:
We can enable ssh on the machine with installation and connect to it to collect logs.
Alternative would be to collect logs on the machine where installation is running.
In theory is should be possible to switch tty over VNC, but will be tricky in the VM to which we are already connected over VNC.
Files
| Screenshot from 2019-10-11 10-29-29.png (88.1 KB) Screenshot from 2019-10-11 10-29-29.png | have we tried F8 key? | JERiveraMoya, 2019-10-11 08:35 |
Updated by riafarov about 5 years ago
- Copied from coordination #49889: [functional][epic][y] Switch between installation/install shell in specific scenarios (hyperv, ssh,vnc) added
Updated by riafarov about 5 years ago
- Copied from deleted (coordination #49889: [functional][epic][y] Switch between installation/install shell in specific scenarios (hyperv, ssh,vnc))
Updated by riafarov about 5 years ago
- Description updated (diff)
- Estimated time set to 8.00 h
Updated by riafarov about 5 years ago
- Due date changed from 2019-05-07 to 2019-05-21
Updated by riafarov about 5 years ago
- Due date changed from 2019-05-21 to 2019-06-04
- Target version changed from Milestone 24 to Milestone 25
Updated by riafarov almost 5 years ago
- Blocks action #49622: [functional][y] Verify the wrong desktop will show up added
Updated by ybonatakis almost 5 years ago
- Status changed from Workable to In Progress
- Assignee set to ybonatakis
Updated by riafarov almost 5 years ago
- Due date changed from 2019-06-04 to 2019-06-18
Updated by ybonatakis almost 5 years ago
- Due date changed from 2019-06-18 to 2019-06-04
Most of the approaches and tests didnt work. What is promising is a solution i found on stackoverflow. in a nutshell, you go to the qemu console and make use of sendkey or maybe even chvt.
The test this in a local qemu image and seemed to work.
When i tried the same in the test connected from VNC i could switch to the qemu console but not send any command. the problem could be in the parameters where the qemu takes. those were for the test that i was using:
/usr/bin/qemu-system-x86_64 -vga cirrus -only-migratable -chardev ringbuf,id=serial0,logfile=serial0,logappend=on -serial chardev:serial0 -soundhw ac97 -global isa-fdc.driveA= -m 1024 -cpu qemu64 -netdev tap,id=qanet0,ifname=tap1,script=no,downscript=no -device virtio-net,netdev=qanet0,mac=52:54:00:12:00:17 -boot order=c,menu=on,splash-time=5000 -device usb-ehci -device usb-tablet -smp 1 -enable-kvm -no-shutdown -vnc :92,share=force-shared -device virtio-serial -chardev socket,path=virtio_console,server,nowait,id=virtio_console,logfile=virtio_console.log,logappend=on -device virtconsole,chardev=virtio_console,name=org.openqa.console.virtio_console -chardev socket,path=qmp_socket,server,nowait,id=qmp_socket,logfile=qmp_socket.log,logappend=on -qmp chardev:qmp_socket -S -device virtio-scsi-pci,id=scsi0 -blockdev driver=file,node-name=hd0-overlay0-file,filename=/var/lib/openqa/pool/2/raid/hd0-overlay0,cache.no-flush=on -blockdev driver=qcow2,node-name=hd0-overlay0,file=hd0-overlay0-file,cache.no-flush=on -device virtio-blk,id=hd0-device,drive=hd0-overlay0,bootindex=0,serial=hd0 -blockdev driver=file,node-name=cd0-overlay0-file,filename=/var/lib/openqa/pool/2/raid/cd0-overlay0,cache.no-flush=on -blockdev driver=qcow2,node-name=cd0-overlay0,file=cd0-overlay0-file,cache.no-flush=on -device scsi-cd,id=cd0-device,drive=cd0-overlay0,serial=cd0
Updated by riafarov almost 5 years ago
- Due date changed from 2019-06-04 to 2019-06-18
Updated by ybonatakis almost 5 years ago
the solution so far involves the opening of xterm and collecting the logs from the target (where the installation is taking place). the problem with this is that the assert_script_run redirects to the serial device that the command is executed. this causes the assert_script_run failing with timeout. One solution is to use script_run or as it is suggested to use type_string in those occasions.
Updated by ybonatakis almost 5 years ago
Updated by ybonatakis almost 5 years ago
the approach is not unified for both VNC and ssh cases.
As it was suggested, i tried to use the root-ssh. the problem i encountered with this is shown in the logs as following
[2019-06-17T15:21:04.785 CEST] [debug] <<< testapi::select_console(testapi_console='root-ssh')
console root-ssh does not exist at /usr/lib/os-autoinst/backend/driver.pm line 95.
[2019-06-17T15:21:04.785 CEST] [debug] Backend process died, backend errors are reported below in the following lines:
Can't call method "select" on an undefined value at /usr/lib/os-autoinst/backend/baseclass.pm line 556.
Taking a deeper look, i discovered that the root-ssh is not used on qemu backend.
lib/susedistribution.pm
if (get_var('BACKEND', '') =~ /ikvm|ipmi|spvm/)
Then i tried to test adding qemu to the list of patterns. the following restriction appears
Could not retrieve required variable SUT_IP at /var/lib/openqa/share/tests/sle/lib/susedistribution.pm line 435.
i tried, then, to set_var the variable in different location in the test without success and having the same error.
Updated by riafarov almost 5 years ago
- Due date changed from 2019-06-18 to 2019-07-02
Updated by riafarov almost 5 years ago
- Target version changed from Milestone 25 to Milestone 26
Updated by ybonatakis almost 5 years ago
for future reference, it is also possible to collect logs from the system using the start_shell in the boot option. this is will give a console which can be used even when openqa crushes
Updated by ybonatakis almost 5 years ago
- Status changed from In Progress to Feedback
Updated by riafarov almost 5 years ago
- Due date changed from 2019-07-02 to 2019-07-16
PR is still open.
Updated by riafarov almost 5 years ago
- Due date changed from 2019-07-16 to 2019-07-30
- Estimated time deleted (
8.00 h)
VR is missing to verify changes in the code.
Updated by riafarov almost 5 years ago
- Due date changed from 2019-07-30 to 2019-08-13
- Target version changed from Milestone 26 to Milestone 27
Needs another round of review.
Updated by ybonatakis over 4 years ago
waiting for some VR on the production to close it
Updated by ybonatakis over 4 years ago
The pull request has been merged but it does not work [0]. At least not for ssh. i have triggered the vnc job [1] to get a full picture.
[0] https://openqa.suse.de/tests/3237658#step/wel come/18
[1] https://openqa.suse.de/tests/3238021#
Updated by ybonatakis over 4 years ago
vnc is also failing to upload the logs https://openqa.suse.de/tests/3238021#
Updated by riafarov over 4 years ago
- Due date changed from 2019-08-13 to 2019-09-10
- Status changed from Feedback to Workable
- Target version changed from Milestone 27 to Milestone 30+
We basically need to start over here and this time I would suggest to fix that in the console handling instead of hacking single scenario.
Updated by riafarov over 4 years ago
- Estimated time set to 8.00 h
https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/susedistribution.pm#L651 here is piece of logic, where we need to redirect root-console to use ssh connection instead for vnc remote installations.
Updated by ybonatakis over 4 years ago
- Status changed from Workable to In Progress
- Assignee set to ybonatakis
Updated by ybonatakis over 4 years ago
- Status changed from In Progress to Workable
Updated by ybonatakis over 4 years ago
- Status changed from Workable to In Progress
Updated by riafarov over 4 years ago
- Due date changed from 2019-09-10 to 2019-09-24
Updated by ybonatakis over 4 years ago
- Status changed from In Progress to Workable
- Assignee deleted (
ybonatakis)
Updated by ybonatakis over 4 years ago
- Status changed from Workable to In Progress
- Assignee set to ybonatakis
Updated by JERiveraMoya over 4 years ago
- Due date changed from 2019-09-24 to 2019-10-08
We failed to look a this ticket. Moving to next sprint.
Updated by ybonatakis over 4 years ago
as i havent found a solution yet based on the requirement i submitted a PR which at least should solve the latest fail to upload the logs when a module fails https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8610
Updated by riafarov over 4 years ago
- Due date changed from 2019-10-08 to 2019-10-22
Updated by ybonatakis over 4 years ago
- Status changed from In Progress to Workable
- Assignee deleted (
ybonatakis)
VR in OSD doesnt work. the reason seems to be that the VM cant communicate with the server set by autoinst_url("/uploadlog/$upname"). i dont know why this work locally. i will close the PR.
Updated by JERiveraMoya over 4 years ago
Updated by JERiveraMoya over 4 years ago
- Status changed from Workable to In Progress
We cannot reuse solution for ipmi due to in ipmi there is two machines and one worker and this worker has access to a physical serial device named SOL, but in Multi-Machine setup we have two machines and one worker for each machine, where the worker in one them (controller) cannot have exclusive access to serial (which virtual provide by qemu) in the other machine (target), meaning that even if we could try to connect both would be a mess for other jobs running, as we would be hacking the serial for the target machine. Discarded the possibility to reuse ipmi approach I'm taking a look for running commands pre-pending ssh, which in some way is used also in this PR but we might need more simple approach for our scenario.
Updated by okurz over 4 years ago
JERiveraMoya wrote:
We cannot reuse solution for ipmi due to in ipmi there is two machines and one worker and this worker has access to a physical serial device named SOL, but in Multi-Machine setup we have two machines and one worker for each machine
There is no direct necessity to handle any IPMI machines different to qemu machines. In principle the idea is that every SUT has both at least a graphical-capable console as well as a serial console.
I'm taking a look for running commands pre-pending ssh, which in some way is used also in this PR
That should only be necessary if you have remote SUTs that are not directly available, e.g. cloud VMs or in case of https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8099 it was a SUT within a separated IBM network that could only be reached over VPN and a two-jump ssh tunnel.
Updated by ybonatakis over 4 years ago
from my investigation i didnt see any solution on impi or other system. When they fail the log gathering is not working
Updated by JERiveraMoya over 4 years ago
- Status changed from In Progress to Feedback
PR: Wait for children to run post_fail_hook on target in MM -> Merged
Updated by JERiveraMoya over 4 years ago
- Status changed from Feedback to Resolved
VR: for instance, recent failure in controller failing in beta warning needle and still we get logs in target.
Updated by riafarov over 4 years ago
https://openqa.suse.de/tests/3501119# Works like a charm. Good job here!