On 10/31/2012 10:24 AM, Gene Czarcinski wrote: > On 10/30/2012 02:28 PM, Laine Stump wrote: >>> I now realize that I am going to need to get into virsh net-update >>> >since I am adding things to the xml specification and net-update will >>> >need to differentiate between dhcp4 and dhcp6 changes. >>> > >>> >Another thought that occurs to me is whether there has any >>> >consideration been given having a "virsh net-restart" which would just >>> >restart dnsmasq and radvd. Typing stuff in for the command line of >>> >net-update is a little prone to typos. >> You can always put them in (temporary) files:-) >> >>> > Wouldn't having net-edit and net-restart do what is intended for >>> >net-update. Maybe there is a way to have net-update do the equivalent >>> >of net-edit/net-restart. For example, if you only did "virsh >>> >net-update <network>" it would do it. > Oh so close and yet so far. > > I have given the man-page for net-update a closer reading and now > realize that I can use a terporary file and that scratch one of my > itches. As I read through that documentation I saw the --parent-index > which allows you to select which <ip> definition you are changing. That was the most troublesome part of that entire API, and I'm still not really happy with the way it works, but every other possibility we could think of had more problems. > Oh boy, this looks good. I can use that to select if I am updating > the ipv4 or ipv6 specification. Sounds good! Too bad it does not work > that way. You check the family and if it is not ipv4, you quit. 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. > > Going with a minimum change, I propose changing that test to allow > ipv4 or ipv6. Since those are the only two supported, and it has to be one or the other, just remove that part of the check. > > > BTW, there seem to be a number of things that do not work in > net-update. Aside from dns-host, is there anything else that is not > there yet? Look at the functions whose names start with virNetworkDefUpdate in network_conf.c. Those for not-yet-implemented sections will be a shell with just a call to virNetworkDefUpdateNoSupport(). As of today, these are implemented: ip-dhcp-host, ip-dhcp-range, forward-interface, and portgroup. The patchset that initially added the virNetworkUpdate API added the toplevel API itself, the backend infrastructure, and the specific function for as many of the defined sections as I could get implemented prior to the 0.10.2 release. The reason for this is that 1) the next release of Fedora 18 will be based on 0.10.2, 2) there will never be a full rebase to a newer libvirt, 3) new public APIs cannot be backported as individual patches, but 4) code that simply adds functionality in the backend *can* be backported to older releases as individual patches. So, by pushing the API plus backend for 4 essential sections (according to a couple people requesting the functionality), we were able to guarantee that the API would be available in Fedora 18. (If there had been more time before the 0.10.2 release, I would have implemented backends for more of the sections) > > Also, I am updating and re-basing my patches against v1.0.0-rc2. Is > that a good choice for now? You really should follow upstream git master rather than sticking to a particular snapshot. Any patches that you send to the list should be rebased to the head of git master anyway. Without exception, any patch that is applied to libvirt is first applied to the head of git master, and then later cherry-picked to one of the -maint branches for exporting to a distro build (at least this is the case for Fedora). Since you'll have to rebase to that eventually anyway, it's usually much easier to periodically rebase against git master as you go, and deal with small merge conflicts as they arise, rather than waiting until the end and suddenly having a large number of "conflicting conflicts" (or at least more confusing). -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list