Difference between revisions of "Google Summer of Code Ideas"

From Libvirt Wiki
Jump to: navigation, search
(add virt-bootstrap idea)
m (Drop the "Extend node device driver API set" project as it's no longer relevant)
 
(41 intermediate revisions by 10 users not shown)
Line 7: Line 7:
 
== Yearly programs ==
 
== Yearly programs ==
  
 +
* [[Google_Summer_of_Code_2019 | 2019]]
 +
* [[Google_Summer_of_Code_2018 | 2018]]
 
  * [[Google_Summer_of_Code_2017 | 2017]]
 
  * [[Google_Summer_of_Code_2017 | 2017]]
 
  * [[Google_Summer_of_Code_2016 | 2016]]
 
  * [[Google_Summer_of_Code_2016 | 2016]]
Line 41: Line 43:
 
* Skill level: beginner
 
* Skill level: beginner
 
* Language: C
 
* Language: C
* Suggested by: Daniel Berrange
+
* Mentor: Pavel Hrdina <phrdina@redhat.com>, phrdina on IRC (#virt OFTC)
 
 
=== Integrate secrets driver with <s>DEO</s> Tang/Clevis ===
 
 
'''Summary:''' Provide encryption of secrets stored by libvirt, optionally using <s>DEO</s> Tang/Clevis to unlock the master key
 
 
The libvirt secrets driver currently stores secrets in base64 plain text files with the recommendation that the filesystem be backed by a LUKS encrypted block volume. This provides protection against offline compromise, but is far from ideal. Libvirt should have its own master AES key that it uses to encrypt the individual secrets files, instead of storing them in base64.
 
 
 
Of course there is a chicken & egg problem of how to store the master AES key itself. For this we should have the ability to integrate with <s>DEO</s> Tang/Clevis to allow the master key to be password protected on local node, having <s>DEO</s> Tang/Clevis decrypt it at libvirtd startup.
 
 
'''Links:'''
 
* https://blog-ftweedal.rhcloud.com/2016/02/introduction-to-tang-and-clevis/
 
* https://github.com/npmccallum/clevis
 
* https://github.com/npmccallum/tang
 
* <s>https://blog-ftweedal.rhcloud.com/2015/09/automatic-decryption-of-tls-private-keys-with-deo/</s>
 
* <s>https://github.com/npmccallum/deo</s>
 
 
'''Details:'''
 
* Skill level: intermediate
 
* Language: C
 
* Mentor:
 
 
* Suggested by: Daniel Berrange
 
* Suggested by: Daniel Berrange
  
Line 83: Line 65:
 
=== libvirt bindings for node.js ===
 
=== 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.
+
'''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
 
* Component: libvirt
 
* Skill level: advanced
 
* Skill level: advanced
* Language: C, C++, node-gyp, scripting language of your choice
+
* Language: C, node.js
* Mentor: Martin Kletzander <mkletzan@redhat.com>
 
 
* Suggested by: Martin Kletzander <mkletzan@redhat.com>
 
* Suggested by: Martin Kletzander <mkletzan@redhat.com>
  
 
'''Links:'''
 
'''Links:'''
* node-gyp: https://github.com/nodejs/node-gyp
+
* https://github.com/RamyElkest/libvirt-node
  
 
=== QEMU command line generator XML fuzzing ===
 
=== QEMU command line generator XML fuzzing ===
Line 105: Line 86:
 
* Language: C
 
* Language: C
 
* Mentor:  
 
* Mentor:  
* Suggested by: Daniel Berrange
 
 
=== Conversion to and from OCI-formatted containers ===
 
 
'''Summary:''' Container formats is being standardized by [https://www.opencontainers.org Open Container Initiative]. libvirt-lxc support for them would be awesome.
 
 
virsh has domxml-from-native and domxml-to-native to help converting between libvirt configuration and another one. In the libvirt-lxc driver the domxml-from-native command already supports converting from [https://linuxcontainers.org/ lxc] (yes, naming is confusing). The goal is not only to implement it also for [https://github.com/opencontainers/specs OCI format] but also to implement export to OCI format.
 
 
Some code pointers to get started:
 
* [http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/lxc/lxc_native.c src/lxc/lxc_native.c] is the place where the lxc import is implemented.
 
* The starting point in the lxc driver is the [http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/lxc/lxc_driver.c#l5815 connectDomainXMLFromNative] function pointer.
 
* To add export capabilities, the [http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/driver-hypervisor.h#l282 connectDomainXMLToNative] will have to be defined.
 
 
Note that there may be tricky things to handle, like disk images conversion to a rootfs, but this project aims at implementing the simple cases first. If time permits, the corner cases could be handled as well.
 
 
'''Details:'''
 
* Component: libvirt
 
* Skill level: intermediate
 
* Language: C
 
* Mentor: Cédric Bosdonnat <cbosdonnat@suse.com>
 
* Suggested by: Cédric Bosdonnat
 
 
=== Introduce libiscsi pool ===
 
 
'''Summary:''' Currently there is an iSCSI storage pool in libvirt. However, all the management communication is done by spawning iscsiadm binary. The aim of this project would be to rework the storage driver backend so that is uses libiscsi directly.
 
 
Libvirt has many drivers to address various parts of virtualization infrastructure. For example, it has so called domain driver which is responsible for managing virtual machines, network driver for providing connectivity to virtual machines and it has storage driver for managing storage pools and volumes. The enumeration is not complete, of course. The aim of the storage driver is to provide units of storage to virtual machines. In order to achieve that goal, the storage driver offers several APIs for management applications to use, e.g. creating a pool of volumes, creating a single volume within that pool and so on. Because of the nature of storage world, the driver has many backends which implement the APIs based on underlying storage technology used. Thus there's an LVM backend for managing LVs, FS backend for working with files and directories, and there's iSCSI backend too. This backend, however, uses iscsiadm binary to execute the desired operation. The binary can be spawned multiple times during single execution of an API. This is suboptimal esp. if there exists a better solution - libiscsi. This should be 1:1 replacement, but that's only an uneducated guess. Student working on this project should explore the possibilities of doing the replacement and implement it as well.
 
 
'''Links:'''
 
* http://libvirt.org/storage.html
 
* https://github.com/sahlberg/libiscsi
 
 
'''Details:'''
 
* Skill level: intermediate
 
* Language: C
 
* Mentor: Pavel Hrdina <phrdina@redhat.com>
 
* Suggested by: Jiri Denemark <jdenemar@redhat.com>
 
 
=== Enhancing libvirt-designer ===
 
 
'''Summary:''' The project is in its very early stage of life. The libvirt-designer tries to ease generation of libvirt XML with coworking with libosinfo project. See https://www.redhat.com/archives/libvir-list/2012-September/msg00325.html for a more detailed description.
 
 
During Summer of Code 2015, new API was added to make it possible to configure more VM details. This project would be a follow-up on that work, this could be :
 
* switch GNOME Boxes to using libvirt-designer instead of its own code when creating a VM. This involves work in Vala for the Boxes side, and in C on the libvirt-designer side
 
* improve libvirt-designer to make it appropriate for use by virt-manager/virt-install (written in Python)
 
* work on both libvirt-designer and libvirt-builder, with the aim of creating a command-line tool to automatically create and install a VM (through libosinfo).
 
 
Contact me and we can refine these potential tasks and find something suitable.
 
 
'''Details:'''
 
* Skill level: beginner
 
* Language: C, (potentially Python, Vala)
 
* Mentor: Christophe Fergeau <cfergeau@redhat.com>, teuf on IRC (#qemu-gsoc OFTC)
 
* Suggested by: Christophe Fergeau <cfergeau@redhat.com>
 
 
=== 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:'''
 
* API coverage http://libvirt.org/hvsupport.html
 
* Test driver http://libvirt.org/drvtest.html
 
 
'''Details:'''
 
* Skill level: beginner
 
* Language: C
 
* Suggested by: Daniel Berrange
 
 
=== Automatic freeing of memory ===
 
 
'''Summary:''' Implement <code>__attribute__((cleanup))</code> for libvirt.
 
 
Both gcc and clang implement the <code>__attribute__((cleanup))</code> which
 
triggers give function call whenever variable marked with this attribute goes
 
out of the scope. This can be used to automatically free the memory as soon as
 
the variable is no longer needed and thus prevent some types of memory leaks.
 
 
This attribute is used by plenty of other projects.
 
 
'''Links:'''
 
* https://www.redhat.com/archives/libvir-list/2017-January/msg00323.html
 
 
'''Details:'''
 
* Skill level: beginner
 
* Language: C
 
* Mentor:
 
 
* Suggested by: Daniel Berrange
 
* Suggested by: Daniel Berrange
  
Line 218: Line 111:
 
=== Metadata support for all object schemas ===
 
=== Metadata support for all object schemas ===
 
   
 
   
'''Summary:''' Extend the domain XML <metadata> concept to 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.
 
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.
Line 239: Line 132:
 
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
 
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
+
* 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 vir{OBJECT}SetMetadata & vir{OBJECT}GetMetadata public APIs for each object
- Add async event callback for each object to notify of changes
+
* 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.
 
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.
Line 247: Line 140:
 
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.
 
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:'''
+
'''Links:'''
 
   
 
   
'''Details:'''
+
'''Details:'''
* Skill level: beginner
+
* Skill level: beginner
* Language: C
+
* Language: C
* Suggested by: Daniel Berrange
+
* Suggested by: Daniel Berrange
  
=== Ease creation of containers ===
+
=== Redfish API implementation ===
 
   
 
   
'''Summary:''' Creating containers for libvirt LXC driver is a pain since there is no simple way to setup the root file system. A new workflow around container images is presented in http://bosdonnat.fr/system-container-images.html. This project is about moving the ''virt-bootstrap'' tool further, that is add more features to it and integrate it with ''virt-manager'' and ''virt-install'' for a smooth user experience.
+
'''Summary:''' [https://redfish.dmtf.org/ 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 [http://flask.pocoo.org/ Flask] given it's simplicity.
 +
 +
'''Links:'''
 +
* [https://redfish.dmtf.org/ Redfish Developer Hub] contains all resources to understand the API
 +
* Redfish [https://git.openstack.org/cgit/openstack/sushy/tree/tools/mockup_server_libvirt/mockup_server_libvirt.py?id=d377b545a03c20c58e359bc7c7cf4ecc4ae8ff61 libvirt mockup in sushy]
 +
* OpenStack Redfish hardware driver spec: https://specs.openstack.org/openstack/ironic-specs/specs/8.0/ironic-redfish.html
 +
* Started implementation: https://github.com/jloeser/bluebird
 +
 +
'''Details:'''
 +
* Skill level: beginner
 +
* Language: python
 +
* Suggested by: Cédric Bosdonnat
 +
 
 +
=== Add support for live migration of LXC containers ===
 
   
 
   
So far the virt-bootstrap tool is in a rather primitive state. It's sources should be cleaned up to be ready for merge in virt-manager sources. The virt-manager UI will have to be modified to fully use this new tool.
+
'''Summary:''' Add support for live migration of LXC containers using [https://github.com/checkpoint-restore/criu 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.
  
The virt-bootstrap tool would need the following features to be added:
+
During GSoC 2016, [https://wiki.libvirt.org/page/Google_Summer_of_Code_2016/lxc_migration 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.
  
* Handle more sources format (virt-builder, Live DVD isos...)
+
'''Links:'''
* Provide several output formats: folder (done), qcow2 with backing chains
+
* https://wiki.libvirt.org/page/Google_Summer_of_Code_2016/lxc_migration
 +
* https://criu.org/CLI/opt/--remote
 +
* https://criu.org/Image_cache/proxy_TODO
 +
 
 +
'''Details:'''
 +
* Component: libvirt
 +
* Skill level: intermediate
 +
* Language: C
 +
* Mentor:
 +
* Suggested by: Cédric Bosdonnat
  
The project will also study how to produce a user-namespace-ready root file system.
+
=== 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:'''
 
'''Links:'''
* virt-bootstrap current code: https://github.com/cbosdo/virt-bootstrap
+
* https://github.com/rwmjones/nbdkit/tree/windows
* virt-manager git repository: https://github.com/virt-manager/virt-manager
+
* https://github.com/libguestfs/nbdkit
 
   
 
   
 
'''Details:'''
 
'''Details:'''
* Skill level: beginner
+
* Skill level: intermediate
* Language: Python
+
* Language: C
* Mentor: Cédric Bosdonnat <cbosdonnat@suse.com>, cbosdonnat on IRC (#virt OFTC)
+
* Mentor: Richard W.M. Jones <rjones@redhat.com>
* Suggested by: Cédric Bosdonnat <cbosdonnat@suse.com>
+
* Suggested by: Richard W.M. Jones <rjones@redhat.com>
 +
 
 +
=== Take migration in Salt virt module to the next level ===
 +
 +
'''Summary:''' Salt [https://docs.saltstack.com/en/develop/ref/modules/all/salt.modules.virt.html#salt.modules.virt.migrate virt.migrate] needs to be reworked to better cover the libvirt API
 +
 
 +
Salt offers a nice wrapper around libvirt. However the migration functions are calling virsh and not exposing all options. This project is about rewriting the salt migration functions to use the python-libvirt API, but also to expose as much as possible of the libvirt migration options.
 +
 
 +
Salt also allows users to describe the guests using a state. Once the migration functions are exposed, the [https://docs.saltstack.com/en/latest/ref/states/all/salt.states.virt.html#salt.states.virt.running virt.running] state would need to be modified to handle migrating the guest to another host.
 +
 
 +
'''Links:'''
 +
* [https://docs.saltstack.com/en/latest/topics/tutorials/states_pt1.html Salt states tutorial]
 +
* [https://github.com/saltstack/salt/blob/master/salt/modules/virt.py virt module's code]
 +
* [https://github.com/saltstack/salt/blob/master/salt/states/virt.py virt state's code]
 +
 +
'''Details:'''
 +
* Skill level: intermediate
 +
* Language: Python.
 +
* Mentor: Cédric Bosdonnat <cbosdonnat@suse.com>
 +
* Suggested by: Cédric Bosdonnat

Latest revision as of 11:09, 26 August 2020

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
  • 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:
  • Suggested by: Cédric Bosdonnat

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>

Take migration in Salt virt module to the next level

Summary: Salt virt.migrate needs to be reworked to better cover the libvirt API

Salt offers a nice wrapper around libvirt. However the migration functions are calling virsh and not exposing all options. This project is about rewriting the salt migration functions to use the python-libvirt API, but also to expose as much as possible of the libvirt migration options.

Salt also allows users to describe the guests using a state. Once the migration functions are exposed, the virt.running state would need to be modified to handle migrating the guest to another host.

Links:

Details:

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