Синхронизация времени в контейнере KVM
На уровне хостовой машины
Без регулярной синхронизации, в зависимости от нагрузки на хост-систему, время внутри KVM контейнера может быстро сбивается. Причина такого поведения вызвана архитектурой операционной системы и особенностями технологии виртуализации.
Большинство операционных систем используют время аппаратных часов только в процессе загрузки, после чего для подсчета времени используются системные часы. В условиях виртуализации процедуры отвечающие за системное время не могут работать также как на реальном железе, в результате часы внутри виртуальной машины начинают постепенно отставать.
Для поддержания времени в актуальном состоянии необходимо регулярно выполнять синхронизацию. Для этих целей можно использовать ntpd, но для контейнеров KVM предпочтительнее использовать синхронизацию системного времени с аппаратными часам kvm-clock.
Время kvm-clock соответствуют времени на хост-системе, таким образом нет необходимости использовать ntpd в каждой гостевой системе.
Для коррекции системного времени мы будем использовать аппаратное время:
/sbin/hwclock --hctosys
Для того что бы система регулярно каждый час синхронизировала часы, добавим задание в cron:
crontab -e 0 */1 * * * /sbin/hwclock --hctosys 0 */1 * * * /sbin/hwclock -w --localtime
'Средствами KVM
Time keeping The guest clock is typically initialized from the host clock. Most operating systems expect the hardware clock to be kept in UTC, and this is the default. Windows, however, expects it to be in so called 'localtime'.
...
<clock offset='localtime'>
<timer name='rtc' tickpolicy='catchup' track='guest'>
<catchup threshold='123' slew='120' limit='10000'/>
</timer>
<timer name='pit' tickpolicy='delay'/>
</clock>
...
- clock
The offset attribute takes four possible values, allowing fine grained control over how the guest clock is synchronized to the host. NB, not all hypervisors support all modes.
- utc
The guest clock will always be synchronized to UTC when booted. Since 0.9.11 'utc' mode can be converted to 'variable' mode, which can be controlled by using the adjustment attribute. If the value is 'reset', the conversion is never done (not all hypervisors can synchronize to UTC on each boot; use of 'reset' will cause an error on those hypervisors). A numeric value forces the conversion to 'variable' mode using the value as the initial adjustment. The default adjustment is hypervisor specific.
- localtime
The guest clock will be synchronized to the host's configured timezone when booted, if any. Since 0.9.11, the adjustment attribute behaves the same as in 'utc' mode.
- timezone
The guest clock will be synchronized to the requested timezone using the timezone attribute. Since 0.7.7
- variable
The guest clock will have an arbitrary offset applied relative to UTC or localtime, depending on the basis attribute. The delta relative to UTC (or localtime) is specified in seconds, using the adjustment attribute. The guest is free to adjust the RTC over time and expect that it will be honored at next reboot. This is in contrast to 'utc' and 'localtime' mode (with the optional attribute adjustment='reset'), where the RTC adjustments are lost at each reboot. Since 0.7.7 Since 0.9.11 the basis attribute can be either 'utc' (default) or 'localtime'.
- ПС:- рекомендую на данный момент в качестве источника времени использовать "unix"
- Time keeping
ИСТОЧНИК:
