[libvirt] dhcp6, radvd, ip6tables, etc. (update)

[Laine Stump]

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).