On 11/01/2012 06:53 AM, Gene Czarcinski wrote: > On 10/31/2012 09:50 PM, Laine Stump wrote: >> On 10/31/2012 03:11 PM, Gene Czarcinski wrote: >>> On 10/31/2012 11:53 AM, Laine Stump wrote: >>>> That's just a safeguard to enforce the ipv4-only status of dhcp in the >>>> current libvirt. Just remove that restriction from the function >>>> virNetworkDefUpdateIP() as a part of your patch adding ipv6 dhcp >>>> support. >>>> >>> OK, removing the ipv4 test has net-update ipv6 working as well as ipv4 >>> does. >>> >>> Observation: this is definitely a work-in-progress. I only tried >>> ip-dhcp-range and ip-dhcp-host. The ip-dhcp-range produced the >>> expected in the the xml was updated and dnsmasq was restarted. With >>> ip-dhcp-host, it only did the right thing if the network was down. If >>> it was started, nothing much happened. >> Most likely because, according to what you recently wrote, the dhcp >> hosts file isn't reread when a SIGHUP is sent to dnsmasq. > With the network started, I tried editing its definition and adding > dns host definitions, when I saved I got a message in syslog that the > network was defined [networkCreate() had executed]. No. If you edit a running network, the definition is updated on disk, but nothing else is (should be) done - it waits until the next start of the network. What you are seeing is the effect of executing networkDefine(), not networkCreate(). (I had assumed you were trying to do net-update to add a dhcp static host, not using net-edit. The changes in net-edit are *only* in the persistent config on disk, and should never take effect until the network is restarted. This is identical behavior to editing a guest's config, and is that way be design.) > There is code in networkCreate() to go through and crate/update the > addnhosts and hostsfile which was done. There is code in networkDefine() to do that as well. It shouldn't be there though - it should only be done when the network is started. Peter Krempa recently sent a patch to fix this: https://www.redhat.com/archives/libvir-list/2012-October/msg01495.html but it hasn't yet been pushed due to the freeze. > However, no SIGHUP was issued. I then did a SIGHUP manually and the > files were re-read. Okay, then net-update should work properly. The rule to remember - if you want a change to take effect immediately (and potentially be persistent across network restarts), use net-update. If you can wait / want to wait until the next time the network is restarted for the change to take effect, you can use net-edit (but can also use net-update with that effect). >> >>> A suggestion, before F18 goes with 0.10.2, I suggest that the virsh >>> man-page be updated. Currently, you would think that all of the stuff >>> worked. Clearly, it does not. At best, users will be confused. I >>> suggest listing the functions that are planned but not currently >>> implemented. >> A valid point. >> >> Note that it's not vanilla 0.10.2 that's currently in F18, it's the >> 0.20.2-maint branch, which is 0.10.2 plus some bugfixes deemed worthy of >> backporting. Patches can be added to that branch at any time during the >> lifetime of F18 (and even beyond if some other distro is using that >> release for their builds), but they are only bugfixes (adding the >> backend for missing sections could be seen as fixing a bug, if we >> *really* wanted to :-). > I guess I like being a little more straight-forward with the > user/customer. I didn't say it wouldn't be useful to document which sections aren't yet implemented, just gave an explanation of how/why the code has eneded up where it is, and what might happen to it in the future; if there is enough demand from (for example) F18 users for the other sections to be complete, we have the ability to update it. If we hadn't done it this way and instead waited until all the sections were implemented and tested before pushing any of them, net-update wouldn't exist at all in F18, and there would be 0 possibility of adding it (because F18 won't rebase to a newer libvirt, and you can't backport API changes to an older libvirt version - not because we just don't want to, but because the library versioning stuff can't handle that.) >> >>> Speaking of documentation. This should be updated for DHCPv6: >>> http://libvirt.org/http://libvirt.org/formatnetwork.html and there is >>> docs/http://libvirt.org/formatnetwork.html.in in the git. However, it >>> is not clear what the process is for changing/updating the >>> documentation. >> Just edit formatnetwork.html.in and make that edit a part of the same >> patch that makes the new functionality available. Your patch would be >> NACKed without that anyway. >> >>> Doing a grep on the log does not show a lot of commits being performed >>> on it. >> Any change to the network XML is not accepted for a push unless a change >> to formatnetwork.html.in accompanies it. Any low patch volume on the >> file is due to there being infrequent changes in the XML. > OK, one more thing on the todo list. I plan to use seamonkey or maybe > Libreoffice to do the editing. Any comments/suggestions? I think everybody just edits the text directly with emacs or whatever. I would be concerned about a higher level tool reformatting everything and creating huge diffs for tiny changes. > Any other files I should look at for appropriate change documentation? If you want to look for an appropriate place on the libvirt wiki to add a section (or update an existing section) that might be nicem but not necessary. > >> >>> While a lot of using IPv6/DHCP6 is straight-forward, there are a >>> couple of twists such as not specifying a MAC address for a v6 >>> dhcp-host specification. >>> >>> I know there is some touchiness about this so I am thinking of adding >>> a "special xml keyword" which would switch between radvd and dnsmasq. >> I'm not sure whether that would be appropriate, or to instead have an >> autoconf option that would enact the change at compile time. > If use/non-use of radvd is an issue on different systems, then an > autoconf options is the way to go. For testing purpose (not really > for submission) is the ablity to have one interface use dnsmasq only > which another interface uses radvd & dnsmasq ... this was intended for > testing only to make sure that things worked properly. >> >>> >>> BTW, I am assuming this is all post v1.0.0. >> We've been in freeze for the last week, and at this point only simple >> fixes to very serious bugs are being pushed. New functionality is >> definnitely post-1.0.0 >> >>> I have currently completed the dhcp6 patch (net-update was the last >>> piece) but I need to let things work for a while to see if I missed >>> anything. If anyone wants to look at these patches, I can post them >>> to this list or send them direct. However, I want to wait until >>> v1.0.0 gets released before submitting them for review, etc. >> You can submit things for review now, they just won't be pushed until >> after the release is cut. > I think I want to do a bit more polishing (and updating documentation) > before actually submitting. > > As things now stand, there are three patches with a forth planned for > documentation: > 1. put dnsmasq parameters into a file. > 2. add interface= to dnsmasq parameters I thought Simon had determined that to be a non-issue for libvirt's use case. Is there still some advantage to it? (Although I tried it all the way back to REHL5 with no problems encountered, several of us have a vague memory that it had caused some kind of problem, so we'd rather avoid applying it unless there is a tangible benefit) > > 3. add support for dhcp6 > > Anything involving radvd vs dnsmasq would be a separate issue, > separate patch, although it would depend on the above patches. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list