ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    CentOS 7 VM on Hyper-V losing DHCP assigned address

    IT Discussion
    centos 7 dhcp failed hyper-v chrony
    8
    60
    12.3k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • JaredBuschJ
      JaredBusch @scottalanmiller
      last edited by

      @scottalanmiller said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

      In theory, /var/log/messages should hold some clues.

      but what do i look for is the better question I guess.

      1 Reply Last reply Reply Quote 0
      • dafyreD
        dafyre
        last edited by

        Your DHCP server's logs may also hold some clues if you can narrow down the time frame when the IP address vanishes.

        1 Reply Last reply Reply Quote 0
        • JaredBuschJ
          JaredBusch
          last edited by

          WTF.. the date went south...

          [root@owncloud ~]# grep DHCP /var/log/messages-20160516
May 11 08:49:13 owncloud dhclient[1134]: DHCPREQUEST on eth0 to 10.201.1.7 port 67 (xid=0x2ca58a7d)
May 11 08:49:13 owncloud dhclient[1134]: DHCPACK from 10.201.1.7 (xid=0x2ca58a7d)
May 11 08:49:13 owncloud NetworkManager[804]: <info>  (eth0): DHCPv4 state changed bound -> bound
May 11 18:15:47 owncloud dhclient[1134]: DHCPREQUEST on eth0 to 10.201.1.7 port 67 (xid=0x2ca58a7d)
May 11 18:15:47 owncloud dhclient[1134]: DHCPACK from 10.201.1.7 (xid=0x2ca58a7d)
May 11 18:15:47 owncloud NetworkManager[804]: <info>  (eth0): DHCPv4 state changed bound -> bound
May 12 06:11:42 owncloud dhclient[1134]: DHCPREQUEST on eth0 to 10.201.1.7 port 67 (xid=0x2ca58a7d)
May 12 06:11:42 owncloud dhclient[1134]: DHCPACK from 10.201.1.7 (xid=0x2ca58a7d)
May 12 06:11:42 owncloud NetworkManager[804]: <info>  (eth0): DHCPv4 state changed bound -> bound
May 12 17:00:03 owncloud dhclient[1134]: DHCPREQUEST on eth0 to 10.201.1.7 port 67 (xid=0x2ca58a7d)
May 12 17:00:03 owncloud dhclient[1134]: DHCPACK from 10.201.1.7 (xid=0x2ca58a7d)
May 12 17:00:03 owncloud NetworkManager[804]: <info>  (eth0): DHCPv4 state changed bound -> bound
May 13 02:14:18 owncloud dhclient[1134]: DHCPREQUEST on eth0 to 10.201.1.7 port 67 (xid=0x2ca58a7d)
May 13 02:14:18 owncloud dhclient[1134]: DHCPACK from 10.201.1.7 (xid=0x2ca58a7d)
May 13 02:14:18 owncloud NetworkManager[804]: <info>  (eth0): DHCPv4 state changed bound -> bound
May 22 23:30:53 owncloud NetworkManager[817]: <info>  Activation (eth0) Beginning DHCPv4 transaction (timeout in 45 seconds)
May 22 23:30:54 owncloud dhclient[1146]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x18ffd4fe)
May 22 23:30:54 owncloud dhclient[1146]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 (xid=0x18ffd4fe)
May 22 23:30:54 owncloud dhclient[1146]: DHCPOFFER from 10.201.1.7
May 22 23:30:54 owncloud dhclient[1146]: DHCPACK from 10.201.1.7 (xid=0x18ffd4fe)
May 22 23:30:54 owncloud NetworkManager[817]: <info>  (eth0): DHCPv4 state changed unknown -> bound
May 16 16:36:07 owncloud NetworkManager[803]: <info>  Activation (eth0) Beginning DHCPv4 transaction (timeout in 45 seconds)
May 16 16:36:07 owncloud dhclient[1133]: DHCPREQUEST on eth0 to 255.255.255.255 port 67 (xid=0x27078c0b)
May 16 16:36:07 owncloud dhclient[1133]: DHCPACK from 10.201.1.7 (xid=0x27078c0b)
May 16 16:36:07 owncloud NetworkManager[803]: <info>  (eth0): DHCPv4 state changed unknown -> bound
[root@owncloud ~]#
          1 Reply Last reply Reply Quote 0
          • JaredBuschJ
            JaredBusch
            last edited by

            So the ntpd service is not present on this system. but I know I enabled an NTP server during the CentOS 7 setup.

            Anyone know where that setting is? I'm not finding anything with my Google Fu this morning except answers relating to ntpd.

            1 Reply Last reply Reply Quote 0
            • coliverC
              coliver
              last edited by

              It doesn't use ntpd anymore. I think it uses chrony.

              Make sure you have it set so that the time isn't coming from the hardware, I had that issue with Linux VMs on both VMWare and Hyper-V in the past.

              JaredBuschJ 1 Reply Last reply Reply Quote 1
              • scottalanmillerS
                scottalanmiller
                last edited by

                Yeah, chrony is the new replacement.

                1 Reply Last reply Reply Quote 1
                • JaredBuschJ
                  JaredBusch @coliver
                  last edited by

                  @coliver said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                  It doesn't use ntpd anymore. I think it uses chrony.

                  Make sure you have it set so that the time isn't coming from the hardware, I had that issue with Linux VMs on both VMWare and Hyper-V in the past.

                  Thanks, Once i knew the right name I had no problem finding the config file.

                  It seems i left a couple public servers in there. But hardware, should only be possibly hit on boot up right?

                  /me goes off to double check Hyper-V settigns.

                  # These servers were defined in the installation:
