Toggle the table of contents

Outreach Program for Women 2014 DecemberMarch: Difference between revisions

From QEMU

Latest revision as of 01:32, 5 September 2014

Introduction

QEMU is seeking funding to participate as a mentoring organization for Outreach Program for Women 2014 December-March. This page contains our ideas list and information for candidates and mentors.

Next deadline: September 8 for initial list of project ideas and mentors.

Find Us

IRC (OPW & GSoC specific): #qemu-gsoc on irc.oftc.net

IRC (development):
- QEMU: #qemu on irc.oftc.net
- libvirt: #virt on irc.oftc.net
- KVM: #kvm on chat.freenode.net

Mailing lists:
- QEMU: qemu-devel
- libvirt: libvir-list
- KVM: linux-kvm

Please contact the mentor for the project idea you are interested in. IRC is usually the quickest way to get an answer.

For general questions about QEMU in GSoC, please contact the following people:

Stefan Hajnoczi (stefanha on IRC)

How to get familiar with our software

See what people are developing and talking about on the mailing lists:

Grab the source code or browse it:

Build QEMU and run it: QEMU on Linux Hosts

Project Ideas

This is the listing of suggested project ideas. Candidates are free to suggest their own projects by emailing qemu-devel@nongnu.org and (optionally) CCing potential mentors.

Note: These project ideas are also available to candidates applying for Outreach Program for Women.

QEMU projects

qemu-img new subcommand "dd"

Summary: Add "qemu-img dd" subcommand.

dd(1) is a powerful tool to work on binary files, while qemu-img(1) has the knowledge of many image formats (qcow2, vhdx, vdi, vmdk, etc.) and protocols (nfs, iscsi, gluster, ssh, etc.). If we put them together, we'll have the power of dd to work on all the qemu-img supported images, and even pipe it through any host side utilities, such as grep(1), xxd(1), or pipe it to a streaming compress utility such as xz. It will be a convenient tool to read, stream and modify guest data without invocation of a live vm (by running qemu or libguestfs).

Currently qemu-img has following subcommands:

Command syntax:
 check [-q] [-f fmt] [--output=ofmt] [-r [leaks | all]] [-T src_cache] filename
 create [-q] [-f fmt] [-o options] filename [size]
 commit [-q] [-f fmt] [-t cache] filename
 compare [-f fmt] [-F fmt] [-T src_cache] [-p] [-q] [-s] filename1 filename2
 convert [-c] [-p] [-q] [-n] [-f fmt] [-t cache] [-T src_cache] [-O output_fmt] [-o options] [-s snapshot_id_or_name] [-l snapshot_param] [-S sparse_size] filename [filename2 [...]] output_filename
 info [-f fmt] [--output=ofmt] [--backing-chain] filename
 map [-f fmt] [--output=ofmt] filename
 snapshot [-q] [-l | -a snapshot | -c snapshot | -d snapshot] filename
 rebase [-q] [-f fmt] [-t cache] [-T src_cache] [-p] [-u] -b backing_file [-F backing_fmt] filename
 resize [-q] filename [+ | -]size
 amend [-q] [-f fmt] [-t cache] -o options filename

Note that we don't have to port the code from "dd", or try to support all the features. A similar user interface is good enough.

Links

Details:

Skill level: beginner
Language: C
Mentor: Fam Zheng <famz@redhat.com>, fam on IRC

KVM projects

Libvirt projects

More intelligent virsh auto-completion

Even though there's already some auto-completion in virsh, it is not enough. For better user experience, virsh should auto complete objects to virsh commands, e.g. "start <TAB><TAB>" lists not only options that the start command knows, but list of inactive domains as well. Moreover, the same applies to command options. There already has been some attempts that can be taken as starting point.

Some useful threads to read before trying this: [1] [2] [3] [4]

Skill level: beginner

Introducing job control to the 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.

Skill level: intermediate

Your own idea

Just catch me (Michal Privoznik) on IRC and we can discuss what interests you.

Links:

Details:

Component: libvirt
Skill level: (see description to each item)
Language: C
Mentor: Michal Privoznik <mprivozn@redhat.com>, mprivozn on IRC (#virt OFTC)
Suggested by: Michal Privoznik <mprivozn@redhat.com>

Abstracting device address allocation

Summary: There are many types of addresses that devices can have in libvirt's XML description. Not all address types are properly assigned and checked for duplicates. The goal of this is to have an abstract data structure that would handle assigning all kinds of addresses, handle duplicates, etc.

Links:

Details:

Skill level: beginner
Language: C
Mentor: Martin Kletzander <mkletzan@redhat.com>; mkletzan on IRC (OFTC and freenode)
Suggested by: Martin Kletzander

Admin interface APIs

Summary: We are currently working on an administrative interface for the libvirt daemon. This interface will be able to probe and change daemon settings live. Since this is going to be a new interface, there needs to be new APIs implemented. These APIs may do various interesting things strarting from showing the current logging filters up to force-disconnecting clients with certain properties. It is up to you what you would like to add, but of course this needs to be discussed and agreed on with the community.

Links:

Details:

Skill level: intermediate
Language: C
Mentor: Martin Kletzander <mkletzan@redhat.com>; mkletzan on IRC (OFTC and freenode)
Suggested by: Martin Kletzander

Project idea 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
 * Mentor: Email address and IRC nick
 * Suggested by: Person who suggested the idea

Information for mentors

Mentors are responsible for keeping in touch with their candidate and assessing the candidate's progress.

The mentor typically gives advice, reviews the candidate's code, and has regular communication with the candidate to ensure progress is being made.

Being a mentor is a significant time commitment, plan for 5 hours per week. Make sure you can make this commitment because backing out during the summer will affect the candidate's experience.

The mentor chooses their candidate by reviewing candidate application forms and conducting IRC interviews with candidates. Depending on the number of candidates, this can be time-consuming in itself. Choosing the right candidate is critical so that both the mentor and the candidate can have a successful experience.

Retrieved from "https://wiki.qemu.org/index.php?title=Outreach_Program_for_Women_2014_DecemberMarch&oldid=4351"