openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842018-07-25T09:41:54ZopenSUSE Project Management Tool
Redmine openQA Project - action #38822 (Resolved): Qemu: Could not open backing file: Cannot reference an...https://progress.opensuse.org/issues/388222018-07-25T09:41:54Zrpalethorperichard.palethorpe@suse.com
<p>When trying to revert to a snapshot QEMU dies with the following error or something similar:</p>
<pre><code>-blockdev driver=qcow2,node-name=hd0-overlay1,file=hd0-overlay1-file,cache.no-flush=on,backing=hd0: Could not open backing file: Cannot reference an existing block device with additional options or a new filename
</code></pre>
<p>The backing file is the hd0 block device which is specified on the command line. Possibly we should not specify block devices used as backing files on the command line and just allow them to be read from the overlay file. It is not clear what the expected usage is.</p>
openQA Project - action #36460 (Resolved): [kernel][tools] QEMU Refactor - Performance settingshttps://progress.opensuse.org/issues/364602018-05-23T14:02:30Zrpalethorperichard.palethorpe@suse.com
<p>Decide on cache mode and 'discard'.</p>
openQA Project - action #35815 (Resolved): [kernel][tools] Refactor QEMU backend - Fix VNC instal...https://progress.opensuse.org/issues/358152018-05-03T10:32:31Zrpalethorperichard.palethorpe@suse.com
<p>It appears that switching to the installation text console is broken with the new version (install-shell) in the logpackages test. Nothing happens when select console is called, it just stays in the graphical shell. However switching to the 'root-console' does work.</p>
openQA Project - action #35443 (Resolved): [kernel][tools] QEMU Refactor - Acceptance testinghttps://progress.opensuse.org/issues/354432018-04-24T16:06:49Zrpalethorperichard.palethorpe@suse.com
<p>Test on all architectures and backends. Test with interactive mode.</p>
openQA Project - action #35440 (Resolved): [kernel][tools] QEMU Refactor - Code format and rebasehttps://progress.opensuse.org/issues/354402018-04-24T16:02:55Zrpalethorperichard.palethorpe@suse.com
<p>Rebase onto master branch, use perl format and rebase the commit log.</p>
openQA Project - action #35437 (Resolved): [kernel][tools] QEMU Refactor - Publish diskhttps://progress.opensuse.org/issues/354372018-04-24T16:00:01Zrpalethorperichard.palethorpe@suse.com
<p>Write the overlays into a copy of the base block device image and publish it (do_extract_assets).</p>
openQA Project - action #35434 (Resolved): [kernel][tools] QEMU Refactor - Ensure consistent use ...https://progress.opensuse.org/issues/354342018-04-24T15:54:46Zrpalethorperichard.palethorpe@suse.com
<p>Replace verbose for loops and similar with standard library functions. Also just try to reduce verbosity in general.</p>
openQA Project - action #35431 (Resolved): [kernel][tools] QEMU Refactor - Clean up miscellaneous...https://progress.opensuse.org/issues/354312018-04-24T15:49:25Zrpalethorperichard.palethorpe@suse.com
<p>Decide whether to delete apparently unused features and workarounds or reimplement them (e.g. LVM, autoinst.img/FDD, HDDFORMAT).</p>
openQA Project - action #35407 (Resolved): [kernel][tools] QEMU Refactor - Serialise state and re...https://progress.opensuse.org/issues/354072018-04-24T09:24:24Zrpalethorperichard.palethorpe@suse.com
<p>Save and load the device (in particular block device) state for the purposes of debuging and the SKIPTO feature which requires the available drives and snapshots to be known.</p>
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 #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 Tests - action #15620 (Rejected): [LTP][OpenQA] Crontab activity not foundhttps://progress.opensuse.org/issues/156202016-12-22T12:17:18Zrpalethorperichard.palethorpe@suse.com
<p>cron_tests.sh checks /var/log/messages and /var/log/cron for crontab activity, but neither file exists on newer systems. The test should probably try using <code>journalctl</code> as well.</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>