もはや完全にわかってなかった…っていうそれだけのことだけど…。

CentOS6で動いているサーバがあって、そのサーバの上で、KVMで仮想化したCentOS7を動かそうとしていて、無事にインストールできたもののCentOS7の時計がなんか変ってことでウダウダした際のメモ。

とりあえず、結論から書いちゃうと、仮想化されたCentOS7はKVMが提供するkvm-clockを参照するようになっている。んで、kvm-clockがゲストOSに提供する時刻のタイムゾーンは仮想化されたサーバごとに設定で変更することができて、ゲストOSにCentOS6を使っていた時には、JSTで提供するように設定してあって特に問題はなかったんだけど、どうやらCentOS7からはUTCで提供されることが前提になったらしい。

CentOS7の設定を帰ると、kvm-clockがUTCじゃなくて、特定のタイムゾーン(今回はJST)の時刻で提供されることを前提にすることもできるけど、そうするとWarningが出力されてしまい、まぁ、Warningだし、いっかと思いつつ、ちょっと気持ちが悪かった。そういうわけなので、KVMの設定ファイルを書き換えて、UTCでkvm-clockを出すようにすると問題なく動くようになった。

まず、CentOS7で時計回りがどうなってるかは、以下のコマンドで確認する。

# timedatectl status

表示される結果の中で「RTC in local TZ: no」となっていれば、kvm-clockはUTCで提供されるもんだと、CentOS7は思っているようですな。KVM側でkvm-clockを提供する際のタイムゾーンをどうするかは、各ドメインの設定XMLの中でこんな感じで(下記のようにすると、UTCで提供される)

CentOS6時代のまま、KVMの設定ファイルのoffsetがlocaltimeになっていると、JSTで提供されてしまうので、CentOS7の方でJSTをUTCとして扱ってしまうので、まったく違う時間を保持してしまうと。…まぁ、NTPでの同期を設定してあれば、そのうち、修正されるだろうけど、気持ち悪いし、システムの時計がすごい幅で修正されてしまうのでドキドキする。

んで、kvm-clockがUTCじゃなくて、特定のタイムゾーンの時刻で提供されることをCentOS7に教えるには、さきほどのtimedatectlコマンドを使って

# timedatectl set-local-rtc 1

って実行すれば、教えることができるけれど、

This mode is not fully supported and will create various problems with time zone changes and daylight saving adjustments.

ってビミョーなWarningが出てくる、と。

密かに想像するに、CentOS7から導入されたsystemdって、デフォルトで時刻をUTCで扱うようなので、kvm-clockをUTCであるものとして動くってのも、その絡みのなんだろうなぁ。システム内部ではUTCで持っておいて、設定に応じて、そのタイムゾーンに合わせた時刻を返すってのが、いろいろと間違いないやり方ではあるような気はするけども…(遠い目)