I've got some virtual machines with old kernels that know nothing
about virt clocks. They keep time so horribly when loaded up with
testbed runs that they forget to renew their DHCP lease, which
results in their name being removed from the DNS server, which
results in testbed failure :-(.

Does anyone know if it is possible to configure the DHCP daemon
to just leave expired leases active until it actually needs
to reuse the IP address for a new request?

Lacking that, I suppose I can identify the handful of machines
that exhibit this problem and give them static IPs...
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

On Tue, 2012-07-03 at 07:37 -0400, Tom Horsley wrote:
> I've got some virtual machines with old kernels that know nothing
> about virt clocks. They keep time so horribly when loaded up with
> testbed runs that they forget to renew their DHCP lease, which
> results in their name being removed from the DNS server, which
> results in testbed failure :-(.

If they keep time so badly, you might want to play around with NTP
servers forcing the clock back into sync, quite often.

> Does anyone know if it is possible to configure the DHCP daemon
> to just leave expired leases active until it actually needs
> to reuse the IP address for a new request?

Depends which daemon you're using, but that's sometimes the default
behaviour (completely new requests from strangers often get un-used IPs,
until it has no choice but to re-use previously leased ones, even if the
leases have expired).

One option is to extend the lease time to something much longer than the
expected up-time of those clients (a day, a few days, a couple of weeks,
et cetera).

Setting static addresses in the DHCP server configuration is probably
the simplest solution. If you have less machines than available IPs,
I'd do that. It also makes other configuration easier (firewalls, and
other networking), which machines always have the same IP.

--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686

Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.



--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

On Tue, 03 Jul 2012 22:18:08 +0930
Tim wrote:

> If they keep time so badly, you might want to play around with NTP
> servers forcing the clock back into sync, quite often.

This is with NTP - you should see how bad they are without it :-).

I found a complicated whitepaper on the vmware web site that
discussed all the different kinds of emulated clocks and how
different kernels would fail with different clocks in an
emulated environment, and I followed all the recommendations
in that paper, but some of the machine are so horrible it
didn't help much.

I'll probably just collect a list of the problem machines and
make them static.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org