Plan A or Plan B?

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

 



Plan A:

This consists of the set of patches I have submitted for conf-file, DHCPv6, etc. The response has been a resounding SILENCE. Thus, I am assuming that there is some reluctance to adopting these changes in their current form. This especially includes the conf-file changes. While I believe that changing dnsmasq parameters from the command-line to a configuration file makes a great deal of sense and might have been the approach if this was being done today, there is resistance to change.

OK, so here is Plan B:

I am removing the conf-file and related changes. They will be repackaged and resubmitted at some later time. The new multi-file patch will focus on "IPV6 Enhanced Support" which will consist of the following:

1. In a manner similar to what is done for IPV6, add ip6tables rules to permit virtual systems to communicate via a defined virtual interface which has no gateway addresses defined. This does mean that virtual systems will not be able to communicate with the host via this interface ... only with each other. Also, the following must be:
      net.ipv6.conf.virbr19.disable_ipv6 = 1
so that the kernel does not start anything.

This implements IPv6 functionality currently available for IPv4.

Documentation will be added to explain the functionality for both IPv4 and IPv6.

[BTW, the only place I have found to add documentaiotn is in the "docs/formatnetwork.html.in" file. If there are other files I should be updating, please enlighten me.]

2. Add code to get the dnsmasq version and save that information. The added code described below will require a dnsmasq version greater than or equal to 2.64. Documentation will be updated to state that dnsmasq >= 2.64 is required for DHCPv6.

3. Implement support for DHCPv6. Most of this is already done with the existing patch. However, this refits the code to work with command-line parameters AND adds a check for dnsmasq >= 2.64. Naturally, tests and documentation will be updated.

4. If dnsmasq >= 2.64, do not use radvd but instead use dnsmasq to support the RA service for both state-full and state-less IPV6.

OPTIONS:
========
a) If dnsmasq < 2.64, just ignore dhcp-range or dhcp-host definitions

OR

b) issue error message and stop dnsmasq startup if dhcp-range or dhcp-host is specified.
========
c) Currently, tests for valid dhcp specifications is only done when a network is started (all significant changes are to "network/bridge_driver.c". This situation could continue. Thus, virsh could be used to specify dhcp-range and dhcp-host but it would not work if the network was started.

OR

d) Move the dnsmasq version checks back into when the network is defined. This would be a bit "trickier" to implement properly since the same code is used by multiple network types and not just that supported by "network/bridge_driver.c". If this is the approach, I will need some guidance as to modifying "conf/network.c".

OK folks. I need some input here. I realize that all of you are very busy working your own interests but I need a little time from someone with "commit" authority to say "go ahead" or "get lost".

Gene

--
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]