UMGUM.COM (лучше) 

KVM + time ( Нюансы настройки подсистемы времени в KVM. )

5 февраля 2012  (обновлено 15 августа 2016)

OS: Debian GNU/Linux Squeeze.
Application: KVM 1:0.12.5.

Я тут уже пару-тройку дней как ковыряюсь с параметрами запуска виртуальных машин в среде KVM (Kernel-based Virtual Machine). Хочется, чтобы всё работало как надо, а не как обычно. Вот и вникаю во всё, пытаюсь разобраться в сути воздействия опциональных ключей на подсистему. Что-то не понимаю до сих пор, что-то очевидно было сразу, а что-то вроде как ясно, но какое-то смущение сидит на задворках и зудит: "а вдруг не так, а вдруг через полгода вылезет косяк и исправление его отнимет месяц работы..." В частности, управление передачей показателей времени из несущей машины в виртуальную мне показалось на тот момент несколько неоднозначным.

Насколько я понимаю, в современном KVM подошли к управлению временем двухэтапно. Вначале выбирается источник сигналов времени (clock) на несущей машине, а потом на основе поступающих данных эмулируется источник сигналов (rtc) для виртуальной машины, параметры которого (смещение и коррекция) можно задавать в отрыве от таймера несущей машины.


На данный момент KVM для Linux поддерживает приём сигналов с четырёх источников:

$ kvm -clock ?

dynticks - Tickless Kernel Event Timer
hpet - High Precision Event Timer
rtc - Real Time Clock
unix - Unix Time (POSIX)

А передача в виртуальную машину возможна только в виде эмуляции устройства RTC с опциональной эмуляцией HPET.

Опция выбора источника несущей машины имеет следующий вид:

$ -clock {dynticks|hpet|rtc|unix}

А опция настройки источника для виртуальной машины следующий:

$ -rtc [base=utc|localtime|date][,clock=host|vm]

Вот тут моя мнительность и показала себя во всей красе. А что, если, с учётом того, что для виртуальной машины эмулируется только источник RTC, параметры для него применимы только тогда, когда сигналы с несущей машины берутся тоже только с RTC? Что, если, в случае использования других источников времени, в виртуальную машину передаётся нерегулируемый сигнал? Что, если, только в случае использования исходного (несущей машины) RTC и виртуального RTC, имеется возможность произвольной передачи в виртуальную машину UTC или UTC+смещение? Сейчас эти подозрения представляются смешными, но ещё вчера... В общем, сомнения замучили и я решил прогнать серию тестов на проверку корректной работы любых комбинаций источника сигнала несущей машины и параметров источника сигнала для виртуальной машины.

Условия выглядили следующим образом:

Несущая машина: x64 + Debian GNU/Linux Squeeze + KVM + Time in UTC+6;
Виртуальная машина: x64 + Debian GNU/Linux Squeeze;
Режимы запуска (по одному разу):
  -clock dynticks -rtc base=utc,clock=vm
  -clock dynticks -rtc base=localtime,clock=vm
  -clock hpet-rtc base=utc,clock=vm
  -clock hpet-rtc base=localtime,clock=vm
  -clock rtc-rtc base=utc,clock=vm
  -clock rtc-rtc base=localtime,clock=vm
  -clock unix-rtc base=utc,clock=vm
  -clock unix-rtc base=localtime,clock=vm
Показатели времени в виртуальной машине снимались с вывода устройства RTC:
  cat /proc/driver/rtc

Тесты показали, что источник сигналов времени несущей машины и эмулируемый источник сигналов времени RTC виртуальной машины действительно никак не связаны. KVM получает данные с произвольного устройства времени несущей машины и формирует на их основе сигнал, посылаемый в виртуальную машину, абстрагируя его от исходного источника. Уф, всю ночь проворочался, какое облегчение.

Кстати, рекомендую на данный момент в качестве источника использовать "unix". Дело в том, что в моём случае KVM не то, чтобы блокирует аппаратные источники, но не умеет считывать с них показатели в два и боле потока. Выражается это в том, что при попытке запустить более, чем одну виртуальную машину с источником "dynticks" или "rtc" (помним, что "hpet" и "unix" - эмулируемые источники), KVM не стартует с уведомлением: "could not initialize alarm timer".


Заметки и комментарии к публикации:


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