Something like this:
--- a/patches/systemvm/debian/config/root/edithosts.sh
+++ b/patches/systemvm/debian/config/root/edithosts.sh
@@ -99,6 +99,10 @@ wait_for_dnsmasq () {
logger -t cloud "edithosts: update $1 $2 $3 to hosts"
+#release previous dhcp lease if present
+dhcp_release eth0 $ip $(grep $ip $DHCP_LEASES | awk '{print $2}')
(same for dnsmasq_edithosts.sh)
--- a/tools/appliance/definitions/systemvmtemplate/postinstall.sh
+++ b/tools/appliance/definitions/systemvmtemplate/postinstall.sh
@@ -40,7 +40,7 @@ install_packages() {
# haproxy
apt-get --no-install-recommends -q -y --force-yes install haproxy
# dnsmasq
- apt-get --no-install-recommends -q -y --force-yes install dnsmasq
+ apt-get --no-install-recommends -q -y --force-yes install dnsmasq
dnsmasq-utils
Would need a rebuild of system VM, perhaps documentation update to notify
users that external dnsmasq should also have dnsmasq-utils package
installed.
On Wed, May 1, 2013 at 11:29 AM, Marcus Sorensen <shadow...@gmail.com>wrote:
> 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?
> >> > > >
> >> > >
> >> > >
> >> >
> >>
> >
>
