Google Summer of Code Ideas

From Libvirt Wiki
Revision as of 19:44, 21 March 2019 by ColeRobinson (talk | contribs) (mark cloud-init project as intermediate, add a disclaimer)
(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

This page contains project ideas for upcoming Google Summer of Code.

FAQ

Google Summer of Code FAQ

Yearly programs

*  2019
*  2018
*  2017
*  2016

Template

=== TITLE ===
 
 '''Summary:''' Short description of the project
 
 Detailed description of the project.
 
 '''Links:'''
 * Wiki links to relevant material
 * External links to mailing lists or web sites
 
 '''Details:'''
 * Skill level: beginner or intermediate or advanced
 * Language: C
 * Suggested by: Person who suggested the idea

Suggested ideas

Test driver API coverage

Summary: Expand API coverage in the test driver

The test driver (as accessed via the test:/// URI scheme) is a fake virt driver designed to let applications test against libvirt with fake data and not have any effect on the host. As can be seen from the API coverage report http://libvirt.org/hvsupport.html there are quite a few APIs not yet implemented in the test driver. Ideally the test driver would have 100% API coverage, and so the goal of the project is to address gaps in the API coverage. The work is incremental, so does not matter if not all APIs are implemented as part of the project - any amount of expanded coverage is sufficient and useful.

Links:

Details:

  • Skill level: beginner
  • Language: C
  • Mentor: Pavel Hrdina <phrdina@redhat.com>, phrdina on IRC (#virt OFTC)
  • Suggested by: Daniel Berrange

Introducing job control to the storage driver

Summary: Implement abstract job control and use it to improve storage driver.

Currently, libvirt support job cancellation and progress reporting on domains. That is, if there's a long running job on a domain, e.g. migration, libvirt reports how much data has already been transferred to the destination and how much still needs to be transferred. However, libvirt lacks such information reporting in storage area, to which libvirt developers refer to as the storage driver. The aim is to report progress on several storage tasks, like volume wiping, file allocation an others.

  • Component: libvirt
  • Skill level: advanced
  • Language: C
  • Mentor: Pavel Hrdina <phrdina@redhat.com>, phrdina on IRC (#virt OFTC)
  • Suggested by: Michal Privoznik <mprivozn@redhat.com>

libvirt bindings for node.js

Summary: There are few libvirt bindings for node.js available via npm. However none of them expose all libvirt APIs. That is mainly because they are manually written and not automatically generated. The aim is to utilize same information that python bindings do and automatically generate node libvirt bindings based on that information so that they don't need to be modified for every new API. This is continuation of last years effort, not starting from scratch.

  • Component: libvirt
  • Skill level: advanced
  • Language: C, node.js
  • Suggested by: Martin Kletzander <mkletzan@redhat.com>

Links:

QEMU command line generator XML fuzzing

Summary: Using fuzzing techniques to generate unusual XML to feed to QEMU command line generator

There are a huge number of potential variants of XML documents that can be fed into libvirt. Only a subset of these are valid for generating QEMU command lines. It is likely that there are cases where omitting certain attributes or XML elements will cause the QEMU command line generator to crash. Using fuzzing techniques to generate unusual XML documents which could then be fed through the test suite may identify crashes.

Details:

  • Component: libvirt
  • Skill level: intermediate
  • Language: C
  • Mentor:
  • Suggested by: Daniel Berrange

Libvirt driver for Jailhouse

Summary: Add support for Jailhouse hypervisor to libvirt.

Jailhouse is a Linux-based partitioning hypervisor designed to run bare-metal applications and (adapted) operating systems alongside Linux. Compared to other hypervisors such as KVM or Xen, Jailhouse is optimized for simplicity rather than features and targets real-time and security workloads.

The project's goal is to develop libvirt driver for Jailhouse. The current vision is to implement lifecycle management (VM aka cell start/stop), status and virtual console support. The latter relies on work-in-progress which would hopefully be merged mainline before the project starts.

There are some initial attempts which could be used as a starting point. However, we should refrain from calling jailhouse tool (a native Jailhouse command-line interface) and rather use direct kernel API (ioctls issued to /dev/jailhouse) or abstract it into a library.

Links:

Details:

  • Skill level: intermediate
  • Language: C
  • Mentor:
  • Suggested by: Valentine Sinitsyn <valentine.sinitsyn@gmail.com>


Metadata support for all object schemas

Summary: Extend the domain XML <metadata> concept to all object schemas

The domain XML schema has support for storing arbitrary user/application specified information in a <metadata> element. Beneath this element, apps can add custom content isolated in a private XML namespace. Libvirt will treat this data as a black-box and store it with no modifications. e.g.

 <metadata>
   <lcp:consoles xmlns:lcp="http://libvirt.org/schemas/console-proxy/1.0">
     <lcp:console token="999f5742-2fb5-491c-832b-282b3afdfe0c" type="spice" port="0" insecure="yes"/>
     <lcp:console token="6a92ef00-6f54-4c18-820d-2a2eaf9ac309" type="serial" port="0" insecure="yes"/>
     <lcp:console token="2a7cbf19-079e-4599-923a-8496ceb7cf4b" type="serial" port="1" insecure="yes"/>
     <lcp:console token="3d7bbde9-b9eb-4548-a414-d17fa1968aae" type="console" port="0" insecure="yes"/>
     <lcp:console token="393c6fdd-dbf7-4da9-9ea7-472d2f5ad34c" type="console" port="1" insecure="yes"/>
     <lcp:console token="7b037f4e-10ab-4c1c-8a49-4e33146c693e" type="console" port="2" insecure="yes"/>
   </lcp:consoles>
 </metadata>

There is also a free form <title> and <description> element

There are also public APIs that let applications read/write this metadata on the fly, without having to redefine the entire XML config. Changes to this metadata triggered asynchronous event notifications.

The project idea is to extend this concept to all/most other object types, networks, nwfilters, interfaces, storage pools, storage volumes, node devices, secrets, etc. This involves

  • Extending the XML schema & corresponding parser/formatter to read/write the <title>, <description> and <metadata> elements
  • Add vir{OBJECT}SetMetadata & vir{OBJECT}GetMetadata public APIs for each object
  • Add async event callback for each object to notify of changes

For networks, nwfilters, storage pools and secrets this work is mostly a matter of copying the existing code pattern used for domains. This part of the project is suitable for total beginners / novices to libvirt.

Storage volumes, interfaces and node devices are more difficult, since libvirt never stores the master XML anywhere itself - the XML is just generated on the fly from another place. We could declare that metadata for those objects is not supported. If we want to get adventurous though, we could provide custom logic. For example, for storage volumes, with file based volumes at least, we can use extended attributes on the file to record metadata. This part of the project is more advanced and so requires higher skill level. It should be considered optional. It would be a successful project to simply complete the first part, covering networks, nwfilters, storage pools and secrets.

Links:

Details:

  • Skill level: beginner
  • Language: C
  • Suggested by: Daniel Berrange

Redfish API implementation

Summary: Redfish is a REST API to manage machines, this project is about implementing it to manage libvirt VMs

This project is about creating a web service using the libvirt API to implement part of the Redfish API. The service could be created with any existing REST framework as long as there is a libvirt binding for this language. However it is rather likely to be implemented in python using Flask given it's simplicity.

Links:

Details:

  • Skill level: beginner
  • Language: python
  • Mentor: Cédric Bosdonnat <cbosdonnat@suse.com>
  • Suggested by: Cédric Bosdonnat

Add support for live migration of LXC containers

Summary: Add support for live migration of LXC containers using CRIU.

Live migration is a pervasive technique allowing transparent movement of VMs from one physical machine to another with negligible service disruption. Recently, there has been an increasing interest to apply the same technique to Linux containers.

During GSoC 2016, Katerina Koukiou implemented a PoC for save, restore and migration support for Libvirt-LXC containers. Since then, a set of patches that enables an automated transfer of image files has been merged into the development branch of CRIU (criu-dev). The idea is about adding upstream support for efficient live migration of LXC containers with Libvirt.

Links:

Details:

  • Component: libvirt
  • Skill level: intermediate
  • Language: C
  • Mentor: Radostin Stoyanov <rstoyanov@fedoraproject.org>
  • Suggested by: Cédric Bosdonnat

Extend the node device driver's API set

Summary: Implement new APIs in the node device driver in order to provide similar functionality (conceptually) to other drivers.

The node device driver is responsible for host device management. In most cases, this means that we simply report device's capabilities and track its lifetime. This is enough for physical host devices, however, there are a few other virtualization features like NFV, NPIV, and MDEV where libvirt should also be able to create such virtual devices. Currently, libvirt is only able to create transient (temporary config) NPIV/vHBA devices, so besides having support for creating virtual functions and mediated devices on feature-capable physical device we also need to be able to store persistent configuration of such virtual devices. Besides extending the existing set of APIs, this will also require a certain amount of refactor of the current code base.

Details:

  • Skill level: beginner
  • Language: C
  • Mentor: Erik Skultety <eskultet@redhat.com>
  • Suggested by: Erik Skultety <eskultet@redhat.com>

nbdkit port to Windows

Summary: nbdkit port to Windows

nbdkit is a Linux Network Block Device server. One of the things it could be used for is exposing Windows volumes to free software (including to libvirt or libguestfs, or to qemu virtual machines). However for that we need to finish off a proper port to Windows. There are the beginnings of a port (see links) but it doesn't work well. In order to be able to accept this upstream the port will also have to be buildable using the mingw-w64 cross-compiler and testable under Wine.

Links:

Details:

  • Skill level: intermediate
  • Language: C
  • Mentor: Richard W.M. Jones <rjones@redhat.com>
  • Suggested by: Richard W.M. Jones <rjones@redhat.com>

Rust bindings for libguestfs

Summary: Create Rust bindings for libguestfs

libguestfs is a library with tools to manipulate disk images. The C library has already lots of bindings, such as Python, Perl, Ruby, OCaml, etc.

The goal of this project is to add also bindings for Rust, extending the internal OCaml tool that generates most of the code needed for each binding, adding the manual bits needed for the Rust binding, and adding tests modelled after the ones already available for other bindings.

Links:

Details:

  • Skill level: advanced
  • Language: C, OCaml, Rust
  • Mentor: Pino Toscano <ptoscano@redhat.com>
  • Suggested by: Pino Toscano <ptoscano@redhat.com>

cloud-init for virt-install/virt-manager

Summary: cloud-init support for virt-install/virt-manager

Many vendors will provide pre-built disk images for running on public clouds. These typically have no ability to login by default, requiring use of cloud-init to pass in the desired root password or ssh public keys or networking details.

While these can be consumed in virt-install/virt-manager, it requires the user to manually prepare a cloud-init data source such as an ISO image. This is something that could usefully by done automatically by virt-manager/virt-install. They can collect a set of information from the user (password, ssh key) and combine it with some auto-determined information (networking config) and automatically expose this to the guest in a way that is consumable by cloud init, for example. Project may also involve teaching the tools how to automatically detect when they are passed a distro cloud image, so the tools can setup cloud-init data automatically.

Note: project mentors are looking for a self starter to lead experimenting and researching the best way to accomplish the goal. The end result may not be much code in the end, it's unclear. Some virtualization end user experience is recommended.

Links:

Details:

  • Skill level: intermediate
  • Language: Python, possibly C for libosinfo extension.
  • Mentor: Cole Robinson <crobinso@redhat.com> / Fabiano Fidêncio <fidencio@redhat.com>
  • Suggested by: Daniel Berrange