I guess we can pre-stage our resolv.conf in template and edit /etc/dhclient-enter-hooks
Append code: make_resolv_conf(){ : } Save and close the file. Works on RHEL, Debian-like will have something similar.. Push the template into CS - that should avoid dhcp updating resolv.conf We can also do "chattr +i /etc/resolv.conf" to make it immutable - that's more of a brick and mortar approach. It's a work around - not a solution. Regards ilya -----Original Message----- From: Caleb Call [mailto:calebc...@me.com] Sent: Wednesday, November 07, 2012 11:40 PM To: cloudstack-users@incubator.apache.org Subject: Re: alter resolv.conf nameservers on linux Sorry, yes, setting the global parameter does not work. The contents of my /etc/resolv.conf is: # cat /etc/resolv.conf ; generated by /sbin/dhclient-script search cs1cloud.internal nameserver <ip of my vrouter> I can edit it to what I want it to be, restart the instance and it gets changed back to this. This happens across all my zones in all my different Cloudstack environments. DNS is configured correctly for them. The reason for my desire to not use my virtual router is two fold. First, I have found the name resolution (forwarding if you will) through the VR to be spotty at best. To correct it, I usually have to bounce my VR, it's like it just stops passing traffic. This is happening in both of my Cloudstack environments. Second, running a single nameserver is by no means acceptable in any environment. I wouldn't do it in my dev, test, or stage environments let alone my production environment. We also specify additional parameters in /etc/resolv.conf like timeout and we have to be able to specify additional search domains. On Nov 7, 2012, at 6:07 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com> wrote: > Not sure what you mean by #2. Do you mean that you set the global > configuration flag use.external.dns ? > If so, what is the content of /etc/resolv.conf ? > > Why is the DNS forwarder not working for you? Is your zone dns > configured correctly in CloudStack? > > On 11/7/12 4:06 PM, "Caleb Call" <calebc...@me.com> wrote: > >> #2 doesn't work. It still stomps /etc/resolv.conf with what's >> provided by the routervm. >> >> On Nov 7, 2012, at 4:48 PM, Caleb Call <calebc...@me.com> wrote: >> >>> Thanks, #2 looks perfect. I'll give that a shot. >>> >>> On Nov 7, 2012, at 4:29 PM, Chiradeep Vittal >>> <chiradeep.vit...@citrix.com> wrote: >>> >>>> That should not be necessary. The DNS server in the router is a >>>> forwarder: >>>> 1. If the target of the DNS resolve is for a VM it has served DHCP >>>> to, it responds with the entry 2. If not, it forwards it to the >>>> 'zone' dns server. >>>> >>>> Or, you can set use.external.dns to 'true', restart the management >>>> server and restart (from the api/ui) the virtual router. >>>> But if you do, you won't get #1. >>>> >>>> On 11/7/12 3:12 PM, "Alex Huang" <alex.hu...@citrix.com> wrote: >>>> >>>>> In 4.0, what I would do is this. >>>>> >>>>> - Write a plugin. >>>>> - Listen to vm start events. >>>>> - On router vm start, ssh into the router vm and change the >>>>> resolv.conf >>>>> >>>>> In the next release, Murali have added proper external event >>>>> system then you don't even need to do this via a plugin. >>>>> >>>>> --Alex >>>>> >>>>> -----Original Message----- >>>>> From: Caleb Call [mailto:calebc...@me.com] >>>>> Sent: Wednesday, November 07, 2012 3:06 PM >>>>> To: cloudstack-users@incubator.apache.org >>>>> Subject: Re: alter resolv.conf nameservers on linux >>>>> >>>>> Good question, I've been meaning to ask this same thing and keep >>>>> forgetting to. I think I've read that you have to edit the config >>>>> on the router vm, but that doesn't persist a reboot of the router >>>>> vm. Is there a better way to do this? >>>>> >>>>> >>>>> On Nov 7, 2012, at 3:18 PM, "Musayev, Ilya" <imusa...@webmd.net> >>>>> wrote: >>>>> >>>>>> How would I pass on my nameservers in resolv.conf of an instance, >>>>>> instead of router vms IP? >>>>>> >>>>>> As of now, my nameserver is set to ip address of router vm. >>>>>> >>>>>> >>>>>> Thanks >>>>>> ilya >>>>> >>>> >>> >> >