server 10.201.1.7 iburst
server 10.201.1.1 iburst
server 0.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).

# Ignore stratum in source selection.
stratumweight 0

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Enable kernel RTC synchronization.
rtcsync

# In first three updates step the system clock instead of slew
# if the adjustment is larger than 10 seconds.
makestep 10 3

# Allow NTP client access from local network.
#allow 192.168/16

# Listen for commands only on localhost.
bindcmdaddress 127.0.0.1
bindcmdaddress ::1

# Serve time even if not synchronized to any NTP server.
#local stratum 10

keyfile /etc/chrony.keys

# Specify the key used as password for chronyc.
commandkey 1

# Generate command key if missing.
generatecommandkey

# Disable logging of client accesses.
noclientlog

# Send a message to syslog if a clock adjustment is larger than 0.5 seconds.
logchange 0.5


logdir /var/log/chrony
#log measurements statistics tracking
                  coliverC 1 Reply Last reply Reply Quote 0
                  • coliverC
                    coliver @JaredBusch
                    last edited by

                    @JaredBusch said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                    @coliver said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                    It doesn't use ntpd anymore. I think it uses chrony.

                    Make sure you have it set so that the time isn't coming from the hardware, I had that issue with Linux VMs on both VMWare and Hyper-V in the past.

                    Thanks, Once i knew the right name I had no problem finding the config file.

                    It seems i left a couple public servers in there. But hardware, should only be possibly hit on boot up right?

                    /me goes off to double check Hyper-V settigns.

                    # These servers were defined in the installation:
server 10.201.1.7 iburst
server 10.201.1.1 iburst
server 0.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).

# Ignore stratum in source selection.
stratumweight 0

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Enable kernel RTC synchronization.
rtcsync

# In first three updates step the system clock instead of slew
# if the adjustment is larger than 10 seconds.
makestep 10 3

# Allow NTP client access from local network.
#allow 192.168/16

# Listen for commands only on localhost.
bindcmdaddress 127.0.0.1
bindcmdaddress ::1

# Serve time even if not synchronized to any NTP server.
#local stratum 10

keyfile /etc/chrony.keys

# Specify the key used as password for chronyc.
commandkey 1

# Generate command key if missing.
generatecommandkey

# Disable logging of client accesses.
noclientlog

# Send a message to syslog if a clock adjustment is larger than 0.5 seconds.
logchange 0.5


