action #20604
closed
refactor current libvirt backend, e.g. better support xen backend (was: investigate xen backend)
Added by pluskalm almost 7 years ago.
Updated about 4 years ago.
Category:
Feature requests
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 open — 0 closed)
Why is svirt testing not viable?
(as we test jeos on svirt xen) - this about xen guests, right?
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)
coolo wrote:
(as we test jeos on svirt xen) - this about xen guests, right?
Yes
- 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
effortless - install libvirt on the same host as openqa worker and define the svirt hostname to localhost.
of course it requires one piece of hardware per xen host version you want to test with.
- 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.
- Target version changed from future to future
- Category changed from 132 to Feature requests
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?
Basically a refactoring of the current libvirt support - which is quite a big hack.
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?
This is the ticket for refactoring - and it's future
- Subject changed from investigate xen backend to refactor current libvirt backend, e.g. better support xen backend (was: investigate xen backend)
- Description updated (diff)
- Related to action #55985: [svirt][serial][xen] Enable svirt serial console for XEN added
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).
- 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