https://www.hardanswers.net/correct-clock-drift-in-centos-hyper-v

вот это мне не подойдет, т.к. ntpd ну и кейс немножечко другой

щас найду KB от MS с разьяснением что RTC всегда будет СИЛЬНО отличаться, и это так by design

если в кратце - ntpd или chrony не будут синкать с RTC, если дельта СЛИШКОМ большая (больше определенного значения)

т.е. они пойдут на ntp server, а если такого не будет - не возникнет ситуация что они от безвыходности установили время с ваще улетевшего RTC

А все мы знаем что RTC может улететь

https://support.microsoft.com/en-us/help/2618634/hyper-v-time-synchronization-doesn-t-correct-the-system-clock-in-the-virtual-machine-if-it-is-more-than-5-seconds-ahead-of-the-host-clock

https://blogs.msdn.microsoft.com/virtual_pc_guy/2010/11/19/time-synchronization-in-hyper-v/

Question #2 – Is there any way that I can stop Hyper-V from putting the wrong time in the RTC at boot? In short; no. We need to put something in there – and that is the best thing that we have to work with.

есть подписка? можешь сделать пдф?

Щас скину

есть подписка? можешь сделать пдф?

Скинул тебе лично

Скинул тебе лично

спс

А если допустим вин7 на квм, там время тоже улетает. Это как править?

про snmp и 32 битные ifInOctets может кто пояснить в чем они меряются? а то столкнулся, что если данные собирать раз в минуту, то макс что счетчик показывает 500Мб

А если допустим вин7 на квм, там время тоже улетает. Это как править?

заставить ее брать время с RTC

про snmp и 32 битные ifInOctets может кто пояснить в чем они меряются? а то столкнулся, что если данные собирать раз в минуту, то макс что счетчик показывает 500Мб

А что не так? Значение В октетах. Максимальное значение счетчика 2^32 = 4 294 967 296 октетов. Если брать раз а минуту, то это 71582788 октетов в секунду (71М октетов) или 572 мегабита в секунду. Надо или опрашивать чаще, или переходить на 64 счетчики.

А что не так? Значение В октетах. Максимальное значение счетчика 2^32 = 4 294 967 296 октетов. Если брать раз а минуту, то это 71582788 октетов в секунду (71М октетов) или 572 мегабита в секунду. Надо или опрашивать чаще, или переходить на 64 счетчики.

О, ты тоже тут?

О, ты тоже тут?

Набегами.

А что не так? Значение В октетах. Максимальное значение счетчика 2^32 = 4 294 967 296 октетов. Если брать раз а минуту, то это 71582788 октетов в секунду (71М октетов) или 572 мегабита в секунду. Надо или опрашивать чаще, или переходить на 64 счетчики.

размерность этих октетов никак понять не могу и перешел на 64 битные счетчики, благо они есть, но что странно, 32 битные хоть и выставлял раз в 30 секунд, собирались существенно реже, и ошибок даж не было

размерность этих октетов никак понять не могу и перешел на 64 битные счетчики, благо они есть, но что странно, 32 битные хоть и выставлял раз в 30 секунд, собирались существенно реже, и ошибок даж не было

Октет это 8 бит

кто как бекапит забикс?

Кто как бэкапит его БД?

Типа того

Просто я запускаю ручками дамп, хочется автоматически и вот думаю чем

Бекапь ВМ консистентно да и всё

Бекапь ВМ консистентно да и всё

место не резиновое, не вим же разворачивать для забикса индивидуально

Просто я запускаю ручками дамп, хочется автоматически и вот думаю чем

cron

:P

место не резиновое, не вим же разворачивать для забикса индивидуально

ну ВМ с заббиксом не много же занимает сама по себе

зависит от

cron

крон куда?

Куда угодно, хоть туда же, где ты ручками dump запускаешь

Куда угодно, хоть туда же, где ты ручками dump запускаешь

ручами дмап, а после через winscp копирую

кто как бекапит забикс?

xtrabackup (innobackupex)

Просто я запускаю ручками дамп, хочется автоматически и вот думаю чем

не лоча таблицы, бекап дампом будет неконсистентным (изменения в некоторых таблицах свежее, чем в тех, что уже забекапились) а лоча таблицы мониторинг будет прерывать приём данных

Бекапь ВМ консистентно да и всё

без остановки mysql он не будет консистентным

без остановки mysql он не будет консистентным

если паузится вм то?

ещё некоторые строят схемы со слейвами и снимают дампы со слейва, лоча таблицы

без остановки mysql он не будет консистентным

Этим можно пренебречь

если паузится вм то?

если выключать заббикс на период дампа вместе с бд, то да, консистентно, но на этот период мониторинг прерывается

не лоча таблицы, бекап дампом будет неконсистентным (изменения в некоторых таблицах свежее, чем в тех, что уже забекапились) а лоча таблицы мониторинг будет прерывать приём данных

они лочатся

они лочатся

тогда мониторинг на этот период прерывается

Там в любом случае есть redo log и recovery

если выключать заббикс на период дампа вместе с бд, то да, консистентно, но на этот период мониторинг прерывается

ну раз в сутки 2 минуты норм

тогда мониторинг на этот период прерывается

угу, яж сервис тормажу, а то спамит в логи