logdir /var/log/chrony
#log measurements statistics tracking

                    I'm not sure about that. I know I had to disable it per VM on Hyper-V.

                    JaredBuschJ 1 Reply Last reply Reply Quote 1
                    • JaredBuschJ
                      JaredBusch @coliver
                      last edited by

                      @coliver said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                      I'm not sure about that. I know I had to disable it per VM on Hyper-V.

                      Right, I know that, but i thought it always checks hardware on boot regardless of setting... It is not checked.

                      0_1463410288970_upload-d748086a-2b51-4117-9ece-4f5a79451e03

                      coliverC 1 Reply Last reply Reply Quote 0
                      • coliverC
                        coliver @JaredBusch
                        last edited by

                        @JaredBusch said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                        @coliver said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                        I'm not sure about that. I know I had to disable it per VM on Hyper-V.

                        Right, I know that, but i thought it always checks hardware on boot regardless of setting... It is not checked.

                        0_1463410288970_upload-d748086a-2b51-4117-9ece-4f5a79451e03

                        Good, then maybe that public server was the issue.

                        JaredBuschJ 1 Reply Last reply Reply Quote 1
                        • JaredBuschJ
                          JaredBusch @coliver
                          last edited by

                          @coliver said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                          @JaredBusch said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                          @coliver said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                          I'm not sure about that. I know I had to disable it per VM on Hyper-V.

                          Right, I know that, but i thought it always checks hardware on boot regardless of setting... It is not checked.

                          Good, then maybe that public server was the issue.

                          I hope so. highly annoying

                          1 Reply Last reply Reply Quote 0
                          • JaredBuschJ
                            JaredBusch
                            last edited by

                            Same issue different server.
                            Why is the time so f'd up.
                            I checked the Hyper-V server, it has the correct time.
                            0_1474475697544_upload-b90e69f0-ebe9-49ad-94e2-34880565e42e

                            I checked chrony on the CentOS box, it had public NTP servers. Boom problem.
                            Changed the ntp servers to internal sources and magic.

                            [root@owncloud ~]# grep chrony /var/log/messages
Sep 19 14:14:44 owncloud chronyd[765]: Can't synchronise: no selectable sources
Sep 21 17:02:28 owncloud chronyd[758]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
Sep 21 17:02:28 owncloud chronyd[758]: Frequency -25.319 +/- 0.011 ppm read from /var/lib/chrony/drift
Sep 20 14:12:20 owncloud chronyd[758]: Selected source 209.208.79.69
Sep 20 14:12:20 owncloud chronyd[758]: System clock wrong by -96617.583787 seconds, adjustment started
Sep 20 14:12:20 owncloud chronyd[758]: System clock was stepped by -96617.583787 seconds
Sep 20 14:12:21 owncloud chronyd[758]: Selected source 104.238.179.130
Sep 20 19:02:11 owncloud chronyd[758]: Selected source 209.208.79.69
Sep 22 08:35:19 owncloud chronyd[758]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
Sep 22 08:35:19 owncloud chronyd[758]: Frequency -25.359 +/- 0.039 ppm read from /var/lib/chrony/drift
Sep 21 11:26:54 owncloud chronyd[758]: Selected source 10.202.1.1
Sep 21 11:26:54 owncloud chronyd[758]: System clock wrong by -76114.165928 seconds, adjustment started
Sep 21 11:26:54 owncloud chronyd[758]: System clock was stepped by -76114.165928 seconds

                            [root@owncloud ~]# date
