Project

General

Profile

action #9680

libvirt backend

Added by RBrownSUSE over 6 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
-
Start date:
2016-01-13
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Difficulty:

Description

We really could do with a generic libvirt backend that would allow a consistent interface for testing through openQA on multiple hypervisors

Ideally this would be the gateway through which we could easily test on ESXi, HyperV, Xen, and an alternative to our existing KVM


Subtasks

openQA Tests - action #10204: zKVM TestsResolvedmgriessmeier

openQA Tests - action #12330: Upgrades on s390Resolvedokurz

openQA Tests - action #15536: zKVM: Upgrades Resolvedmgriessmeier

openQA Tests - action #12346: minimalx on zKVMResolvedmgriessmeier

openQA Tests - action #10206: [tools]libvirt tests (Xen, Hyper-V, VMware)Resolvedmichalnowak

History

#1 Updated by oholecek over 6 years ago

I did an experiments using virt-install to generate libvirt domain xml file. It uses almost the same options as qemu. There is a problem getting all the functionality trough however. Mainly the one which uses qemu monitor like audio capture. Using spice instead of vnc would help with that.

#2 Updated by coolo over 6 years ago

I don't see us being interested in audio tests and e.g. multipath at the same time. So reducing the qemu backend to what it's strong in and having a generic libvirt interface for the stuff people would do on VMs sounds appealing to me.

What I don't look forward to is generating the XML the same way we generate the the qemu command line - I hate that code.

#3 Updated by okurz over 6 years ago

Isn't that what virt-install can be used for? E.g. I am testing like this:

build=GMC2
install=ftp://dist.suse.de/install/SLP/...
autoyast_profile=https://my.server.org/autoinst.xml
virt-install --connect qemu:///system  --name ${name} --ram 1024 --disk path=~/local/virtual/${name}.qcow2,size=20 --vcpus 1 --os-type linux --os-variant generic --location $install --extra-args "install=${install} usessh=1 sshpassword=XXX autoyast=${autoyast_profile}"

#4 Updated by RBrownSUSE over 6 years ago

oholecek wrote:

I did an experiments using virt-install to generate libvirt domain xml file. It uses almost the same options as qemu. There is a problem getting all the functionality trough however. Mainly the one which uses qemu monitor like audio capture. Using spice instead of vnc would help with that.

Yeah I'm not looking for feature parity with our existing qemu backend - while that would be nice, that isn't the goal

The goal is primarily to support testing of standard openQA scenarios (installations and upgrades primarily) for multiple hypervisors, specifically ESXi, HyperV, and Xen - KVM would be an obvious bonus, but might be a good starting point as it would be a sanity check compared to our existing backend - we know KVM works with openQA so we'd know if we broke it.

In the case of both ESXi and HyperV, the 'libvirtd' will be remote from the actual hypervisor - This might pose some interesting challenges in regards to getting ISOs and disk images to the hypervisors

https://libvirt.org/drvhyperv.html
https://libvirt.org/drvesx.html

In the case of Xen, we can assume local access, though if we're getting remote access done right for those other two hypervisors, then maybe it makes sense to use libvirt remotely for everything - https://libvirt.org/drvxen.html

This might also be a sensible solution for adding virtualbox testing back into openQA for openSUSE (where virtualbox testing is certainly desired by the community) https://libvirt.org/drvvbox.html

And testing SLES is a container is certainly something someone would like too.. https://libvirt.org/drvlxc.html

#5 Updated by RBrownSUSE over 6 years ago

  • Assignee set to coolo
  • Priority changed from Normal to High

#6 Updated by coolo over 6 years ago

  • Status changed from New to Resolved

I claim we can use svirt for everything - everything else are bugs

#7 Updated by mgriessmeier about 6 years ago

  • Due date set to 2016-06-14

due to changes in a related task

#8 Updated by mgriessmeier over 5 years ago

  • Due date set to 2016-06-15

due to changes in a related task

Also available in: Atom PDF