Project

General

Profile

action #20604

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

Added by pluskalm almost 3 years ago. Updated about 2 months ago.

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

0%

Estimated time:
Difficulty:
Duration:

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

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

History

#1 Updated by coolo almost 3 years ago

Why is svirt testing not viable?

#2 Updated by coolo almost 3 years ago

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

#3 Updated by pluskalm almost 3 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)

#4 Updated by pluskalm almost 3 years ago

coolo wrote:

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

Yes

#5 Updated by coolo almost 3 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.

#6 Updated by pluskalm almost 3 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

#7 Updated by coolo almost 3 years ago

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

#8 Updated by coolo almost 3 years ago

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

#9 Updated by coolo over 2 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.

#10 Updated by okurz almost 2 years ago

  • Target version changed from future to future

#11 Updated by okurz 12 months ago

  • Category changed from 132 to Feature requests

#12 Updated by okurz 10 months 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?

#13 Updated by coolo 9 months ago

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

#14 Updated by okurz 9 months 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?

#15 Updated by coolo 9 months ago

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

#16 Updated by okurz 9 months ago

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

#17 Updated by pvorel 6 months ago

  • Description updated (diff)

#18 Updated by pvorel 6 months ago

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

#19 Updated by pvorel 6 months 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).

#20 Updated by okurz about 2 months 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.

Also available in: Atom PDF