Wed Sep 21 11:38:02 CDT 2016
[root@owncloud ~]#
                            1 Reply Last reply Reply Quote 0
                            • JaredBuschJ
                              JaredBusch
                              last edited by

                              So the reason I posted to this again.. If you cannot trust ntp.org anymore how are we supposed to handle this.

                              scottalanmillerS 1 Reply Last reply Reply Quote 1
                              • scottalanmillerS
                                scottalanmiller @JaredBusch
                                last edited by

                                @JaredBusch said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                                So the reason I posted to this again.. If you cannot trust ntp.org anymore how are we supposed to handle this.

                                What did I miss? Why can't we trust NTP.org?

                                JaredBuschJ coliverC 2 Replies Last reply Reply Quote 0
                                • JaredBuschJ
                                  JaredBusch @scottalanmiller
                                  last edited by

                                  @scottalanmiller said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                                  @JaredBusch said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                                  So the reason I posted to this again.. If you cannot trust ntp.org anymore how are we supposed to handle this.

                                  What did I miss? Why can't we trust NTP.org?

                                  It pulled the wrong date for the server, which then f'd up the DHCP renew.

                                  1 Reply Last reply Reply Quote 0
                                  • coliverC
                                    coliver @scottalanmiller
                                    last edited by

                                    @scottalanmiller said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                                    @JaredBusch said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                                    So the reason I posted to this again.. If you cannot trust ntp.org anymore how are we supposed to handle this.

                                    What did I miss? Why can't we trust NTP.org?

                                    Crazy time skew with ntp.org and chrony. Never had the issue with the ntpd system. I've had it on some of my new CentOS servers as well. We have a atomic clock on site here but if using ntp,org we get some serious skew.

                                    1 Reply Last reply Reply Quote 1
                                    • scottalanmillerS
                                      scottalanmiller
                                      last edited by

                                      Are we sure that ntp.org was the issue? Is this repeatable?

                                      JaredBuschJ 1 Reply Last reply Reply Quote 0
                                      • JaredBuschJ
                                        JaredBusch @scottalanmiller
                                        last edited by

                                        @scottalanmiller said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                                        Are we sure that ntp.org was the issue? Is this repeatable?

                                        Second time it has caught me. Completely different server. Completely different client.

                                        coliverC 1 Reply Last reply Reply Quote 0
                                        • coliverC
                                          coliver @JaredBusch
                                          last edited by coliver

                                          @JaredBusch said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                                          @scottalanmiller said in CentOS 7 VM on Hyper-V losing DHCP assigned address:

                                          Are we sure that ntp.org was the issue? Is this repeatable?

                                          Second time it has caught me. Completely different server. Completely different client.

                                          Was it the same centos pool? I haven't had issues with the us pool just the default centos ones.

                                          1 Reply Last reply Reply Quote 0
                                          • JaredBuschJ
                                            JaredBusch
                                            last edited by JaredBusch

                                            The end of the log is me changing it to 3 local NTP sources and it fixing itself. Prior to that is was 2 local sources and 2 ntp.org sources.

                                            10.202.1.11
10.202.1.1
3.us.pool.ntp.org
4.us.pool.ntp.org

                                            changed to

                                            10.202.1.11
10.202.1.1
10.202.0.21

                                            No it has not always been a problem, but it picked bad time more than once.

                                            # grep chrony /var/log/messages* > chrony.logs
