[libvirt-users] network configuration for guest specific dns-servers

[Laine Stump]

On 08/31/2017 08:17 AM, Martin Kletzander wrote:
> On Thu, Aug 31, 2017 at 01:09:14PM +0200, David Ayers wrote:
>> Am Donnerstag, den 31.08.2017, 11:32 +0200 schrieb David Ayers:
>>>
>>> Am Donnerstag, den 31.08.2017, 10:11 +0200 schrieb Martin Kletzander:
>>> >
>>> > AFAIK the support for this was not added.  Feel free to request
>>> this in
>>> > our bugzilla [1] so that we can track it.  Or, even better, send a
>>> patch
>>> > if you have some time ;) It should not be difficult.
>>>
>>> Okay, I'll be sure to add it to bugzilla sometime soon.
>>
>> Actually, this was already reported (on the last day of 2010):
>> https://bugzilla.redhat.com/show_bug.cgi?id=666556
>> and seems to restated (two years later) in:
>> https://bugzilla.redhat.com/show_bug.cgi?id=824573
>>
>> and by the looks of this, generic dhcp options at global scope are
>> already contentious, let alone at host scope.
>>
>> So I guess we my stop configuring dnsmasq via libvirt.
>>
>
> Oh, look at that.  It's good that you've found it.  Of course there are
> people more proficient in the networking area who have way more thing on
> their radar.  Looks like this is very often requested thing also.  I
> can't speak for arbitrary options, but named ones that we know what to
> map them to, should be fine and not rejected (at least not right away).
> But others (especially Laine; Cc'd) could be more specific WRT your
> request.

The first attempt at this was really just a passthrough for dnsmasq
commandline options, and as such was ripe with potentials for ambiguous
interpretation (when certain special characters were present),
idiosyncracies specific to dnsmasq's implementation details, etc, so we
pulled it out to re-tool, but I think I tried to be too ambitious about
the design, and so it stagnated rather than proceeding with something
simple but expandable.

What we need is for someone with enough vested interest to map out the
proper XML structure to allow supporting all dhcp options, and then
someone to write the support for the first example dhcp option. After
that, new options could be added as needed. The bit that produces the
reluctance to start is that we need to be sure that whatever we setup
for the initially-supported options needs to be expandable to work for
all options. (I tried to map out such a beast, and it was just too much
work vs. other more pressing things). If somebody wants to pick it up,
I'd be happy to offer my advice/opinions :-)