если это допустимо - ок

если паузится вм то?

если у VM бекапится не только состояние диска, то консистентно

Там в любом случае есть redo log и recovery

:

если у VM бекапится не только состояние диска, то консистентно

ну вся целиком конечно же, не только диск

щас вроде большинство приложений понимают что там БД и что с ней нужно нежно

приложений резервного копирования*

но конечно dump более дешевый бекап получается, можно в принципе и так и так делать

на всякий пожарный шланг

потсоны я кстати поборол проблему времени когда hyper-v and guest centos and zabbix inside

настроил ntp на гипервизоре и стал получать время с гипервизора?

настроил ntp на гипервизоре и стал получать время с гипервизора?

нет же

не нужно никогда получать время с гипервизора

это моветон

оно может иметь страшные последствия если хост сойдет с ума

очередность сервисов в systemd немножко подтюнил

чтобы машка ждала обязательно запуска chronyd

более изящного с инженерной точки зрения решения я не вижу(

почему время вообще стало отставать?

почему время вообще стало отставать?

оно не остает а спешит, и это by design

умышленно делается разрыв по времени для rtc гостя

мсфт обьясняет свою мотивацию достаточно понятно, но там много букаф

на esxi тоже будет разрыв, оно будет так или иначе на почти всех гипервизорах

ERROR: S client not available

Но что интересно - проявилось это только на одной машине

потому что у меня еще есть ВМ с базами

Вернее как, дело не в одной машине, а именно только на заббиксовой. Причем пофигу что я поставлю убунту или центось

оно не остает а спешит, и это by design

оно дрифтует внутри vm под нагрузкой, но, при запуске, vm получает время от гипервизора, как если бы получало от hw-часов если при старте vm время до синка по ntp неправильное, значит оно неправильное на гипервизоре

возможно в hyper-v с тех пор что-либо и изменилось, о чём я просто ещё не слышал

Вернее как, дело не в одной машине, а именно только на заббиксовой. Причем пофигу что я поставлю убунту или центось

может дело в настройке "часы в UTC"? в линуксах часто по дефолту так выбрано

может особенность поддержки линуксов со стороны гиперв

хорошая мысль, я бы проверил

еще как вариант часовые пояса. в России изменений много было. может где-то не все обновления стоят

оно может иметь страшные последствия если хост сойдет с ума

само по себе ничего не может сойти с ума, если память с ECC (если без, то и без гипервизора внутри вм все будет сходить с ума по мере аптайма гипервизора) другое дело - человеческая ошибка, резкая смена времени/пояса на гипервизоре, но во-первых обычно менять время на нём и не требуется, во-вторых её точно также можно совершить и внутри гостя постоянный синк времени с гипервизором выключают по другой причине - он синкает время гостю слишком резко, что нежелательно для репликаций ad/субд и прочих вещей, сильно завязанных на времени

оно дрифтует внутри vm под нагрузкой, но, при запуске, vm получает время от гипервизора, как если бы получало от hw-часов если при старте vm время до синка по ntp неправильное, значит оно неправильное на гипервизоре

оно не получит от гипервизора, если отключены средства интеграции относительно времени

может дело в настройке "часы в UTC"? в линуксах часто по дефолту так выбрано

нет

оно не получит от гипервизора, если отключены средства интеграции относительно времени

а откуда оно его получает, по твоему, при запуске?

а откуда оно его получает, по твоему, при запуске?

из своего же hwclock, который уже улетел вперед на пару недель за время аптайма

оно помнит свой hwclock

RTC кароче говоря (типа RTC, ведь мы говорим о ВМ)

из своего же hwclock, который уже улетел вперед на пару недель за время аптайма

hwclock виртуалки - чаще всего это часы гипервизора

https://blogs.msdn.microsoft.com/virtual_pc_guy/2010/11/19/time-synchronization-in-hyper-v/

Question #2 – Is there any way that I can stop Hyper-V from putting the wrong time in the RTC at boot? In short; no. We need to put something in there – and that is the best thing that we have to work with.

hwclock виртуалки - чаще всего это часы гипервизора

далеко не всегда

далеко не всегда

Оттуда же: > When a virtual machine is turned off there is no component that keeps track of time for it.  Instead – whenever you start a virtual machine we take the time from the management operating system and put this into the real-time clock of the virtual machine. > This is done without the use of the Hyper-V time synchronization integration servers (it happens long before the integration services have loaded).

И чего вы хотите сказать что у меня на хосте было 4 мая три дня назад?

она была выключена или запаузена, и какое сейчас время на хосте?

и это говорю не я, а msdn

она была выключена или запаузена, и какое сейчас время на хосте?

выключалась и включалась

никаких пауз

еще как вариант часовые пояса. в России изменений много было. может где-то не все обновления стоят

часовые пояса с рассинхроном на недельку?:)

часовые пояса с рассинхроном на недельку?:)

откуда мне знать? =) я идеи подкидываю. может что-то да поможет найти ответ

ты так спрашиваешь, словно здесь кто-либо в курсе твоего контекста и знает, что и как у тебя сейчас работает

откуда мне знать? =) я идеи подкидываю. может что-то да поможет найти ответ

спасибо

это действительно какой то мутный кейс и я не уверен что всё работает так, как описывает msdn

но любопытный