# cat chrony.logs
/var/log/messages:Sep 19 14:14:44 owncloud chronyd[765]: Can't synchronise: no selectable sources
/var/log/messages:Sep 21 17:02:28 owncloud chronyd[758]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
/var/log/messages:Sep 21 17:02:28 owncloud chronyd[758]: Frequency -25.319 +/- 0.011 ppm read from /var/lib/chrony/drift
/var/log/messages:Sep 20 14:12:20 owncloud chronyd[758]: Selected source 209.208.79.69
/var/log/messages:Sep 20 14:12:20 owncloud chronyd[758]: System clock wrong by -96617.583787 seconds, adjustment started
/var/log/messages:Sep 20 14:12:20 owncloud chronyd[758]: System clock was stepped by -96617.583787 seconds
/var/log/messages:Sep 20 14:12:21 owncloud chronyd[758]: Selected source 104.238.179.130
/var/log/messages:Sep 20 19:02:11 owncloud chronyd[758]: Selected source 209.208.79.69
/var/log/messages:Sep 22 08:35:19 owncloud chronyd[758]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
/var/log/messages:Sep 22 08:35:19 owncloud chronyd[758]: Frequency -25.359 +/- 0.039 ppm read from /var/lib/chrony/drift
/var/log/messages:Sep 21 11:26:54 owncloud chronyd[758]: Selected source 10.202.1.1
/var/log/messages:Sep 21 11:26:54 owncloud chronyd[758]: System clock wrong by -76114.165928 seconds, adjustment started
/var/log/messages:Sep 21 11:26:54 owncloud chronyd[758]: System clock was stepped by -76114.165928 seconds
/var/log/messages:Sep 21 11:43:40 owncloud chronyd[758]: chronyd exiting
/var/log/messages:Sep 21 11:43:40 owncloud chronyd[5238]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
/var/log/messages:Sep 21 11:43:40 owncloud chronyd[5238]: Frequency -24.924 +/- 0.508 ppm read from /var/lib/chrony/drift
/var/log/messages:Sep 21 11:43:45 owncloud chronyd[5238]: Selected source 10.202.1.1
/var/log/messages-20160828:Aug 22 07:58:01 owncloud chronyd[755]: Selected source 64.6.144.6
/var/log/messages-20160828:Aug 22 08:10:35 owncloud chronyd[755]: Selected source 129.250.35.250
/var/log/messages-20160919:Oct 19 03:22:07 owncloud chronyd[762]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
/var/log/messages-20160919:Oct 19 03:22:08 owncloud chronyd[762]: Frequency -25.194 +/- 0.096 ppm read from /var/lib/chrony/drift
/var/log/messages-20160919:Sep 15 21:22:30 owncloud chronyd[762]: Selected source 129.6.15.28
/var/log/messages-20160919:Sep 15 21:22:30 owncloud chronyd[762]: System clock wrong by -2872803.736327 seconds, adjustment started
/var/log/messages-20160919:Sep 15 21:22:30 owncloud chronyd[762]: System clock was stepped by -2872803.736327 seconds
/var/log/messages-20160919:Sep 16 07:55:53 owncloud chronyd[762]: chronyd exiting
/var/log/messages-20160919:Sep 16 18:26:18 owncloud chronyd[759]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
/var/log/messages-20160919:Sep 16 18:26:18 owncloud chronyd[759]: Frequency -25.324 +/- 0.011 ppm read from /var/lib/chrony/drift
/var/log/messages-20160919:Sep 16 07:56:36 owncloud chronyd[759]: Selected source 10.202.1.1
/var/log/messages-20160919:Sep 16 07:56:36 owncloud chronyd[759]: System clock wrong by -37792.972761 seconds, adjustment started
/var/log/messages-20160919:Sep 16 07:56:36 owncloud chronyd[759]: System clock was stepped by -37792.972761 seconds
/var/log/messages-20160919:Sep 16 08:00:04 owncloud chronyd[759]: chronyd exiting
/var/log/messages-20160919:Sep 16 17:26:05 owncloud chronyd[764]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
/var/log/messages-20160919:Sep 16 17:26:05 owncloud chronyd[764]: Frequency -25.324 +/- 0.014 ppm read from /var/lib/chrony/drift
/var/log/messages-20160919:Sep 16 17:25:42 owncloud chronyd[764]: Selected source 10.202.1.1
/var/log/messages-20160919:Sep 16 17:25:42 owncloud chronyd[764]: System clock wrong by -31.644643 seconds, adjustment started
/var/log/messages-20160919:Sep 16 17:25:42 owncloud chronyd[764]: System clock was stepped by -31.644643 seconds
/var/log/messages-20160919:Sep 16 17:30:01 owncloud chronyd[764]: Selected source 66.228.59.187
/var/log/messages-20160919:Sep 18 15:35:10 owncloud chronyd[764]: chronyd exiting
/var/log/messages-20160919:Sep 20 13:43:45 owncloud chronyd[765]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
/var/log/messages-20160919:Sep 20 13:43:45 owncloud chronyd[765]: Frequency -25.310 +/- 0.020 ppm read from /var/lib/chrony/drift
/var/log/messages-20160919:Sep 20 13:43:54 owncloud chronyd[765]: Selected source 152.2.133.52
/var/log/messages-20160919:Sep 18 15:35:51 owncloud chronyd[765]: System clock wrong by -166083.522656 seconds, adjustment started
/var/log/messages-20160919:Sep 18 15:35:51 owncloud chronyd[765]: System clock was stepped by -166083.522656 seconds
#
                                            1 Reply Last reply Reply Quote 0
                                            • 1
                                            • 2
                                            • 3
                                            • 1 / 3
                                            • First post
                                              Last post