openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842018-03-09T09:34:47ZopenSUSE Project Management Tool
Redmine openQA Project - action #32968 (Resolved): [kernel][tools] Refactor QEMU backend - Create QEMU pr...https://progress.opensuse.org/issues/329682018-03-09T09:34:47Zrpalethorperichard.palethorpe@suse.com
<p>Start moving the configuration of QEMU to a more abstract model where the parameters are generated from an object model. This should allows parameters to be added and removed between QEMU restarts as well as making the configuration more modular. There are too many parameters to create an object model for in a single refactoring (without breaking the small batch sizes principle), so we can split them into static parameters which are just an array of strings like in the current model and dynamic parameters which are stored as Perl objects and are serialised into parameter strings when required. The ultimate goal is to have an object model which completely decouples configuration from how the parameters are passed to QEMU. And possibly after that we could further generalise the object model between backends to allow some configuration options to be shared between backends. However it may not be necessary to go that far.</p>
<p>This ticket is just for creating the manager class with the static parameters.</p>
openQA Project - action #31777 (Resolved): [tools][kernel] Better document serial terminal consol...https://progress.opensuse.org/issues/317772018-02-14T13:27:51Zrpalethorperichard.palethorpe@suse.com
<p>The serial terminal console (virtio_console) is now being used more widely and people are running into the same problems which I had while using it with the LTP test runner. These are mostly avoidable, by following some guidelines which need to be added to the OpenQA documentation.</p>
openQA Project - action #30649 (Resolved): [tools][openqa] Improve performance by using migration...https://progress.opensuse.org/issues/306492018-01-22T12:20:38Zrpalethorperichard.palethorpe@suse.com
<p>Sometimes snapshots fail to save, see <a href="https://bugzilla.suse.com/show_bug.cgi?id=1035453">https://bugzilla.suse.com/show_bug.cgi?id=1035453</a>. This is of high importance to kernel team because the LTP test runner now makes heavy use of snapshots.</p>
<p>According to the QEMU developers this is because 'internal' snapshots are slow and relatively untested so it is recommended that we use 'external' snapshots combined with the migration functionality[1]. This is currently how libvirt works when taking a snapshot. The downside to this is that it is more complex than simply calling savevm and loadvm.</p>
<p>It makes sense to fix upstream QEMU however this could potentially take a long time[2]. Therefore I think the best thing to do is to first implement a new snapshot method within OpenQA (os-autoinst) then consider making changes to QEMU based on the results. Ideally we want to align OpenQA with the common use case which is being actively maintained.</p>
<p>Alternatively we could convert the QEMU backend to use libvirt (or combine it with the existing virsh backend). However, this only removes some of the complication, but at the same time introduces another layer of indirection. It would be quite a large undertaking so I would put it outside of the scope of this task, at least to begin with.</p>
<p>From what I have seen, the new snapshot process would look something like this:</p>
<ul>
<li>Start QEMU with the deferred migration flag</li>
<li>...Do some work...</li>
<li>Pause the virtual machine</li>
<li>For each block storage device: start an incremental snapshot to an external file</li>
<li>Save the CPU, RAM and other device state by migrating the VM to a file[3]</li>
<li>Unpause the VM</li>
<li>...Continue until something bad happens...</li>
<li>Pause the VM</li>
<li>For each storage device: restore the corresponding snapshot file</li>
<li>Restore the CPU, RAM and other device state by starting an incoming migration</li>
<li>Unpause the VM</li>
</ul>
<p>The details of how to do this should be in the libvirt source. The worst part is migrating to a file which will possibly require passing a file handle to QEMU using SCM rights or opening another socket which it can send the data to.</p>
<p>[1] <a href="https://www.mail-archive.com/qemu-devel@nongnu.org/msg504839.html">https://www.mail-archive.com/qemu-devel@nongnu.org/msg504839.html</a><br>
[2] Ideally we want a clean simple interface which requires little knowledge about QEMU's internal workings. However the QMP interface is necessarily low level which conflicts with ease of use.<br>
[3] Note we are not performing a 'migration', just using the migration command to save the VM's state to a file which could then be used in a real migration. Obviously this does not include the storage device data which is taken care of separately.</p>
openQA Project - action #19174 (Rejected): [aarch64] Timeouts waiting for QEMU HMP socket during ...https://progress.opensuse.org/issues/191742017-05-16T08:05:34Zrpalethorperichard.palethorpe@suse.com
<p>Sometimes aarch64 tests timeout waiting for a response from QEMU over HMP. In particular <a href="https://openqa.suse.de/tests/933880">https://openqa.suse.de/tests/933880</a>.</p>
<pre><code>06:42:01.1674 1294 ||| finished boot_ltp kernel at 2017-05-16 06:42:01 (126 s)
06:42:01.1686 1294 Creating a VM snapshot lastgood
DIE ERROR: timeout reading hmp socket
at /usr/lib/os-autoinst/backend/baseclass.pm line 73.
backend::baseclass::die_handler('ERROR: timeout reading hmp socket\x{a}') called at /usr/lib/os-autoinst/backend/qemu.pm line 923
backend::qemu::_read_hmp('backend::qemu=HASH(0xd22b550)') called at /usr/lib/os-autoinst/backend/qemu.pm line 991
backend::qemu::_send_hmp('backend::qemu=HASH(0xd22b550)', 'savevm lastgood') called at /usr/lib/os-autoinst/backend/qemu.pm line 212
backend::qemu::save_snapshot('backend::qemu=HASH(0xd22b550)', 'HASH(0xd9baf48)') called at /usr/lib/os-autoinst/backend/baseclass.pm line 68
backend::baseclass::handle_command('backend::qemu=HASH(0xd22b550)', 'HASH(0xd9c08b8)') called at /usr/lib/os-autoinst/backend/baseclass.pm line 422
backend::baseclass::check_socket('backend::qemu=HASH(0xd22b550)', 'IO::Handle=GLOB(0xd64c4d8)') called at /usr/lib/os-autoinst/backend/qemu.pm line 1018
backend::qemu::check_socket('backend::qemu=HASH(0xd22b550)', 'IO::Handle=GLOB(0xd64c4d8)', 0) called at /usr/lib/os-autoinst/backend/baseclass.pm line 203
eval {...} called at /usr/lib/os-autoinst/backend/baseclass.pm line 151
backend::baseclass::run_capture_loop('backend::qemu=HASH(0xd22b550)') called at /usr/lib/os-autoinst/backend/baseclass.pm line 122
backend::baseclass::run('backend::qemu=HASH(0xd22b550)', 6, 9) called at /usr/lib/os-autoinst/backend/driver.pm line 85
backend::driver::start('backend::driver=HASH(0xc535e90)') called at /usr/lib/os-autoinst/backend/driver.pm line 48
backend::driver::new('backend::driver', 'qemu') called at /usr/bin/isotovideo line 206
main::init_backend() called at /usr/bin/isotovideo line 271
06:47:01.2664 1296 waitpid for 1302 returned 0
06:47:01.2665 1296 sending TERM to qemu pid: 1302
06:47:02.2668 1296 waitpid for 1302 returned 0
06:47:02.5449 1288 signalhandler got TERM - loop 1
06:47:02.5451 1288 awaiting death of commands process
06:47:02.5505 1288 commands process exited: 1292
06:47:02.5507 1288 awaiting death of testpid 1294
06:47:02.5588 1288 test process exited: 1294
06:47:02.5589 1288 isotovideo failed
</code></pre> openQA Project - action #18980 (Resolved): [ltp][openqa][virtio][ppc64le] It appears agetty is no...https://progress.opensuse.org/issues/189802017-05-05T13:25:35Zrpalethorperichard.palethorpe@suse.com
<p>Neither os-autoinst or QEMU throw an error when creating a virtio console device, connecting to its socket or sending data. However no I/O is recorded in QEMU's chardev log, nor is anything received from the SUT through the socket. It is a bit strange that not even data sent by os-autoinst is recorded in the log, although it might never log input data, but appears to under normal operation because echo is enabled on the TTY.</p>
<p>Unlike x86, ppc64le already uses /dev/hvc0 (on the SUT) for the regular serial port whereas virtio console would usually be on this device. However this should probably just mean that it uses /dev/hvc1 instead, os-autoinst would have no problem with this. Maybe SLE's systemd is not configured to start agetty on this device or the virtio_console driver works differently on ppc64le. Both seem quite strange.</p>
<p>This might be a product bug, but I need more information from the SUT to decide. It should just work.</p>
<p>UPDATE: for those who are searching here for <strong>OFW</strong>: it's ppc detectioni<br>
<a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/4477" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/4477</a><br>
(Replace check_var ARCH ppc64le by get_var OFW)</p>
openQA Project - action #16616 (Rejected): ppc64le tests die/timeout while saving snapshothttps://progress.opensuse.org/issues/166162017-02-09T11:01:12Zrpalethorperichard.palethorpe@suse.com
<p>In the following case it clearly shows that the test timed out while waiting for a response from QEMU. In other cases it is not clear to me why the test dies, but it seems to happen at the same point (where a snapshot is saved). I thought there would be an existing ticket for this, but could not find it.</p>
<p><a href="https://openqa.suse.de/tests/762741" class="external">https://openqa.suse.de/tests/762741</a></p>
<a name="Hypothesises"></a>
<h2 >Hypothesises<a href="#Hypothesises" class="wiki-anchor">¶</a></h2>
<ul>
<li>H1, It takes too long to save the snapshot and times out, but would complete if given enough time.</li>
<li>H2, QEMU crashes</li>
<li>H3, The storage is unreachable or broken</li>
<li>H4, The socket is misread by os-autoinst</li>
</ul>
<p>H1 seems the most likely by far.</p>
<a name="Potential-Actions"></a>
<h2 >Potential Actions<a href="#Potential-Actions" class="wiki-anchor">¶</a></h2>
<ul>
<li>A1, Increase the timeout</li>
<li>A2, Increase the storage or compression performance</li>
<li>A3, Stress test OpenQA to recreate the bug and investigate further</li>
</ul>
<p>A1 is easiest, A2 and A3 may be more profitable, but maybe too difficult for now.</p>
<a name="Workarounds"></a>
<h2 >Workarounds<a href="#Workarounds" class="wiki-anchor">¶</a></h2>
<p>Simply restart the test manually.</p>
openQA Project - action #16544 (Rejected): Worker does not terminate when sent TERM signalhttps://progress.opensuse.org/issues/165442017-02-07T11:50:12Zrpalethorperichard.palethorpe@suse.com
<p>When I start a worker with</p>
<p><code>sudo -u _openqa-worker /home/richie/qa/openQA/script/worker --instance 1<br>
--isotovideo ~/qa/os-autoinst/isotovideo --verbose --apikey 1234567890ABCDEF --a<br>
pisecret 1234567890ABCDEF</code></p>
<p>and run a job which fails or completes (more often with a job which fails), the script will not close unless I send the kill signal.</p>
<p>If I press <code>^C</code> then the following is printed:<br>
<code>[INFO] quit due to signal INT</code></p>
<p>If I send <code>kill -TERM <pid></code> then is printed:<br>
<code>[INFO] quit due to signal TERM</code></p>
<p>However the script does not close, sending the kill signal closes the script, but there is still a Perl process active which must also be killed otherwise the pool folder remains locked.</p>
<p>If you have observed a similar problem, please comment, in case it is just my installation (which is from the Git HEAD).</p>
openQA Project - action #16538 (Resolved): [easy hack] improve isotovideo command line handling a...https://progress.opensuse.org/issues/165382017-02-07T09:19:49Zrpalethorperichard.palethorpe@suse.com
<p>Typing <br>
<code>$ ./isotovideo lsdjf</code></p>
<p>Only results in:<br>
<code>Can't open 'vars.json' for reading: 'No such file or directory' at qa/os-autoinst/bmwqemu.pm line 72<br>
1672: EXIT 1</code></p>
<p>There is no warning that a command line parameter has been ignored, this is an issue with the following:<br>
<code>/isotovideo -d /tmp/vars.json</code></p>
<p>Intuitively I would expect <code>/tmp/vars.json</code> to be used as the test's parameters, instead it is ignored and the following message is returned<br>
<code>Can't open 'vars.json' for reading: 'No such file or directory' at qa/os-autoinst/bmwqemu.pm line 72<br>
1734: EXIT 1</code></p>
<p>There are a number of possible actions, including:</p>
<ul>
<li>A1, produce an error and help message on an unexpected command line argument</li>
<li>A2, treat the first command line argument (which does not start with '-') as the path to vars.json</li>
</ul>
<p>Obviously A1 and A2 are not mutually exclusive.</p>
openQA Project - action #16506 (Resolved): [easy hack] Use of uninitialized value with isotovideo...https://progress.opensuse.org/issues/165062017-02-06T14:45:11Zrpalethorperichard.palethorpe@suse.com
<p>run <code>isotovideo --help</code> and observe:</p>
<p><code>Use of uninitialized value $r in concatenation (.) or string at qa/os-autoinst/isotovideo line 537.<br>
23685: EXIT<br>
Use of uninitialized value $? in scalar assignment at qa/os-autoinst/isotovideo line 538.</code></p>
openQA Project - action #16320 (Resolved): Random timeouts while waiting for serial output when u...https://progress.opensuse.org/issues/163202017-01-30T11:00:19Zrpalethorperichard.palethorpe@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>Tests timeout while waiting for output from an LTP test: <a href="https://openqa.suse.de/tests/743383" class="external">https://openqa.suse.de/tests/743383</a>.</p>
<p>It appears that the command text is sent to the SUT, but no response is received. In the serial log[1] for the above test it shows that the last test ran and returned a result. However nothing is read by the virtio console backend.</p>
<p>In this test: <a href="https://openqa.opensuse.org/tests/342884" class="external">https://openqa.opensuse.org/tests/342884</a> [2], one call to <code>wait_serial</code> fails, but then the next succeeds and then it fails again. The calls which pass do not use regular expressions to do the matching.</p>
<p>As a rough estimate this bug occurs in 1%-5% of tests.</p>
<a name="Problem"></a>
<h2 >Problem<a href="#Problem" class="wiki-anchor">¶</a></h2>
<ul>
<li>H1, QEMU is writing bytes to the log, but not the socket</li>
<li>H2, The virtio backend function <code>read_until</code> is not reading bytes from the socket correctly</li>
<li>H3, One or more of the read buffers in <code>read_until</code> are being dropped.</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>A0, Inspect more test failures.</li>
<li>A1, Run the virtio terminal unit tests repeatedly.</li>
<li>A2, Modify the virtio test module to perform a stress test.</li>
<li>A3, Investigate how QEMU passes the data.</li>
</ul>
<p>I am currently waiting for a crash dump of the SUT to be attempted after a freeze.</p>
<a name="workaround"></a>
<h2 >workaround<a href="#workaround" class="wiki-anchor">¶</a></h2>
<ul>
<li>W0, Retrigger the job manually.</li>
<li>W1, Retrigger the job automatically after a timeout.</li>
</ul>
<p>[1] The serial log is written by QEMU.<br>
[2] There is no virtio serial log for this test, possibly O3 needs updating.</p>
openQA Project - action #14690 (Resolved): Live stream for serial terminalhttps://progress.opensuse.org/issues/146902016-11-08T14:32:21Zrpalethorperichard.palethorpe@suse.com
<p>Replace the live SUT video feed in the OpenQA UI with a scrolling text display when a serial terminal is set as the active console.</p>
<p>Currently when the user selects a serial console a stale screen shot of the last used VNC console is shown. The live log below still updates, but the user experience is significantly degraded.</p>
openQA Project - coordination #14626 (New): [epic] backend and console capabilities interface to ...https://progress.opensuse.org/issues/146262016-11-03T13:28:48Zrpalethorperichard.palethorpe@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>Prevent "if/else" in tests needing to distinguish different backends</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> No obvious "if/else" for different types of consoles in os-autoinst-distri-opensuse are necessary anymore</li>
<li><strong>AC2:</strong> Same as <em>AC1</em> for different <em>backends</em></li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Read what had been done in <a href="https://github.com/os-autoinst/os-autoinst/pull/1232">https://github.com/os-autoinst/os-autoinst/pull/1232</a> and <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8718">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8718</a> to define "persistent" consoles</li>
<li>Incorporate content from <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/Utils/Backends.pm">https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/Utils/Backends.pm</a> into os-autoinst as flags on backends rather than if/else in test code</li>
<li>Look for other "if/else" code in test distributions, e.g. os-autoinst-distri-opensuse", distinguishing different backends and consoles to provide as capabilities on backends/consoles</li>
</ul>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<a name="Background"></a>
<h3 >Background<a href="#Background" class="wiki-anchor">¶</a></h3>
<p>In an ideal world all the backends (QEMU, bare metal, Xen) and consoles (VNC, serial or hybrid) would be accessed in a uniform manner by testapi so that the distribution and test writers could write their test case once and then have it run across all available platforms without modification. In practice however different Operating systems, hardware, hypervisors and console combinations differ significantly enough in behaviour that a completely uniform API is not possible without either significantly disadvantaging some platforms or providing support for edge cases in the distribution itself.</p>
<p>While the functions in testapi can be kept mostly uniform in availability and behaviour it requires that the distribution handles changes in the Operating System's behaviour due to the machine (virtual or physical) which it is running on and what user interface (console) is selected. Many things can be abstracted away into the console or backend classes in os-autoinst, however OS specific behaviour can not be without making os-autoinst specific to one type of OS or even Linux distribution. Currently the SUSE os-autoinst distribution handles differences between backends by reading variables to determine which backend or architecture is being used in a variety of different places and performing some particular action for that backend. Unfortunately this doesn't just happen in (suse)distribution.pm or other modules in the lib folder, but throughout the test cases.</p>
<p>The problem with branching on a particular architecture or backend is that the contents of the branch statement may actually apply to a whole class of backends not just one. Thus by restricting it to one particular backend you have missed an opportunity to maximise the benefit of your code, which will lead to duplication of effort. However in some cases it may be wasted effort to try inventing general abstractions when they will only be used in one or two instances, but then that is a universal problem, we just have to make a judgement on each and every case.</p>
<a name="Proposal"></a>
<h3 >Proposal<a href="#Proposal" class="wiki-anchor">¶</a></h3>
<p>At any rate my proposal is to introduce the notion of capabilities which can apply to consoles or backends. Any console or backend should have to declare its capabilities in a standard way which can then be read by the distribution and in some very rare cases, the distribution's test modules. Capabilities should be validated against a central list in the appropriate base class, attempting to access or set a capability which does not exist should be an error. This should make them better structured than simply adding more global variables which already serve this purpose to some extent. A list of quirks could also be maintained to indicate negative platform attributes.</p>
<p>The actual implementation could be done using a Perl map, object mixins from some Perl OO library or something else.</p>
<a name="Further-rambling"></a>
<h3 >Further rambling<a href="#Further-rambling" class="wiki-anchor">¶</a></h3>
<p>In the case of the serial terminal feature, I would remove the new testapi function I have added called is_serial_terminal and instead replace it with one or more console/backend capabilities. Perhaps something like <code>direct_read_text</code> and <code>direct_write_text</code> which indicates to the distribution that we are reading and writing raw text to the terminal, the backend would of course require a serial port capability to activate the console. The Linux VNC text console would have something like <code>redirect_write_text</code> which indicates we can redirect output to the serial port and some other capabilities to indicate that we can use needles and send key presses. Any console on some other OS/hardware combo which doesn't support serial ports will be missing the capabilities which indicate we can do this so either <code>run_script</code> and <code>wait_serial</code> will return an error indicating the missing capability or the distribution will have to implement the testapi functions using some other capabilities or workarounds.</p>
<p>Along with having capabilities comes the idea of having interfaces to take advantage of them, so that a backend, console and distribution with compatible capabilities can be plugged together. Such interfaces and their associated capabilities can be invented and implemented on a rolling basis rather than attempting to do some massive overhaul of the code base. This may slow down feature development for some time, but will eventually speed it up and creates a basis for a backend/console plugin architecture. I am willing to implement this in so far that it is required for <a class="issue tracker-4 status-3 priority-5 priority-high3 closed" title="action: Add virtio serial console backend and API (Resolved)" href="https://progress.opensuse.org/issues/14582">#14582</a> and other platform specific features I think that the LTP, and other test suites I may work with, can take advantage of.</p>
<a name="Alternatives"></a>
<h3 >Alternatives<a href="#Alternatives" class="wiki-anchor">¶</a></h3>
<p>The alternatives are to forgo taking advantage of platform specific features or add the occasional function to the testapi like <code>is_serial_terminal</code> and use the existing vars mechanism. At least for what I am currently doing, the latter choice is acceptable to me, but it is not extensible beyond a point. There is also the console proxy feature which allows you to tightly couple your test module to a particular console implementation completely bypassing all layers of abstraction while at the same time obfuscating the code flow using Perl meta programming which should be avoided at least from tests perspective.</p>
<a name="Problems"></a>
<h3 >Problems<a href="#Problems" class="wiki-anchor">¶</a></h3>
<p>It is more difficult to identify and isolate a class of behaviour shared by multiple entities and create an abstraction to encapsulate it than just to write code for a specific case. Sometimes people may attempt to create capabilities when there is no significant advantage to doing so or they may be tempted not to when there clearly is an advantage. The feature will need documenting and require effort on the part of reviewers to learn it and enforce its use. It will probably increase the codebases complexity initially until it has been reasonably taken advantage of. There is the danger of an explosion in capabilities which makes it difficult to write a new distribution which covers multiple platforms without understanding a large number of them. Regressions may be introduced while moving backends and consoles over to this system.</p>
openQA Project - action #14582 (Resolved): Add virtio serial console backend and APIhttps://progress.opensuse.org/issues/145822016-10-31T10:40:37Zrpalethorperichard.palethorpe@suse.com
<p>I have written a new console backend which allows IO through a serial terminal, in particular the virtio console with QEMU, but I am currently thinking about how to generalise it. I started out mostly interested in how virtio could be used to speed up testing, but actually it has turned out to be mostly irrelevant. The most important thing is that communication is done as if a user is typing text into a serial terminal. For platforms which can be controlled entirely (or only) over UART (or UART over USB/Bluetooth/whatever) this opens up quite a few possibilities.</p>
<p>From <a href="https://github.com/os-autoinst/os-autoinst/pull/637:">https://github.com/os-autoinst/os-autoinst/pull/637:</a></p>
<pre><code>This allows the test writer to log into and interact with a serial
terminal directly. Initially this is just for the virtio_console under
QEMU, but can be extended to any serial console.
Presently the only way of sending text to a tty running on a SUT is to
send the keystrokes via VNC. Output from the SUT can be redirected to
and read from, a serial port, however the test writer can not send text
directly to the serial port without circumventing the test API.
This patch introduces a new console backend which can be selected in the
same manner that the existing console backends are, but is limited to
text input and output. This means that there is no video feed, but
entering commands is orders of magnitude faster because the commands are
sent and interpreted as text rather than simulated keystrokes.
This adds the is_serial_terminal subroutine to the testapi which is
exported on request. Otherwise the API should be unchanged and fully
backwards compatible.
</code></pre>
<p>Currently the virtio serial terminal must be requested by the test case. I think this is fine for now, because it is primarily needed for the LTP native runner I am also working on. However after further testing and modifications to the UI to display a text feed rather than a video, I think it can be automatically used when 'root-console' (or similar) is requested. Further improvements and features may include:</p>
<a name="Display-serial-log-in-OpenQA-UI"></a>
<h3 >Display serial log in OpenQA UI<a href="#Display-serial-log-in-OpenQA-UI" class="wiki-anchor">¶</a></h3>
<p>Currently a bitmap feed is displayed, which is nice, and using a serial terminal breaks that. The user can still see, to some extent, what is happening in the virtual machine from the os-autoinst log feed. However it would be nice if they could see the tty log in real time. All that needs to happen is that either os-autoinst relays IO from the serial socket to the UI or the UI reads a log file containing the serial terminal output (e.g. QEMU produces such a file). There is probably a javascript library for handling terminal escape codes, but otherwise the raw text can just be displayed. Alternatively an image could be generated of the text terminal, but that will increase network and processor load.</p>
<a name="Use-serial-terminal-whenever-possible"></a>
<h3 >Use serial terminal whenever possible<a href="#Use-serial-terminal-whenever-possible" class="wiki-anchor">¶</a></h3>
<p>This should be easy to enable, but there are two issues. One is user experience, which I have discussed above. The second is the possibility of bugs caused by subtle differences in the testapi behaviour when switching to a serial terminal. If we explicitly switch a few different tests over to using serial, then we can probably catch most problems without exposing the entire test suite to them at once.</p>
<a name="Implement-it-for-other-platforms"></a>
<h3 >Implement it for other platforms<a href="#Implement-it-for-other-platforms" class="wiki-anchor">¶</a></h3>
<p>To my knowledge, all the backends have some ability to read input from a serial port. Ideally we will want to open a second serial port which OpenQA is not already using, but it should also be possible to use the existing one. It is then a case of generalising the existing code for virtio_console to read from a different socket. If a backend only has one serial port then we perhaps have to come up with a mechanism for ignoring kernel log messages which are usually sent to the serial port.</p>
openQA Project - action #14100 (Rejected): Implement ClientCutText for VNC to speed up sending texthttps://progress.opensuse.org/issues/141002016-10-07T08:47:04Zrpalethorperichard.palethorpe@suse.com
<p>Assuming the backend's VNC server supports *CutText actions we can send text more quickly using the ClientCutText message: <a href="https://tools.ietf.org/html/rfc6143#section-7.5.6" class="external">https://tools.ietf.org/html/rfc6143#section-7.5.6</a></p>
<p>Control flow:</p>
<ol>
<li>Test case calls type_string or perhaps a new call like paste_string</li>
<li>Check the guest is in a state which supports the clipboard</li>
<li>Check the string for any none latin characters or control codes which may break the operation</li>
<li>Send ClientCutText message in VNC.pm</li>
<li>Send the appropriate key sequence to perform paste/yank</li>
</ol>
<p>Similarly ServerCutText can be used to send text in the opposite direction, if the test writer can reliably copy text to the clipboard.</p>
<p>Potential problems:</p>
<ul>
<li>The backends may not support the *CutText operations</li>
<li>It may require a daemon to be running on the guest OS</li>
<li>Not all software supports the clipboard.</li>
</ul>
<p>Advantages:</p>
<ul>
<li>Faster</li>
<li>Won't drop keypresses</li>
<li>May work in most situations</li>
</ul>
<p>I will investigate further if other attempts to speed up text input are not adequate.</p>
openQA Project - action #12848 (Resolved): os-autoinst: CDROM assumed to be on SCSI controllerhttps://progress.opensuse.org/issues/128482016-07-25T10:18:24Zrpalethorperichard.palethorpe@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>When running os-autoinst separately from OpenQA. If <code>CDMODEL</code> in <code>vars.json</code> is not set to something beginning with <code>virtio-scsi</code> then it will fail to start the virtual machine.</p>
<pre><code>QEMU: qemu-system-x86_64: -device scsi-cdrom,drive=cd0,bus=scsi0.0: 'scsi-cdrom' is not a valid device model name
</code></pre>
<a name="Reproduction"></a>
<h2 >Reproduction<a href="#Reproduction" class="wiki-anchor">¶</a></h2>
<p>Create a vars.json similar to this</p>
<pre><code>{
"ARCH" : "x86_64",
"BACKEND" : "qemu",
"CASEDIR" : "/home/richie/qa/os-autoinst-distri-opensuse",
"CDMODEL" : "scsi-cdrom",
"DISTRI" : "opensuse",
"ISO" : "/var/lib/openqa/factory/iso/openSUSE-Tumbleweed-DVD-x86_64-Snapshot20160715-Media.iso",
"PRODUCTDIR" : "/home/richie/qa/os-autoinst-distri-opensuse/products/opensuse",
"VNC" : 90,
}
</code></pre>
<p>and run <code>isotovideo</code>. Changing CDROM to <code>virtio-scsi-pci</code> allows isotovideo to run succesfully, however it overwrites the value with <code>scsi-cdrom</code> meaning that it will fail on the next run.</p>
<a name="Discussion"></a>
<h2 >Discussion<a href="#Discussion" class="wiki-anchor">¶</a></h2>
<p>In the file qemu.pm on line 305 it decides whether or not to create a SCSI controller based on the type of drives being used. It looks for drives beginning with <code>virtio-scsi</code>, if none are present then no scsi controller is created. Then on line 548 it assumes the CDROM has the bus address <code>scsi0.0</code>.</p>
<p>It is not clear to me where the value <code>scsi-cdrom</code> comes from. The default for <code>CDMODEL</code> in <code>qemu.pm</code> is <code>virtio-scsi-pci</code>.</p>