Project

General

Profile

Actions

action #20604

closed

refactor current libvirt backend, e.g. better support xen backend (was: investigate xen backend)

Added by pluskalm about 7 years ago. Updated over 4 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2017-07-19
Due date:
% Done:

0%

Estimated time:

Description

Description:

We would like to investigate possibilities to have xen (paravirtualized/ fully virtualized/pvhvm) backend

User story:

We are currently testing kGraft updates on hosts generated by openQA (see i.e https://openqa.suse.de/group_overview/100). There is however demand for test coverage in Xen environment as well. Given complexity of tests (number of combinations of kernels/kGraft patches), svirt usage is not viable option. Apart from QAM/kGraft testing JeOS and CaaSP would also potentially benefit from this as well.


Related issues 1 (1 open0 closed)

Related to openQA Tests - action #55985: [svirt][serial][xen] Enable svirt serial console for XENNew2019-08-27

Actions
Actions #1

Updated by coolo about 7 years ago

Why is svirt testing not viable?

Actions #2

Updated by coolo about 7 years ago

(as we test jeos on svirt xen) - this about xen guests, right?

Actions #3

Updated by pluskalm about 7 years ago

coolo wrote:

Why is svirt testing not viable?

Managing dozens of vm's for kraft testing seems turned out to be rather challenging (and a bit boring as well)

Actions #4

Updated by pluskalm about 7 years ago

coolo wrote:

(as we test jeos on svirt xen) - this about xen guests, right?

Yes

Actions #5

Updated by coolo about 7 years ago

I don't think you understand what svirt does. https://openqa.suse.de/tests/overview?distri=casp&version=1.0&build=29.9&groupid=74 - this is casp tested on xen. And the VMs are created as the tests need it.

That we use svirt also to attach to running kgraft instances is just an abuse of the backend.

Actions #6

Updated by pluskalm about 7 years ago

  • Subject changed from [qam] [tools] investigage xen backend to [qam] [tools] investigate xen backend

coolo wrote:

I don't think you understand what svirt does. https://openqa.suse.de/tests/overview?distri=casp&version=1.0&build=29.9&groupid=74 - this is casp tested on xen. And the VMs are created as the tests need it.

That we use svirt also to attach to running kgraft instances is just an abuse of the backend.

Indeed I missed that functionality - nevertheless I still wonder how difficult it would be to have Xen worker as well

Actions #7

Updated by coolo about 7 years ago

effortless - install libvirt on the same host as openqa worker and define the svirt hostname to localhost.

Actions #8

Updated by coolo about 7 years ago

of course it requires one piece of hardware per xen host version you want to test with.

Actions #9

Updated by coolo almost 7 years ago

  • Subject changed from [qam] [tools] investigate xen backend to investigate xen backend
  • Target version set to future

I remove the [qam] here as Martin didn't know qam can use libvirt to create xen instances - having a generic xen backend will only happen as special libvirt handling IMO.

Actions #10

Updated by okurz over 6 years ago

  • Target version changed from future to future
Actions #11

Updated by okurz over 5 years ago

  • Category changed from 132 to Feature requests
Actions #12

Updated by okurz about 5 years ago

coolo wrote:

having a generic xen backend will only happen as special libvirt handling IMO.

What do you mean by that? Is there anything necessary to be done here? We have the possibility to run tests on xen and it is actively used, so what elese would bring new functionality?

Actions #13

Updated by coolo about 5 years ago

Basically a refactoring of the current libvirt support - which is quite a big hack.

Actions #14

Updated by okurz about 5 years ago

still don't get it. Seems like you only answered my first question "What do you mean by that?". So a big refactoring. Do we need a ticket for "refactoring"? I guess whenever we want to fix bugs or actually add new features we would consider refactoring, right?

Actions #15

Updated by coolo about 5 years ago

This is the ticket for refactoring - and it's future

Actions #16

Updated by okurz about 5 years ago

  • Subject changed from investigate xen backend to refactor current libvirt backend, e.g. better support xen backend (was: investigate xen backend)
Actions #17

Updated by pvorel almost 5 years ago

  • Description updated (diff)
Actions #18

Updated by pvorel almost 5 years ago

  • Related to action #55985: [svirt][serial][xen] Enable svirt serial console for XEN added
Actions #19

Updated by pvorel almost 5 years ago

I wonder what XEN support is missing in svirt. We use svirt for s390x LTP tests, which also test KLP, KOTD, etc.
Also mloviska is planning to use LTP on JeOS (#40175), which also includes XEN.
So my only concern about svirt on XEN is #55985 (adapt svirt serial for XEN as well, it shouldn't be that difficult).

Actions #20

Updated by okurz over 4 years ago

  • Status changed from New to Rejected
  • Assignee set to okurz

In the current state of the ticket I just doubt it will be helpful. The backlog of tickets is overwhelming for many and no volunteer jumps on board to work on old, stale tickets easily, especially not if it's not a "fancy feature" but "refactor old hacks". If the time and the need comes we will refactor same as we are constantly improving our code base recently and ongoing. IMHO no need to keep this open.

Actions

Also available in: Atom PDF