How do we go about requesting that dnsmasq-utils be installed on the new system VM?
On Wed, May 1, 2013 at 11:15 AM, Marcus Sorensen <shadow...@gmail.com>wrote: > I think on new system VM edithosts should preemptively expire lease for > the passed ip and then sighup. That avoids complications in having to put > in separate calls to the router VM in each agent resource just to expire. > On May 1, 2013 9:10 AM, "Dennis Lawler" <dlaw...@gmail.com> wrote: > >> It does reconfigure the available leases for new IP allocations. It just >> doesn't expire the leases it has already handed out. >> >> If you replace the "service dnsmasq restart" in edithosts.sh with "kill -s >> 1" on the router VM, you'll start seeing these log messages when a VM is >> destroyed and re-allocated: >> >> dnsmasq-dhcp[pid]: not using configured address 192.168.1.100 because it >> is >> leased to aa:bb:cc:11:22:33 >> dnsmasq-dhcp[pid]: DHCPDISCOVER(eth0) aa:bb:cc:22:33:44 no address >> available >> >> >> >> >> On Tue, Apr 30, 2013 at 10:10 PM, Marcus Sorensen <shadow...@gmail.com >> >wrote: >> >> > that's strange, because the dnsmasq man page explicitly calls out the >> > SIGHUP as a way to reconfigure DHCP hosts entries from a >> --dhcp-hostsfile >> > parameter. Or are these not the same thing? >> > >> > >> > On Tue, Apr 30, 2013 at 5:52 PM, Chiradeep Vittal < >> > chiradeep.vit...@citrix.com> wrote: >> > >> > > >> > > >> > > On 4/30/13 3:26 PM, "Dennis Lawler" <dlaw...@gmail.com> wrote: >> > > >> > > >Every time a new VM is started up, there is a 2 second outage in DNS >> > > >services that can cause problems in guest VMs that use the router VM >> for >> > > >DNS. >> > > > >> > > > >> > > > >> > > >For Cloudstack configurations using both DHCP and DNS services on the >> > > >router >> > > >VM (both implemented with dnsmasq), there is currently a 2 second DNS >> > > >service outage every time a new VM is instantiated >> > > > >> > > > >> > > > >> > > >The source of this outage is in edithosts.sh, which uses "service >> > dnsmasq >> > > >restart" to pick up the freshly added DNS and DHCP entries. >> > > > >> > > >Restarting the dnsmasq service triggers a sleep for 2 seconds after >> > > >killing >> > > >dnsmasq before starting it back up again. >> > > > >> > > > >> > > > >> > > >An obvious solution would be to replace "service dnsmasq restart" >> with >> > > >"kill >> > > >-s 1 $pid" (SIGHUP) so that dnsmasq reads the new DHCP entries >> without >> > > >restarting, as in dnsmasq_edithosts.sh (external dhcp). >> > > > >> > > > >> > > >Unfortunately, this solution is flawed because dnsmasq SIGHUP >> handling >> > > >does >> > > >not expire in-memory DHCP leases in dnsmasq and all leases are >> infinite >> > by >> > > >default. >> > > >> > > Aha! That's why SIGHUP didn't work consistently. This has been >> bugging me >> > > for a long time. >> > > >> > > >Thus, this will only work if the guest VM performs a DHCP release on >> > > >shutdown, which cannot always be guaranteed. >> > > > >> > > > >> > > > >> > > >A few possible solutions off the top of my head: >> > > > >> > > >1. Separate DNS and DHCP services. While DHCP services still >> > > >experience an outage during VM, DNS will not necessarily be >> impacted if >> > > >implemented correctly. >> > > > >> > > >2. Use SIGHUP with dnsmasq and implement a removeDhcpEntry >> > interface >> > > >for network appliances to force a DHCP release whenever a NIC / IP is >> > > >deallocated. This can use dhcp_release to simulate a DHCP release on >> > the >> > > >router VM. >> > > >Catch: dhcp_release is not available for Debian 6.0. The System VM >> > needs >> > > >to >> > > >be updated to at least Debian 7.0, or the dnsmasq-tools .deb from 7.0 >> > > >would >> > > >need to be included in the System VM image. >> > > >> > > There is going to be a new system vm based on 7.0 for the upcoming >> > > release. This should work with earlier releases as well. >> > > https://cwiki.apache.org/confluence/x/UlHVAQ >> > > >> > > > >> > > >3. Change DHCP to have a shorter lease, track de-allocation of >> IPs >> > > >separately from VM destruction. >> > > >Catch: This may cause occasional IP pool exhaustion depending on >> > > >allocation >> > > >of the guest IP range and the rate of VM destruction / instantiation >> in >> > > >the >> > > >network. >> > > > >> > > > >> > > > >> > > >Thoughts? >> > > > >> > > >> > > >> > >> >
