Because of a missing dependency (net-misc/netcf), app-emulation/libvirt isn't fully functional at the moment. See also this mailinglist posting: https://www.redhat.com/archives/virt-tools-list/2009-December/msg00007.html This bug is intended to track the progress of getting netcf integrated in Gentoo. The current ebuild compiles + installs properly so far, but what's now missing, is netcf being able controlling network interfaces on Gentoo. I hope to figure out a clean approach during the next days - stay tuned. Reproducible: Always
Created attachment 212253 [details] ebuild for net-misc/netcf-0.1.5 The dependency >=app-admin/augeas-0.5.3 is currently only available through the 'dev-zero' repository.
Until now, there's unfortunately nearly no documentation at all, so here some links: Some configuration examples for netcf (XML): http://git.fedorahosted.org/git/?p=netcf.git;a=tree;f=tests/interface A blogpost about the netcf CLI tool (ncftool): http://linux-kvm.com/content/netcf-silver-bullet-network-configuration I'd appreciate if someone proficient with Gentoo's networking setup would step in to help a little bit.
Some more interesting information about netcf: http://fedoraproject.org/wiki/Features/Network_Interface_Management
Created attachment 212290 [details] ebuild for net-misc/netcf-0.1.5 ChangeLog * inheriting now the autotools eclass to handle the WANT_AUTOMAKE=1.11 dependency more properly * Installing the Augeas file now into the right destination path
Asked the netcf developers some questions regarding the usage + integration of netcf. Follow the thread for possible responses: https://fedorahosted.org/pipermail/netcf-devel/2009-December/000388.html
A few notes: - WANT_AUTOMAKE needs to go *before* the inherit line; - $ROOT in there is abused, since it's not used for prefixing; - ${D} usage must be quoted; - you can probably just move the directory most likely rather than its content; - COPYING in git at least says it's LGPL-2.1 not GPL-2.
Created attachment 212417 [details] ebuild for net-misc/netcf-0.1.5 (In reply to comment #6) > - you can probably just move the directory most likely rather than its > content; Doesn't work as the makefile does some nasty things here. > - COPYING in git at least says it's LGPL-2.1 not GPL-2. You're right - was misreading the license name... my failure Thanks a lot for your input!
Ah one thing I didn't note before; why are you inheriting autotools and depending on automake-1.11 if you're not calling the eauto* functions? If the sources from upstream produce maintainer-mode rebuilds (which means they are broken) you should run an explicit eautoreconf to make sure it doesn't run ./configure twice.
(In reply to comment #8) > Ah one thing I didn't note before; why are you inheriting autotools and > depending on automake-1.11 if you're not calling the eauto* functions? If the > sources from upstream produce maintainer-mode rebuilds (which means they are > broken) you should run an explicit eautoreconf to make sure it doesn't run > ./configure twice. Uuh, I'm confused ;-) I don't understand the autohell by far not enough to give you an answer here. I'm just using > WANT_AUTOMAKE=1.11 > inherit autotools because ./configure failed previously and the error message told me, that automake 1.11 would be required. Any chance you could take a look into this and fix the ebuild if necessary? Thanks!
Can you post a build log without automake-1.11 around? I'll be glad to pick it up from there :) For tonight I was irked by libvirt enough that I'd rather not look at more fedora software ;)
Created attachment 212423 [details] ebuild for net-misc/netcf-0.1.5 (In reply to comment #10) > Can you post a build log without automake-1.11 around? I'll be glad to pick it > up from there :) > > For tonight I was irked by libvirt enough that I'd rather not look at more > fedora software ;) > Sorry for bothering you - it seems this was a false alarm. I must have introduced this automake-1.11 dependency when playing around with autogen.sh in the git sources. The latest release works just fine with the default automake, so here's an updated ebuild from which I've stripped all the automake stuff.
netcf also depends on dev-libs/libxslt and dev-libs/libnl . After adding these dependencies to the ebuild it compiled fine.
The dependencies according to the spec file: BuildRequires: readline-devel augeas-devel >= 0.5.2 BuildRequires: libxml2-devel libxslt-devel BuildRequires: libnl-devel configure.ac wants at least 0.5.0 and the attached ebuild has 0.5.3.
I've added a masked netcf ebuild to the tree. Hopefully we can start working on official Gentoo support.
Are there any patches to send back to upstream netcf for this? I would really like to get official support for more distros into netcf (in such a way that someone could clone the git tree, then just do autogen.sh && make), and would be happy to provide any assistance needed to make that happen (in case it hasn't clicked, I'm the upstream maintainer for netcf ;-)
I have built netcf, and removed the option disabling netcf in libvirt, but virt-manager still says "libvirt connection does not support interface management" Is there something else I must do or configure to use the netcf functionality in virt-manager?
"removed the option disabling netcf in libvirt" by which I mean I changed the configure setting in libvirt's ebuild before building it
Reuben - I'm unfamiliar with the gentoo port of netcf (still waiting for patches to upstream :-), but can offer a few hints: 1) is netcf installed (not just built)? In particular, the equivalent of Fedora's "netcf-devel" package must be installed in order for libvirt's autogen to find it. If /usr/include/netcf.h exists, then you should be in good shape. 2) Look at the output of autogen and see what it says about netcf. That will tell you if it's even putting it in the build (if autogen doesn't find the libraries and .h file, it will disable netcf support and continue). 3) if it really is being built with netcf, possibly netcf itself is returning an error on init - try running "ncftool" from the shell to make sure netcf is functioning properly on its own. Oh, and BTW, netcf will only function when connecting to the "system" libvirt URL (eg, running virsh as root), because it requires root privileges. If it turns out the problem is that netcf support is being disabled in the libvirt build, even though netcf.h is in place, you could try asking about it on the libvirt developers' list - libvir-list@redhat.com. If netcf itself (ncftool, run as root) isn't working, probably the people Cc'ed to this bug report are the best ones to ask, although I wouldn't mind the discussion taking place on netcf-devel@lists.fedorahosted.org (as long as the involved gentoo people are subscribed, of course!). That would give more upstream folks (and those from other platforms) oppurtunity to offer advice, and may help promote getting gentoo-specifics into upstream sooner.
That's unlikely to work since libvirt is explicitly told to disable netcf support. $ grep netcf /usr/portage/app-emulation/libvirt/libvirt-*.ebuild /usr/portage/app-emulation/libvirt/libvirt-0.8.4.ebuild: myconf="${myconf} --without-netcf" /usr/portage/app-emulation/libvirt/libvirt-0.8.5-r1.ebuild: myconf="${myconf} --without-netcf --without-audit" It's fairly easy to enable netcf support to libvirt, but perhaps Laine can enlighten us if it's actually of any use since there's no gentoo backend. Btw, perhaps a gentoo backend could be based on the gentoo networkmanager plugin written as part of GSoC by qiaomuf (http://qiaomuf.wordpress.com/).
I had assumed that the ebuild of netcf had a backend, and that was the purpose of Reuben's exercise :-) As far as the idea of using NetworkManager for the backend, that could get tricky, as there is talk of changing NetworkManager to use netcf for its config-file needs (since netcf supports bridges/vlans/bonds while NetworkManager currently doesn't).
In reply to comment #18) > Reuben - I'm unfamiliar with the gentoo port of netcf (still waiting for > patches to upstream :-), but can offer a few hints: > > 1) is netcf installed (not just built)? In particular, the equivalent of > Fedora's "netcf-devel" package must be installed in order for libvirt's autogen > to find it. If /usr/include/netcf.h exists, then you should be in good shape. Yes, ebuilds basically automate both the build and system install process. (and in gentoo, include files are always installed for all packages since everything is built from source anyway) > > 2) Look at the output of autogen and see what it says about netcf. That will > tell you if it's even putting it in the build (if autogen doesn't find the > libraries and .h file, it will disable netcf support and continue). > > 3) if it really is being built with netcf, possibly netcf itself is returning > an error on init - try running "ncftool" from the shell to make sure netcf is > functioning properly on its own. > Doesn't seem to be: Failed to initialize netcf error: unspecified error > Oh, and BTW, netcf will only function when connecting to the "system" libvirt > URL (eg, running virsh as root), because it requires root privileges. I've only been messing with libvirt for a couple days and didn't realize it had a shell. I like. :) Beats having to modify my clunky management scripts each time I change something with the layout. What functionality within the shell does netcf interact with? I assume anything to do with interfaces? iface-list error: Failed to list active interfaces error: this function is not supported by the connection driver: virConnectNumOfInterfaces > > If it turns out the problem is that netcf support is being disabled in the > libvirt build, even though netcf.h is in place, you could try asking about it > on the libvirt developers' list - libvir-list@redhat.com. > > If netcf itself (ncftool, run as root) isn't working, probably the people Cc'ed > to this bug report are the best ones to ask, although I wouldn't mind the > discussion taking place on netcf-devel@lists.fedorahosted.org (as long as the > involved gentoo people are subscribed, of course!). That would give more > upstream folks (and those from other platforms) oppurtunity to offer advice, > and may help promote getting gentoo-specifics into upstream sooner. > (In reply to comment #19) > That's unlikely to work since libvirt is explicitly told to disable netcf > support. > $ grep netcf /usr/portage/app-emulation/libvirt/libvirt-*.ebuild > /usr/portage/app-emulation/libvirt/libvirt-0.8.4.ebuild: > myconf="${myconf} --without-netcf" > /usr/portage/app-emulation/libvirt/libvirt-0.8.5-r1.ebuild: > myconf="${myconf} --without-netcf --without-audit" > Yes, I had edited the ebuild to remove the "--without-netcf" option before I built it. > It's fairly easy to enable netcf support to libvirt, but perhaps Laine can > enlighten us if it's actually of any use since there's no gentoo backend. > > Btw, perhaps a gentoo backend could be based on the gentoo networkmanager > plugin written as part of GSoC by qiaomuf (http://qiaomuf.wordpress.com/). > Ah, that's probably the problem (or one of them). I've only recently been experimenting with virt-manager, and wasn't aware that the grunt work was passed off to a back-end.
While I said that I added a basic netcf ebuild to the tree, that doesn't mean libvirt can use it at all. netcf is merely a wrapper API around a distro's network configuration scripts. When I added the ebuild, there was no support for any Gentoo network configuration scripts in netcf. It would merely return unsupported for every API call. This in turn means that libvirt would function the same way as if netcf wasn't installed in the first place if you built libvirt with netcf support. I just looked at the upstream netcf project and it really appears to be pretty quiet. From the latest posts by the maintainers, it currently only supports RHEL6.x upstream (which I believe is based on Fedora 13) and they even had to drop RHEL5.x (Fedora 6) support which is pretty disheartening for a project that aims at maintaining an API for managing cross-distro network config script management. It appears that several people have been interested in implementing support for other distros (Debian, Ubuntu, SuSE, Slackware, Gentoo, Windows) but it doesn't appear much code has materialized on the development list. The code which has materialized hasn't been committed to their git repo. I was really hoping this project would take off and we could have an implementation for baselayout-2 and then provide command line tools to modify network setups on Gentoo. If someone still has some interest in this, I really urge you to make this a reality.
Doug, As the maintainer of netcf, I want to reiterate my willingness to help out in any way I can to get netcf ported to any other platform. Currently netcf is on RHEL6, and on Fedora since F12. As you say, the RHEL5 support is currently frozen at an older release - that was necessitated because RHEL5 is in a tightly locked down maintenance mode (especially since RHEL6 was released), and newer versions of netcf require libnl-1.1, which is ABI-incompatible with the libnl version in RHEL5 (1.0). Rebasing libnl to 1.1 would require upgrading all other packages in RHEL5 that depend on libnl, and that is considered too dangerous wrt stability at this stage in RHEL5's lifecycle. Although there have been several projects to port netcf to other platforms, none has sent significant patches upstream (although someone did make a SuSE port that they are using privately), and since my day job mandates that I spend most of my time directed towards RHEL and Fedora, I'm unable to do the ports myself. I have tried sending encouraging messages, and refactoring the code into a form that I *think* will make it easier to create a port, but have yet to see any fruit from this. This is unfortunate, because libvirt has chosen netcf as the way to configure physical host network interfaces, so virtual/cloud management systems that use libvirt are likely to use libvirt to configure the interfaces on their host farms. Right now this is not a total solution, leaving them to maintain kludge solutions on platforms other than RHEL, Fedora, and CentOS (CentOS6 will of course support netcf, when it is released). It is also unfortunate, because some of us see netcf as the way that NetworkManager could begin supporting bridge, bond, and vlan interfaces (rather than just (almost, but not quite) ignoring them, as it does now). But of course NetworkManager cannot use netcf until all the platforms supported by NetworkManager also have netcf. (On a personal level, this is very important to me, because I like using NetworkManager, but lack of support for bridges means I must have it disabled on machines that need a bridge device connected to a physical interface :-( ) For those reasons, even though I don't personally use gentoo, I would really like to see it fully support netcf. So what is needed to make that happen? Really just one person who understands how gentoo's network interface configuration works, and is willing/able to write some C code that converts between the XML descriptions consumed/produced by netcf, and gentoo's config file format (RHEL/Fedora use augeas for that, which is an option, but definitely not mandatory). (It would also be helpful if they could assist me in setting up a gentoo development vm so I can try things out for myself :-) Once that person steps up, I will do everything in my power to help the port along, change existing code to be a better fit, review the gentoo patches, and push them to the official netcf git. Whoever is interesting in doing this can either send email to netcf-devel@lists.fedorahosted.org, or to me personally (if they don't yet want to make a public commitment ;-)) Thanks for posting to the bug. Hopefully it will encourage some action!
Are there any new changes or workarounds possible at the moment? I tried to set it up, but networking seems to be still an issue under gentoo (portage's netcf ebuild is masked and this bugzilla case is referenced).
I've removed this package from the tree. It doesn't have Gentoo support and since I've added the udev backend a few years ago in libvirt, things are much better.
