[libvirt-users] network configuration for guest specific dns-servers
Hello, similar to how one can configure guest specific IP addresses via mac addresses: <ip address="192.168.122.1" netmask="255.255.255.0" localPtr="yes"> <dhcp> <range start="192.168.122.100" end="192.168.122.254"/> <host mac="00:16:3e:77:e2:ed" name="foo.example.com" ip="192.168.122.10"/> <host mac="00:16:3e:3e:a9:1a" name="bar.example.com" ip="192.168.122.11"/> </dhcp> </ip> We would like to configure guest specific dns-servers as would be done with the --dhcp-option of dnsmasq. I was expecting to be able to do something like: <host mac="00:16:3e:77:e2:ed" name="foo.example.com" ip="192.168.122.10" dhcp-option="dns-server,127.0.0.1" /> but it seems that this isn't the correct approach, as virsh net-edit default removes that attribute definition. Could someone point me to the correct documentation? Thank you! David Ayers -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate)
On Thu, Aug 31, 2017 at 12:10:22AM +0200, David Ayers wrote:
Hello,
similar to how one can configure guest specific IP addresses via mac addresses: <ip address="192.168.122.1" netmask="255.255.255.0" localPtr="yes"> <dhcp> <range start="192.168.122.100" end="192.168.122.254"/> <host mac="00:16:3e:77:e2:ed" name="foo.example.com" ip="192.168.122.10"/> <host mac="00:16:3e:3e:a9:1a" name="bar.example.com" ip="192.168.122.11"/> </dhcp> </ip>
We would like to configure guest specific dns-servers as would be done with the --dhcp-option of dnsmasq. I was expecting to be able to do something like:
<host mac="00:16:3e:77:e2:ed" name="foo.example.com" ip="192.168.122.10" dhcp-option="dns-server,127.0.0.1" />
but it seems that this isn't the correct approach, as virsh net-edit default removes that attribute definition.
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.
Could someone point me to the correct documentation?
Sure! [2]
Thank you! David Ayers
You are welcome. Martin [1] https://bugzilla.redhat.com/enter_bug.cgi?product=Virtualization%20Tools&component=libvirt [2] https://libvirt.org/formatnetwork.html
-- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate)
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
Thanks a lot, Martin! Am Donnerstag, den 31.08.2017, 10:11 +0200 schrieb Martin Kletzander:
On Thu, Aug 31, 2017 at 12:10:22AM +0200, David Ayers wrote:
We would like to configure guest specific dns-servers as would be done with the --dhcp-option of dnsmasq. I was expecting to be able to do something like:
<host mac="00:16:3e:77:e2:ed" name="foo.example.com" ip="192.168.122.10" dhcp-option="dns-server,127.0.0.1" />
but it seems that this isn't the correct approach, as virsh net-edit default removes that attribute definition.
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. Your request for a patch implies that this would be a welcome feature and will not be rediscussed on its principal merit correct? (implementation details notwithstanding ;-) ) The reason I ask, is that I do not have a development environment ready for libvirt and there will be quite a bit work before I've read through all your guidelines, setup a development VM (I suppose that should be easiest with the latest stable release of Fedora, RHEL or CentOS?) I'm not sure yet that I can muster up the time, but it does seem interesting, so a may give it shot. It would be very disappointing if it then were rejected on principle. Thank you! David -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate)
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. Cheers, David -- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate)
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.
Cheers, David
-- David Ayers - Team Austria Free Software Foundation Europe (FSFE) [] (http://www.fsfe.org) Join the Fellowship of FSFE! [][][] (https://fsfe.org/join) Your donation powers our work! || (http://fsfe.org/donate)
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
our bugzilla [1] so that we can track it. Or, even better, send a
this in 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 :-)
participants (3)
-
David Ayers -
Laine Stump -
Martin Kletzander