On 28/02/13 19:56, Laine Stump wrote: > On 02/27/2013 09:57 PM, TJ wrote: >> From: TJ <linux@xxxxxx> >> >> A DHCP relay daemon will be started that will forward all DHCP/BOOTP >> requests on the bridge network via the first declared forward >> interface. > > Okay, I think we've got our first candidate for something we might want > to configure. Picking the forward interface would probably be correct > 95% of the time, but it seems reasonable someone might want to forward > it somewhere else. Also there's the fact that most people don't define > any forward interface for their networks, just leaving it up to the > host's IP routing to determine the appropriate egress for every packet. > (I don't really like what's done with the forward interface anyway - it > doesn't do anything about routing to force traffic egress via that > particular interface, just rejects any traffic that would have gone out > a different interface). Are you thinking in terms of <dhcp relay='yes' forward='ethX'/> ? Should it be always explicit or use the current 'pick a sensible default' but allow this property to over-ride it? > >> The relay is broadcast rather than routed so no IP address >> is needed on the bridge. >> >> The XML <relay> element's "relay" property of the active DHCP stanza >> defaults to 'no'. Set it to 'yes' to enable the relay: >> >> <ip ...> >> <dhcp relay='yes'/> >> </ip> >> >> The relay will not be started if the "enable" property is 'no': >> >> <ip ...> >> <dhcp enable='no' relay='yes'/> > > I don't see the utility of that - it's the same as simply omitting the > <dhcp> element altogether. > The utility of the "enabled='(yes|no)'" properties is one of convenience for the sysadmin, and was something I felt in need of whilst testing many scenarios of dnsmaq *before* I embarked on this DHCP relay functionality, and again when I was testing dhcp-helper. Without needing to delete important sub-elements of <dhcp> (and lose through forgetting them) from an active network XML definition I could selectively switch a <dhcp> block on/off simply by adding the "enabled" property to the element. The alternative was continually having to switch amongst several network XML files all of which were permutations of the same settings in order that disabling a stanza in the primary XML didn't require needing to delete, for example, all the <host> and <range> sub-elements of <dhcp>. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list