Рассинхронизация времени на узле Proxmox VE проявляется сразу в нескольких местах: в журналах появляются события «из будущего», задачи резервного копирования запускаются не по расписанию, а кластер отклоняет тикеты аутентификации из-за разницы в метках времени. Чаще всего причина — неверный часовой пояс, заданный при установке, либо отсутствие работающего NTP-клиента на хосте.
Проверить текущее состояние можно одной командой в консоли узла: timedatectl status. Она покажет системное время, часовой пояс и статус синхронизации. Если в строке System clock synchronized стоит no или пояс не соответствует вашему региону — настройку нужно выполнить, и дальше разберём, как это сделать через веб-интерфейс и командную строку.
Почему точное время критично для Proxmox
Гипервизор опирается на системные часы во многих подсистемах. Планировщик cron запускает бэкапы и репликацию по локальному времени узла, а механизм кворума в кластере чувствителен к расхождению часов между нодами. Заметный сдвиг времени на одном из узлов способен вызвать ошибки при миграции виртуальных машин и проблемы с проверкой подлинности.
Отдельная история — гостевые системы. Виртуальные машины при старте получают время от хоста через виртуальные часы RTC, и если на хосте часы сбиты, гостевая ОС унаследует ошибку. Контейнеры LXC вообще используют системные часы ядра хоста напрямую и не могут менять время самостоятельно.
Проверка текущего времени и статуса синхронизации
Перед любыми изменениями зафиксируйте исходное состояние. Зайдите в Shell узла через веб-интерфейс или подключитесь по SSH и выполните:
timedatectl statusВ выводе обратите внимание на несколько строк. Local time и Time zone показывают текущее время и пояс, System clock synchronized — идёт ли синхронизация с NTP, а NTP service — активна ли служба. Также полезно посмотреть, какой именно NTP-клиент работает в системе:
systemctl status systemd-timesyncd
systemctl status chrony
В свежих установках Proxmox VE по умолчанию используется chrony, а в более старых мог остаться systemd-timesyncd. Держать активными оба сервиса одновременно не нужно — они будут конфликтовать за управление системными часами.
Смена часового пояса
Самый простой способ — веб-интерфейс. Выберите узел в дереве слева, перейдите в раздел System → Time, нажмите кнопку редактирования часового пояса и выберите нужный регион из списка, например Europe/Moscow. Изменение применяется сразу, перезагрузка не требуется.
Тот же результат через консоль даёт команда:
timedatectl set-timezone Europe/MoscowСписок всех доступных поясов можно посмотреть через timedatectl list-timezones, отфильтровав вывод по региону. После смены пояса повторно выполните timedatectl status и убедитесь, что локальное время отображается корректно.
Настройка NTP-синхронизации через chrony
Если на узле установлен chrony, серверы времени задаются в файле /etc/chrony/chrony.conf. Откройте его в редакторе и при необходимости замените пулы по умолчанию на ближайшие к вам серверы — например, на региональные пулы проекта ntppool.org или на локальный NTP-сервер вашей сети, если он есть.
server ntp1.example.local iburst
pool ru.pool.ntp.org iburst
После правки перезапустите службу и проверьте источники синхронизации:
systemctl restart chrony
chronyc sources -v
В выводе chronyc sources у активного источника в колонке состояния появится символ *. Параметр iburst ускоряет первичную синхронизацию после запуска службы — это удобно на узлах, которые перезагружаются нечасто, но должны быстро выходить на точное время.
☑️ Проверка настройки NTP на узле Proxmox
⚠️ Внимание: не запускайте одновременноchronyиsystemd-timesyncd. Если решили использовать chrony, отключите второй сервис командойsystemctl disable --now systemd-timesyncd, иначе синхронизация будет нестабильной.
Вариант с systemd-timesyncd
Если chrony на узле нет и устанавливать его не хочется, достаточно встроенного клиента systemd-timesyncd. Его настройки хранятся в файле /etc/systemd/timesyncd.conf, где в параметре NTP= перечисляются серверы через пробел. После правки включите синхронизацию:
timedatectl set-ntp true
systemctl restart systemd-timesyncd
Проверить состояние можно командой timedatectl timesync-status — она покажет используемый сервер, интервал опроса и величину смещения. Этого варианта достаточно для большинства одиночных узлов, где не требуется тонкая настройка.
Время в виртуальных машинах и контейнерах
С контейнерами LXC всё просто: они разделяют ядро и системные часы с хостом, поэтому отдельная настройка времени внутри контейнера не требуется и обычно невозможна. Достаточно правильно настроить узел. Часовой пояс внутри контейнера при этом может отличаться — он задаётся средствами гостевой ОС через тот же timedatectl или настройки окружения.
Виртуальные машины под KVM получают при старте время от виртуальных часов RTC хоста. Дальше возможны два подхода: либо гостевая ОС сама синхронизируется по NTP (рекомендуемый вариант), либо используется агент QEMU Guest Agent, позволяющий хосту корректировать время гостя, например после снапшота или миграции. Для Windows-гостей важно помнить про параметр localtime в конфигурации ВМ: Windows трактует RTC как локальное время, а Linux — как UTC.
- 🕐 Для Linux-гостей оставляйте RTC в UTC и включайте NTP внутри гостевой системы.
- 🖥️ Для Windows-гостей проверьте опцию
localtime: 1в конфигурации ВМ, если время уезжает на величину смещения пояса. - 📦 В контейнерах LXC время наследуется от хоста — исправляйте его на узле, а не внутри контейнера.
- 🔄 После восстановления ВМ из снапшота проверьте время в госте — оно может «застыть» на момент снимка.
Что делать, если время в Windows-госте скачет ровно на 3 часа
Это типичный признак конфликта трактовки RTC. Проверьте файл конфигурации ВМ /etc/pve/qemu-server/<VMID>.conf на хосте: для Windows обычно нужна строка с параметром localtime. Либо настройте Windows на работу с RTC в UTC через реестр (параметр RealTimeIsUniversal) — но такой способ требует аккуратности и резервной копии реестра.
Типичные проблемы и их диагностика
Ниже собраны частые симптомы, с которыми сталкиваются администраторы Proxmox VE, и способы их проверки. Начинайте диагностику всегда с хоста, а не с гостевых систем.
| Симптом | Возможная причина | Что проверить |
|---|---|---|
| Время сбито на несколько часов | Неверный часовой пояс | timedatectl status, раздел Time zone |
| Время постепенно уходит вперёд/назад | NTP-синхронизация не работает | chronyc sources, доступность NTP-серверов |
| Ошибки в кластере, проблемы с тикетами | Расхождение часов между узлами | Сравнить date на всех нодах |
| В Windows-госте сдвиг на величину пояса | RTC в UTC вместо localtime | Параметр localtime в конфиге ВМ |
| Бэкапы запускаются не в срок | Смена пояса без перечтения расписаний | Проверить задания в Datacenter → Backup |
⚠️ Внимание: если часы узла ушли далеко вперёд или назад, не исправляйте время резким скачком на работающем кластере с активной репликацией. Сначала приостановите критичные задачи, затем выполните коррекцию — chrony умеет плавно подгонять часы, а резкая установка через timedatectl set-time может нарушить последовательность событий в журналах и задачах.
Отдельно проверьте сетевую доступность NTP-серверов: протокол использует UDP-порт 123, и если файрвол или фильтрация на периметре его блокируют, синхронизация молча не заработает. Диагностика — chronyc sources покажет источники в состоянии ? или с недостижимостью.
Часто задаваемые вопросы
Нужно ли перезагружать узел после смены часового пояса?
Нет, смена пояса через веб-интерфейс или timedatectl set-timezone применяется немедленно. Однако уже запущенные службы могут продолжать писать логи со старым смещением до своего перезапуска — это нормально и не требует перезагрузки всего узла.
Какое время видят контейнеры LXC?
Контейнеры используют системные часы ядра хоста и не могут изменять время самостоятельно. Если в контейнере неверное время — исправляйте настройку на узле Proxmox. Часовой пояс внутри контейнера при этом настраивается отдельно средствами гостевой ОС.
Что лучше для Proxmox: chrony или systemd-timesyncd?
Оба варианта рабочие. Chrony даёт более гибкую диагностику через chronyc и лучше подходит для кластеров и серверов с нестабильной сетью. Systemd-timesyncd проще и достаточен для одиночного узла. Главное — не запускать оба сервиса одновременно.
Почему после восстановления ВМ из снапшота время в ней неправильное?
Снапшот сохраняет состояние системы на момент снятия, включая текущее представление гостя о времени. После отката гостевая ОС должна сама подтянуть точное время через NTP или QEMU Guest Agent. Если этого не происходит — проверьте, установлен ли агент и включён ли он в настройках ВМ.
Можно ли указать свой локальный NTP-сервер?
Да, и это хорошая практика для изолированных сетей. Укажите адрес локального сервера в /etc/chrony/chrony.conf (директива server) или в /etc/systemd/timesyncd.conf (параметр NTP=), перезапустите соответствующую службу и проверьте источник в выводе диагностических команд.