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