Two more libvirt GSOC ideas

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,
I'd like to add 2 more GSOC ideas to our wiki page, but I'd like to get some
opinions whether you think these might even be appropriate GSOC project
candidates.

#1
PROJECT:
Support wildcard with log filters

SUMMARY:
Enhance the log filters format to allow specifying a wildcard, i.e. <level>:*

DESCRIPTION:
Currently, libvirt admin interface allows (among other things) runtime tuning
of daemon log settings with the exception of setting the global log priority.
The main reason for not having an API to get/set the global log priority is that
the same effect that setting global log level would have can be achieved with
using log filters only which in terms of logging control provide us with more
granularity. However, in order to achieve the same effect using filters only,
one would end up with a filter similar to this:

1:access 1:daemon 1:conf 1:cpu 1:libvirt 1:locking 1:logging 1:network
1:nwfilter 1:util

Therefore, we should enhance the format of a filter to allow us to simply use
the following instead:

1:* other_filters


#2
PROJECT:
Extend node device driver's API set

SUMMARY:
Modify the existing set (adjust/add) of APIs for node device driver in order to
provide similar functionality (conceptually) to other drivers.

DESCRIPTION:
The node device driver is responsible for host device management. In most
cases, this means that we're simply just 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 our current code base. Not all of the changes mentioned
above are absolutely necessary to finish the project successfully.

Thanks,
Erik

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux