2018/11/02

GPOを作成しようとすると「このセキュリティID はこのオブジェクトの所有者として割り当てられない可能性があります」と言われて作成できない

ここしばらくずっと困ってたのがやっと解決したのでメモ。

ドメインコントローラに domain\administrator でログイン、グループポリシーの管理を開いて新しいグループポリシーオブジェクトを作成しようとすると、何故か「このセキュリティID はこのオブジェクトの所有者として割り当てられない可能性があります」というエラーが発生、GPO が作成できませんでした。

解決策は social.microsoft.com のこのスレッドの最後にありました。

  1. グループポリシーの管理を開いて、既存の「Default Domain Controllers Policy」を選択、編集を開始
  2. 「コンピュータの構成」「ポリシー」「Windows の設定」「セキュリティの設定」「ローカルポリシー」「ユーザの権利の割り当て」を選択
  3. 「ファイルとディレクトリの復元」を開き、Administrators グループがあるか確認、無ければ追加する
  4. gpupdate /force を実行してGPOを有効にする
  5. 一度サインアウトして、サインインを行う

なんでやねん!って思わず突っ込みそうになりましたが確かに Administrators を追加するこの手順で直りました。

日本語では見つけられなかったので、備忘録代わりに。


2018/04/16

【余談】Excel で折れ線グラフが縦棒になる問題とその回避策

問題解析のために Excel で時系列のデータをグラフにした時、横軸に日付時刻が入った列を指定すると下図のような縦棒になることがあります。

結構これが困ってたのでちょっと調べてみました。
横軸を指定する前は、こんな感じです。
ここでグラフ上で右クリック「グラフデータの選択」 を選び、「横(項目)軸ラベル」でA列を選ぶと、冒頭のグラフのようになります。

つまりはこの横軸が問題なため、横軸の書式設定を見てみます。




すると、軸の種類が「データを基準に自動的に選択する」 となってますが、この時「日付軸」が選ばれるようです。つまり、同じ日なら同じ横軸の位置に表示されます。このため、日付入りの時間が記載された列を横軸に選ぶと、1日1目盛りの軸になってしまい、冒頭の縦棒ができあがります。

少なくとも Mac 版の Excel (16.12 にて確認) では、時間単位の軸はなく、時刻として扱う限りはこうなってしまいます。

そこで、もう一つの選択肢の「テキスト軸」を明示的に選択します。この場合、時刻を文字列として扱い、1つの行ごと1つの目盛りとなります。結果として、意図通りに描画される次第です。


 これ自体は以前から見つけていたのですが、何度も忘れて探し直し、今日もそれをやったので忘れないようにここに記載した次第。








2018/03/11

vExpert 2018 受賞しました

vExpert 2018 受賞しました。どうもありがとうございます。

例年、VMware 社の blog にリストがアップされる vExpert の発表ですが、今年は発表方法も変わっていて少々混乱しました。
そもそも、vExpert 2018 の申し込みから vExpert App と彼らが呼ぶ Webサイトでアカウントを作成、申し込みをするようになっておりまして、発表というか「現在のvExpert のリスト」の更新と、あと受賞のメールの送付を持って発表となったようです。

で、リストの方には名前があったのですが、届くとされていた受賞メールがいつまで経っても来ず、今年はとうとう落ちたかなぁと思っていたら、なんのことはない SPAMフィルタに引っかかって迷惑メール扱いになっていたというオチでした。
vexpartapp.com からで、vmware.com からではないのに注意!!

この Blog の右側のバッチですがまだ2018年のは用意されていないようで、アップされしだい更新します。

3/17追記 : Facebook の vExpert Japan コミュニティで渡辺 剛さんからバッチが出たのを伺いまして、早速 更新しました。いつもの年号入りとは別に、連続受賞回数で☆がついたものがあったので、今年は星の方にしてみました。なんせ9連続は日本では2人?、いても3人しかいないはずなので(笑)

2017/12/16

esxtop のご乱心とその対処法について

vSphere の管理をしていると、vSphere Client などGUIからではらちがあかず、SSH でログオンして様々なコマンドで状況を確認、解消する事もよく出てきます。

特にパフォーマンス問題で力を発揮するのが esxtop コマンドです。Linux, UNIX の top コマンドのように仮想マシンや関連プロセスの稼働状況、IOの状況を表示、定期的に更新してくれる優れものです。
esxtop : とくにパフォーマンス問題で無くてはならない管理者の友です
ただ、様々な端末を使っていると、ときにこの esxtop の表示が乱れたり、vi や less が下記の画像のような表示をして正しくスクロールしてくれなくなる事があります。
esxtop ご乱心!

terminal is not fully functional のメッセージ
リターンを押すと一応表示されるが、若干挙動がおかしくなる

これはどうしてかを簡単に調べてみました。

● 端末画面制御

esxtop や vi, less といったコマンドの特徴は、ただ出力のテキストを垂れ流すのではなく、画面の任意の位置を書き換え、適切なところに表示を行おうとする、事です。こうした端末画面の制御のためのデータベースとして、termcap と terminfo があります。とか言うと何故画面制御にデータベースが関係する? となりますが、これはUNIXと「端末」の歴史にもつながってきます。

60年代やそれ以前、極めて初期のコンピュータでは出力は「紙」でした。プログラムからの出力は紙に印字されて出力されていました。その後にブラウン管への出力に移っていきましたが、ごく初期のブラウン管の出力とキーボードなどの入力の組み合わせた機械、すなわち「端末」(Terminal)では、やはり出力をそのまま、左から右、上から下へだだっと垂れ流すしかできませんでした。これを「ダム端末」と呼ばれてました。dumb=馬鹿とかのろまとかという意味で、まあシリアルケーブルなどを通じて送られてきたデータをただ垂れ流し表示するだけ、なんの能もないからそういう名前になったようです。

少し時代が経つと、少し賢い端末がでてきました。ダム端末に対してこれらは「インテリジェント端末」とも呼ばれました。インテリジェント端末の定義は時代により様々ですが、出始めの場合、文字に色がつけれる、Tektronixと言う会社の端末のように グラフィックの表示機能を備えたものとかがインテリジェント端末と呼ばれました。
(後にはパソコンベースの端末でローカルでのアプリケーションの実行やそれとホストとの連携ができるもの、などがインテリジェント端末と呼ばれるそうですが、私はこの頃はよく知りません。)

インテリジェント端末の時代になってただ出されたテキストを垂れ流しで表示するのではなく、文字の色を変えたり、画面の任意の位置にカーソルを動かして「左から右、上から下」ではない順序での表示が可能になりました。

このような画面の操作を行うのにつかわれたのが「エスケープシーケンス」などと呼ばれる一連のテキストです。これは出力のテキストに混ぜて送られ、送られた文字をただ表示するのではなく、その文字列が指示する動き、例えば次の文字を赤く表示する、カーソルの位置を上から20左から30に移動させる、を実施しました。ちょうどHTMLのタグみたいなものです。この一連のコードはエスケープ(0x1B)を先頭にする場合が多かったこともありエスケープシーケンスと呼ばれました。

エスケープシーケンスは後にISOの共通規格にもなりましたが、問題は、インテリジェント端末の出始めは必ずしも端末のエスケープシーケンスが同じ、ではありませんでした。ホスト上で動くソフトウェア、例えば vi とか esxtop、が次はカーソルを左上に動かして強調文字で「ABC」と書きたい、とか思っても、端末ごとに送るエスケープシーケンスは異なる、端末ごとにアプリ側で対応が必要となりました。ホストに繋ぐ端末機器を変えるたびにアプリ側の設定変更(あるいはコードの修正)が必要になりました。

これは不便だと登場したのが BSD UNIX の「termcap」というデータベースです。/etc/termcap というファイルに、端末ごとのエスケープシーケンス、カーソルを上に動かす時はこう、色を変える時はこう、っという定義を記載、環境変数 TERM によりどの端末の種類かを定義、esxtop のようなアプリケーションはTERMの端末種別を元に termcap から適切なエスケープシーケンスを読み出し、適切な操作ができるようになりました。
環境変数TERM
SystemV では terminfo というほぼ同じ仕組みが作られました。termcap との違いは「termcap はテキストで人が読める」「terminfo はテキストの定義を元にバイナリに変換、アプリからの読み込みが手っ取り早い」と、まあその程度です。

なお、いまどきの Linux, UNIX では terminfo の方を使うのが一般的となってます。

Windows の TeraTerm Pro Putty といったソフトウェアは、SSH や TELNET といったプロトコルで通信する機能を提供する一方、エスケープシーケンスを解釈し適切な表示を行う「端末」の役割も果たしてます。このため端末エミュレータとも呼ばれます。分かりやすいのは macOS の「ターミナル」や Ubuntu Linux などのターミナルアプリで、これらは「端末」としての表示のみを担当、SSH での通信は ssh コマンド、TELNET での通信は telnet コマンド、が担当しております。

余談ですが Windows 8 から 10 にかけて、ウィンドウズのコマンドプロンプトウィンドウもかなり機能強化されましたが、その一つとして端末エミュレータとしての機能強化もあります。マイクロソフト自身が OpenSSH を移植、Windows10 への標準搭載化を進めていますので、端末エミュレータとしての機能の受け皿が必要になった、というのもあります。

閑話休題、ともあれ termcap ないしは terminfo というデータベースを通じて端末の形式から正しいエスケープシーケンスを調べだし、適切な画面の制御ができるようになっている、というのが Linux, UNIX の端末画面制御になります。

なお、terminfo の情報は通常、/usr/share/terminfo 以下にあります。コンピュータの処理能力が非力だった時代からあるため、負荷軽減と検索の高速化のため、terminfo フォルダの下にサブフォルダを作成、1ファイル1端末種別 でファイルが格納されています。
macOS 10.12.6 Sierra での terminfo の設定ファイル数
1ファイル=1端末種別のため、約2600の端末機器に対応...ほとんどは使われないと思うけど。
macOS の場合、terminfo 以下には 2563ファイル存在、つまり 2563種類の端末に対応しています。

また、「ターミナル」アプリケーションでは、以下画面の10種類の端末形式に対応しております。
Mac の場合、ターミナルアプリのプロファイルにて、
プロファイルごとにどの端末の種別かを設定できる

vt100 はハードウェアだった端末でのデファクトスタンダードで、vt100互換、つまりvt100と同じエスケープシーケンスを受け付ける端末ハードウェアが多かったと伺っております。また、xterm は X Window System に付属のターミナルソフトで、rxvt は xterm を元に軽量化させたもので、一時期 流行ってたのを記憶しております。
( なお、私は NeXT(標準ターミナルアプリケーション) -> UX/OS(kterm) という流れで以降は Mac か Windows を端末に Solaris や Linux にリモートアクセスなので、xterm を少々使った事があるぐらいです。)

大まかに有名どころの端末のエスケープシーケンスに対応していると言えます。
この「ターミナルの宣言方法」を切り替えてから新規ターミナルウィンドウを開くと、環境変数TERMはその値に設定され、そして若干挙動がかわります。例えば、vt100 と xterm でそれぞれ less を実行、終了すると分かりやすいと思います。


● ESXi の端末情報データベース

さて、ようやく本題です。
ESXi Shell の環境も概ね Linux, UNIXの仕組みを継承しています。画面制御については実は terminfo を使っています。ではどれだけの端末の種類に対応してるでしょうか...。

ESXi Shell 環境での端末の種別。5行、すなわち5ファイルで、5端末種別、だけ...。
はい。たった5種類の端末にしか対応していません。内訳を見ると、screen, xterm, ansi, linux, vt102 です。screen は端末切り替えソフトの screen を使用の際に使われるもの、linux は Linux 起動時のコンソールで利用される端末の種別で、実際、コンソールでの ESXi Shell では環境変数TERM は linux に定義されています。
ローカルコンソールでの ESXi Shell
環境変数が linux になってるのが分かる
つまり、ssh接続などで一般的に使われる端末エミュレータとしては、xterm か vt102 しか対応していない、といえます。
Mac のターミナルアプリケーションのデフォルトの端末種別は「xterm-256color」です。ssh コマンドはデフォルトでローカルの環境変数TERMをリモートにも伝えてくれます。つまり ESXi にログインした場合、環境変数 TERM は xterm-256color が設定されますが、これは ESXi 側の terminfo に存在しない端末種別のため、esxtop のように画面制御ができずダム端末のようにテキストを流し込んでくるか、冒頭の less のように「制御できないけど、いい?」って聞いてくるようになります。

● どう対処すべきか

このような問題が生じている場合、簡単なのは送付する環境変数TERM を変えてしまうと言う事です。
例えば、以下のように env コマンドで環境変数TERMを xterm に変更後 ssh コマンドを実行すると、ESXi 側では xterm-256color ではなく xterm として扱ってくれます。

env コマンドで環境変数TERMを再設定してから ssh
結果、再設定したTERMの値が伝えられる
xterm-256color と xterm は、色に関するエスケープシーケンスが違うだけで互換性がありますので、このような無茶も通ります。

あとは、そもそも端末エミュレータ側の端末種別を xterm か  vt102 に設定してしまう、というのもあります。

この手の問題をググると、「だったら terminfo に設定追加すれば良いじゃん」的な答えが散見されますが、残念ながら ESXi Shell の環境には tic コマンド(terminfo でテキストの設定からバイナリの設定にコンパイルするコマンド)が存在しないので、やるとすると少々面倒です。また、ESXi Shell 環境というかあのファイルシステムにあまり独自のファイルを置くのはあまり推奨されません。やるなら tardisk とか ramdisk の仕組みをよく調べて、ESXi の動き、何処のファイルが温存されどれが消えうるかを確認、これらの意味をよく分かった上で実施すると良いでしょう。

ともあれ、vSphere の管理者にとって esxtop が使えない環境は最悪です。環境変数TERMをうまく扱う事でそんな環境はなくしていきましょう。


最後に、個人的な感想ですが、「いや、vt100互換が実際には vt102互換である事ぐらいは知ってるけどさ、何も馬鹿正直に vt102 だけを置いて vt100 を置かないってのもないんじゃねえの?」とか思いましたよ、ええ。


2017/10/26

Fall Creators Update で OpenSSH が標準搭載に(ただしBeta)

ふと、Windows10 の設定アプリにて、「アプリと機能」の「オプション機能の管理」から、「機能の追加」を見たところ、OpenSSH のサーバとクライアントを Windows10 のオプションとして導入できるようになっていた。


以前よりマイクロソフトは Windows 向けに OpenSSH の移植を行っていたが、どうやらこれがとうとうOS側に搭載されるようになったようだ。まだβ版で以下に述べるように少々問題があるが、エスケープシーケンスが強化されてきているコマンドプロンプトウィンドウとあわせることで、TeraTermPutty といったターミナルエミュレータ抜きで SSH によるリモートアクセスが可能になる点は歓迎したい。

せっかくなので OpenSSH Client の方をインストールしてみた。モジュールは %SYSTEMROOT%\System32\OpenSSH 以下にインストールされる。システム環境設定のPATHにも設定されるのだが、これは次にサインインするセッションから有効なため、インストールを行ったそのセッションではパスが設定されないことに注意。インストールが終わったら一度サインアウト/サインインをしなおすようにしよう。

たまたま macOS Sierra で sshd が動いているのでこちらに接続してみた。パスワードを用いた場合はあっさりとログインできた。



\Users\<アカウント名>直下に .ssh フォルダを作成、config ファイルを作成する事で ssh クライアントの設定を行う事もできる。



しかし、ssh-keygen を用いて鍵を作成しようとしたところ、RSA, DSA などはそもそも作成できず、ed25519 については作成できているものの、id_ed25519 ファイルの作成で失敗する。おそらく、\ と / が混在したパスがデフォルトで指定されているために見受けられる。



では、と id_ed25519 ファイルのパスを手入力してみたところ、/ だとパスの区切りとして認識できないのか失敗し、\ は「¥¥」にエスケープされてしまい、これまた失敗してしまう。今のところ、ssh-keygen でキーの作成には成功していない。

それでは、とこれまで使っていた TeraTerm を使って公開鍵と秘密鍵を作成、macOS 側の ~/.ssh/authorized_keys に公開鍵を登録してみた。TeraTerm  でこの公開鍵と暗号鍵でパスフレーズによる認証ができた事を確認した後、今回の ssh コマンドでも試してみた。


結果がこれである。


ssh コマンドも id_ed22519 ファイルが読めていないように見受けられる。これもパスの問題の模様だ。この事から、公開鍵による認証は現時点ではできないと言える。



また、ESXi にサインインしようとしたところ、暗号化方式が合致せずサインインできなかった。


この ESXi は 6.5.0 build-4887370 なのだが、/etc/ssh/sshd_config では以下の暗号化およびメッセージ認証符号が以下に設定されている。
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,3des-cbcMACs hmac-sha2-256,hmac-sha2-512,hmac-sha1
...正直、これは少々後ろ向きというかトラッディショナルというかいまどきな設定に見受けられる。なお、macOS Sierra での sshd の設定では Ciphers も MACs も特に設定されていないが、デフォルトで以下のように設定されている。


macOS Sierra と Windows10 の ssh でそれぞれのバージョン、対応している暗号(Cipher)およびメッセージ認証符号(MAC)を出力させたが、バージョンは 7.4p1 と 7.5p1 でほぼ同じだが、対応している Cipher と MAC が段違いである事が分かった。



しかも、この出力が正しいなら ESXi とは Cipher: aes256-ctr, MAC:hmac-sha2-256 あたりでネゴシエーションしそうなのだが、どうも記載されている全ての Cipher,MACが使えるわけでもないようだ。




公開鍵による認証ができない、Cipher,MAC が今風のしかない事から接続先が限られるなど、現時点では諸々問題がありこれ一個で、とはいかない。他の SSH クライアントは用意しておくべきだろう。とはいえまだβ版だ。そのうちこれらの問題は解決していくだろう。


コマンドとしての動作は十分に軽快で、OS標準で提供され、サードパーティーのアプリを入れなくて良いという点では評価ができるかと思われる。

2017/10/20

Flash 27.0.0.170 で WebClient がクラッシュする

普段使ってない vSphere 6.5 の vCenterServer アクセス、WebClient を使おうとした時に、ブラウザ内で「プラグインがクラッシュしました」などと表示され WebClient がいつまでもあがってこず難儀してしまったのでメモ。

これは、WebClient 側の問題で、VMware の KB (2151945) にも記載がある。
残念ながら現時点では解決策はない。ワークアラウンドとしては
  • Flashプラグインのβ版を導入する
  • 前のバージョンの Flash プラグインに無理矢理ダウングレードする
  • HTML5の vSphere Client ないしは C# の vSphere Client を使う
の三つだ。正直どの対応もいかがなものかと思うのだが、vSphere 6.5 の場合これまで使っていた Windows アプリ(C#) の vSphere Client も使えないし、HTML5版はまだばまだメインで使うには辛いのでダウングレードを試してみた。

macOS の Macbook Pro のため、
  1. Adobe のサイトから Flash のアンインストーラをダウンロード、実行
  2. こちらのサイトから 27.0.0.159 の Flashプラグインをダウンロード、インストール
  3. システム環境設定の Flash Playerペインから Flash の自動アップアップデートを禁止
という手順になった。
なお、1. のアンインストーラーは PPAPI の Flash も NPAPI の Flash もどちらも消してしまうので要注意だ。また、上記にリンクされている 27.0.0.159 の Flashプラグインは各OS版がまとめて入っているので少々大きい。使うのは「27_0_r0_159」フォルダのなかの「flashplayer27_0r0_159_mac.dmg」と「flashplayer27_0r0_159_macpep.dmg」だけだ。flashplayer27_0r0_159_mac.dmg が NPAPI 版のプラグインで、flashplayer27_0r0_159_macpep.dmg が PPAPI 版プラグインだ。

NPAPI はもはや Firefox しか使ってない古いインターフェイスのもので、PPAPI は Chrome および Safari が使っているより新しいインターフェイスになる。

私は Chrome を使っていないのと、普段使いの Safari と WebClient へのアクセス用のFirefox を分けていたのもあり、NPAPI 版の「flashplayer27_0r0_159_mac.dmg」飲みをインストールした。

結果、WebClient が使えるようになったが、Flash の利用には制限をかけておいた方がいいのかも知れない。










2017/08/31

仮想マシンとハードウェアクロック

PCの中には時間を刻むハードウェアが内蔵されており、今が何月何日の、何時何分何秒かを把握しております。歴史的な事情からこのハードウェアは単一ではなく、複数のものが存在していたりします。かつては RTC (Real Time Clock)という仕組みだけでしたが、これがあまり精度が良くなかった、使い勝手が悪かったなどの理由で HPET が登場し、CPU には TSC というタイマーが用意されたのでこれを使って時刻を図ることが行われ、また ACPI には ACPI PMT というこれまた時間を計る機能が存在します。

ともあれ、OS は起動時にPCハードウェアのこれらの時計から時間を取得、カウンターを利用して、取得後どれぐらい経過したかを知り、OS自身で時間を管理しております。
例えば Linux の場合は、OSの終了時に hwclock コマンドを使ってPCのハードウェア側にOSが把握している時間をかき込みます。Windows などの場合もおそらくOS終了時に時刻を書き戻しているでしょう。この理由は、PCのハードウェア上の時刻はずれていることがままあるためです。

この PC上のハードウェアの時計は「どの時間帯」の時間を記録しているでしょうか?実はこれは決まっていません。ほとんどの場合、ハードウェアの時計はローカルタイム、現地時間を記録してます。一方、ハードウェアの時計が UTC(世界標準時) であることを前提としているシステムもあります。例えば ESXi がそうです。ESXi は物理ホスト上のハードウェアの時計に UTC での時間をかき込み、起動時も UTC であることを前提に読み込みをします。

一方、Windows や Linux では、OSの内部では UTC をベースに構成されていますが、時刻の表示時には指定されたタイムゾーンを加味して現地の時間を表示しております。ハードウェアの時計に対しても、ローカルタイムがかき込まれているものと考えるのがデフォルトとなってます。先の hwclock コマンドも、OSから読み出した時間を /etc/localtime ファイルの示す時間帯を考慮した現地時間でかき込みます。


● 仮想マシンの時間

VMware の場合、初回起動時には ホストOSの時間がそのまま使われます。VMware Player や Workstation, Fusion では、新しい仮想マシンを作成して起動、BIOS設定画面に入ると現地時間での時刻が表示されます。
かつての ESX でもそうでした。ESX の場合、COS(サービスコンソール) の Linux 上の /etc/localtime を参照して仮想マシンの仮想的なハードウェアの時計に「ローカル時間」をかき込んでました。
ESXi の場合、/etc/localtime のようなタイムゾーンを把握する枠組みがありません。vSphereClient などで時間を見ると現地時間が表示されますが、これらはクライアントソフトウェア側で変換して表示しているもので、ESXi との時間のやりとりは UTC をベースとしています。

このため、ESXi で仮想マシンを作成、初回の起動時にBIOS時間を見ると、UTCで表示されます。日本の場合、9時間前の時刻が表示されていることになります。

新規に作成した仮想マシン
17:42 頃のものだが、8:42となっており、初回起動時は9時間ずれてるのが分かる
二度目以降の起動では少々事情が異なります。ゲストOSが終了時に(仮想の)ハードウェアの時計に時間を設定した時、VMware はそのかき込まれた時間と自身が把握している時間を比較、「差分」を検知します。ESXi の場合、上のOSが「日本時間」をかき込んでくると、9時間早い時間がかき込まれたことを検知します。この差分は nvram ファイルに保存されます。

二度目以降の起動時は、自身の時刻にこの差分を加味した時刻を、仮想マシンのハードウェアの時計としてセットします。先の例の場合、UTCに9時間を加えた時刻をハードウェアの時計とします。これは日本時間になります。ゲストOSはこの時間を読み込みますので、結果として正しい時間になります。
この挙動は VMware のこのドキュメントの「Virtual CMOS RTC」に記載されています。


● 他のハイパーバイザの仮想マシン

Hyper-V の場合は Windows の時刻管理に準じるためあまり深いことを考える必要がありません。

今回、この記事を書く動機になったのは KVMについてのハードウェアの時計がどうなってるかを調べたことからでした。KVM では、仮想マシンのモニタである qemu-kvm コマンドの引数 -rtc にどう設定するかによって決まります。主に以下2つのオプションが使われます。

  • clock : 時刻を何処で管理するか
    • clock=vm : 仮想マシン側で独自に時刻を管理する
    • clock=host : ホストの時間をそのまま利用する
  • base : 仮想マシンの起動時、(仮想の)ハードウェアの時計を何処に設定するか
    • base=2010-12-03T01:02:00 : 2010/12/03 01:02:00 に設定する
    • base=utc : UTCでの現在時間に設定する
    • base=local : ホストOSのタイムゾーンを加味した現地時間に設定する

OpenSUSE のドキュメントの例をみると
qemu-kvm [...] -rtc clock=vm,base=2010-12-03T01:02:00
となってますが、これは「時刻は仮想マシンで独自に管理」「2010 12/03 1:02:00 をハードウェアの時計の開始時間」として設定することを意味します。

(AHVについては記述が誤っていたため一旦削除しました。あらためて正しい情報を書きます。)