jfehlig

The libvirt TCK provides a framework for performing testing of the integration between libvirt drivers, the underlying virt hypervisor technology, related operating system services and system configuration. The idea (and name) is motivated by the Java TCK. Currently the libvirt TCK is not fully packaged for SUSE and the test suite itself contains a lot of Redhat-isms. Mike Latimer and Jim Fehlig will work on properly packaging libvirt TCK (it has a LOT of perl dependencies) and patching it to work better with SUSE virtualization hosts and SUSE guest operating systems. It has traditionally focused on the KVM hypervisor, so there might be some progress made to make it work better with Xen too.

The virtualization team's automated testing has a long history. It was born in the old Novell Integration Test framework. The virtualization lab ran an instance of this framework for many years. Over time, those who knew the framework left the company, taking their knowledge and leaving little documentation behind. As our testing needs increased, we found the old framework insufficient, but saw little value in improving it given the available open source CI frameworks. Before burying ourselves in SLE12 development, we took some time to move our automated tests under control of a Jenkins instance running in our lab. Tests were configured to run when new packages landed in our SLE12 devel project, ensuring our queued SLE12 submissions were continuously tested. But more is needed.

The libvirt qemu hypervisor driver has long supported protecting disk devices from concurrent use via libvirt's lock manager interface. Xen used to support the same functionality in the old xend toolstack, but dropped support in the new libxl toolstack. The Xen community decided, rightly so, that this functionality is best provided by a higher-level management tool, e.g. libvirt. This project aims to provide integration between libvirt's lock manager and the libxl hypervisor driver, essentially reintroducing support for disk device protection in the Xen management stack.

libvirt+Xen should support the qdisk (qemu) rbd backend, providing native access to block devices hosted on Ceph clusters. Adding this support to the libvirt+Xen toolstack will also improve interoperability with SUSE Enterprise Storage.

openvswitch is used by cloud infrastructure (e.g. OpenStack) and software defined networking stacks, often in conjunction with KVM and Xen compute resources. When creating workloads on KVM compute resources, orchestration services can specify the openvswitch interfaceid and port-profile of the workload's virtual interface(s). E.g. orchestration can create workload configuration containing

I wanted to work on something test related this hackweek since we always need more automated testing of our virtualization-related packages. There are many possible test-related topics, but I think a good addition would be more unit tests that are run during build time, e.g. during 'make check'. Additional tests of this nature would then be run by upstream developers and the various distro CI setups, exposing the tests to more environments than would typically be available within SUSE. To this end, I'm planning to add unit tests to libvirt.git that test conversion of domain XML to structures used by Xen's libxl interface. The first attempt at such tests was nearly 3 years ago

Most large workloads such as SAP HANA require special, highly optimized configuration to run in a virtual machine. Virtual resources such as memory and CPU must be carefully configured to ensure optimum performance of the virtual machine workload. Default VM configuration created by tools such as virt-install are not optimized and often result in poor performance of large workloads due to memory access latencies and incorrect/incomplete information available to the VM's task scheduler. Currently, users deploying large workloads must manually optimize virtual CPU and memory resources, which can be error-prone and if not done properly can actually degrade performance. This project aims to create a tool that can produce suggested vCPU and vNUMA configuration based on a VM configuration template and capabilities of the target virtual machine host. E.g. something along the lines of

Brewtarget is an open source brewing software, similar to the commercial product BeerSmith. For hackweek I'd like to investigate the capabilities of Brewtarget and perhaps add some features/improvements for my use case.

This project aims to run VMs in a CaaSP 4 cluster using kubevirt and a libvirt+qemu container (aka compute container) based on SLES15 SP1/2. Compute containers based on openSUSE Leap15.1 and SLES15 SP1 already available in registry.opensuse.org and registry.suse.com respectively. VMs can be deployed to the cluster but there are several functional problems that need investigating, e.g. accessing the VM's serial and VNC consoles, proper network access, etc.

Project Description

Update the physical KubeVirt+Kubernetes test cluster in Provo from SLES15 SP2 and CaaSP to SLES15 SP3 and Rancher's k3s. This will allow us to easily experiment and test Harvester.

Project Description

Most developers are comfortable with the workflows of git hosting services like gitlab and github, including their CI/CD capabilities. This project aims to experiment with new downstream package development and maintenance workflows based on upstream git repositories cloned at gitlab.suse.de. I'll be using the libvirt package for these experiments since it typically contains a healthy mixture of downstream-only patches along with upstream cherry picks.