UUIDについての取り留めもない検証～こんなニッチな情報、誰がいるんだ？ 編～
ご機嫌よう、私です。
私の趣味は、バイクいじりです。
そんな私にとって、6月とは、魔の月です。
そう・・・梅雨です！
ただでさえ、祝日が一日もないというとんでもない月なのに、
休みの日には、雨でバイクもいじれない・・・
一人寂しく、家の中で何をしろというのか。
というわけで、早急に、雨の日でも時間が潰せる趣味を探索中です！
何かいいのがあれば教えてほしい。。。
さて、今回は、やってみよう！シリーズ(んなのあったっけ？)としまして、仮想マシンのUUIDについて少し興味がでたので、検証してみます。
★今回は、検証結果のまとめなので、「結論」はありません。暇ではないですが、暇を持て余した技術者の遊び―、程度にとらえてください。
そもそもUUIDってさ
SIDやら、MID、そしてUUID。
ちまたでは色んなIDがあり、お客様との会話の中で使い分ける必要があります。
単語の意味を正しく理解しないと、お客様にうまく伝わらなかったり、認識に齟齬が生まれてしまうためです。
さて、ものっそいざっくり言うと、vSphereにおけるUUIDとは「vSphere仮想化基盤上で仮想マシンに付与される一意のID」のことです。
あくまで基盤上での管理に使用されるため、通常、仮想化基盤の利用者が意識するものではありません。
ただ、このUUID。
仮想化基盤においてはとっても重要です。
vSphereにおいて、仮想マシンをクローンしたとします。
クローンして出来上がったマシンは、Sysprepなどをかけない限り、クローン元と全く同じものが出来上がります。
ただ、それはあくまで「ゲストOS」上でのお話しです。
vSphere仮想化基盤からすると、突然現れた「全く別のマシン」として認識されます。
なぜなら、これらはUUIDが全く違うため、仮想化基盤からすると、全く別物に見えているのです。
例えるなら、楽〇カードマンと川平慈英ぐらい違います。くぅ～！
まあ結論だけ言っておくとね。
答えだけいいますとUUIDの手動変更は「できまぁす」。
この定義は、「仮想マシンのvmxファイル」に記載されています。
ちなみに、VMwareのKBにもちゃーーーーーんと書いてます。
なので、vmxファイルを直接編集してやれば、終了です。
勝った！第三部完！
さて、一つ事例的なお話しを。
とあるお客様で、仮想マシンの基盤間移行を行いたい、という要望をいただきました。
仮想化基盤間の移行、いわゆるV2Vと呼ばれる移行は、同じvSphere基盤同士であれば、比較的リスクは少ないです。それでも、移行した先でマシンがうまく動かなかった際の迅速な切り戻しのために、移行対象マシンのクローンを取得しておきたい、とのことでした。
ただ、そのお客様は、過去の実績から「クローンして出来上がったマシン」ではなく、「クローン元のマシン」を移行したい、というご要件があったのです。
さて、ここで問題になるのがUUIDです。
クローン元を残さない切り戻しは注意が必要
たとえば、近年のバックアップ製品は、仮想基盤との親和性が高く、vCenterと連携してAgentlessでバックアップを取得できるものが非常に多いです。
ただ、先ほどの楽〇カードマンの話を思い出していただきたいのですが、クローンして出来上がったマシンは、クローン元のマシンと全くの別物です。
つまり、仮想化基盤と連携するような製品からすると、同じ名前の全然違うマシンが突然現れたことになります。
そうすると、バックアップなんかは最初から取り直しになっちゃいます。フルバックアップをまた最初から取得するのは、中々手間ですよね。
さて、前置きが長くなりましたが、ここでUUIDの登場です。
UUIDは、マシンに割り振られる一意のIDです。
連携する製品群がUUIDを参考に仮想マシンを判断しているケースもあるので、「じゃぁ、UUIDを上書きしたらいいんじゃね？」と思われるかもしれません。
実際、お客様からも同じ質問をいただきました。
なるほど。
仮想化基盤において、仮想マシンを一意たらしめるものが、UUIDであるのであれば、それを欺瞞することができれば、クローン元を残さなくてもいいかもしれない！
では、早速、Let's 検証☆
vc.uuidとuuid.biosってあんねんけど？
さて、突然ですがvmxファイルの中身を見てみましょう。
すると、以下のような記載になっているはずです。
uuidは、各マシンのvmxファイルの中に定義されています。
あれれー？
UUIDってなんか3つもあるぞー。
と思ったあなた。
そうなんです。
UUIDと一口に言っても、実は上図のように実は、他にもあります。
検証のパターンとして、これらを少しだけ突き詰めてみましょう。
uuid.bios → 同一 かつ vc.uuid → 別 のパティーン
試しに↑でUUIDを見た仮想マシンをvCenterの機能でクローンしてみます。
クローンして出来上がったマシンのUUIDを見てみましょう。
うん。どちらのUUIDもクローン元とは違いますね。
試しに、uuid.biosをクローン元と同じものにしてみましょう。(vc.uuidはそのまま)
つまり、同一vCenter内に同じuuid.biosを持ったものが2台存在する状態ですね。
uuid = 一意のIDである というのを思いっきり破った状態です。
対象のマシンは、DTP001とDTP001-Cloneです。
起動に支障はなさそうです。
★ちなみに、起動後にもう一度UUIDを確認しましたが、勝手に変更されたりしていませんでした。
では、次にバックアップを見てみましょう。
まずは、バックアップを取ります。
次に、DTP001をインベントリから消して、実行してみましょう。
はい。見事にジョブに失敗しましたね。
というわけで、UUID程度を同一にしてみたところでこのバックアップ製品(Veeam)にとって意味はありませんでしたね！
まあVeeamは、別の仕組みで仮想マシンを認識している可能性もありますが、
先ほどの事例のお話しでいくと、UUIDをクローン元と合せたとて、やはり別物のマシンなのです。
つまり、切り戻しを見据えたとき、クローン元を残さない、というのは使用するプロダクトによって、遺恨を残す、ということですね。
uuid.bios → 同一 かつ vc.uuid → 同一 のパティーン
では、次にvc.uuidを合わせてみましょう。
なお、vc.uuidを変更する手順は、探しましたがどこにもありませんでした。
ということは、VMwareとしては認められていない行いということだと思います。
やっちゃダメと言われるとやりたくなりますよね！
お客様環境じゃぁ恐ろしくてとても試せませんからね・・・
さて、状況としては、
uuid.biosは、同一
vc.uuidは、同一
パワーオン動作は問題なし。
シャットダウン後に、再びvmxファイルを見ると・・・？
なんと、vc.uuidは元の値に戻っているではありませんか。
しかも、変更前の値と同じです。
つまり ↓ のような感じ
これは興味深いですね。
変更前と同じになるということは、
vCenter側がすでに割り振ったものがあり、vmxファイルをそれに強制的に書き換えている可能性がありますね。
ちなみに
このuuid。PowerCLIでも参照することが可能です。
uuidが、bios.uuid。
instanceuuidが、vc.uuidと紐づくようですね。
では、起動してvc.uuidが元の値に戻されてしまう前に、このコマンドを叩いてみましょう。
すると・・・
先ほど上書きしたuuidとは、違うuuidが出てきました。
起動していないので、クローンしてできたマシンのvc.uuidは、～～a4 98 になっているはずですが、コマンドで参照すると、～～09 be になっています。
つまり、vmxファイルとは別のところでvc.uuid = instanceuuid が定義されている（？）ことがわかります。
vc.uuidは、もはや我々のどうしようもないところで一意になるようにできているということです。素晴らしいですね。
というわけで
今回の検証結果としては以下のような形になりました。
① uuid.biosは、変更可能
② uuid.biosだけ変更しても、vCenterからはやはり別物としてみなされる
③ vc.uuidは、手動変更できるが、結局元の値に戻される(必ず一意になるように)
④ 移行の切り戻しを考えると、おとなしくクローン元を残しましょう
uuidって奥が深いんだなぁ。
ではでは～。
