QA (public) » openQA Project (public)

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.

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.

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}"

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