VSAN で使ったディスクを再利用して VMFS を構成する

先日のことだが、vExpert 2014受賞者向けに VSANを含む各種製品の評価ライセンス(365日有効)が配布された。
例年、vExpert にはだいた1年のほぼ全製品の評価版が渡されており、自由に検証に使うことができる。あくまで個人への割り当てのため家の私物 ESXi 環境などに入れても問題がないため、これは結構重宝する。


さて、そのVSANの検証をしていて、VSANの構成にHDDやSSDを使おうとした際、あるいはその逆でVSANで使ってたディスクを VMFSで利用しようとすると、構成時にそのディスクが選択肢に表示されず、利用できないことがあった。

どうやら以前に一方で使っていたディスクは、もう一方に使えないようになっているようだ。これはフェイルセーフとしても納得がいく。何らかの理由で孤立してしまい、単体では VSANの一部として見なされないディスクをうっかりVMFSで上書きしてしまっては困るからだ。

とはいえ、検証でディスクを使い回しているとそうも言ってられない。
ので、少々乱暴だが認識できるようにしたので、メモをしておく。


● なぜ認識されないか

VMFSを削除したり VSANを解放しても、SSD/HDD上にはその時に作成されたパーティション情報が残っている。ESXi はこのパーティション情報を見て VSAN/VMFSで使っていたことを検知する。VMFSで使ってた領域を VMFSで使う分には問題ないのだが、タイプを変えようとするとお互いの選択肢から除外されてしまう訳だ。
(なお、これに限らず、ESXi はなんらかのパーティション情報があると選択肢から除外する傾向がある。Linux 等で使ってたディスクを追加のVMFSとして使う際はこれが問題になる事がある。 )
このため、パーティションテーブルをクリアすれば新しいSSD/HDDのように素直に認識してくれる。


● パーティションの削除(失敗編)

さて、パーティションテーブルを飛ばすとなると、普通 dd コマンドだろう。
(大事なことなので強調してみました)

しかし、なんとも嘆かわしいことに ESXi Shell では dd コマンドは使えない。
存在はするのだが、ディスクドライバ側に必要なAPIが備わってないため、書き込みができないのだ。

# dd if=/dev/zero of=/dev/disks/naa.600508b1001cccc92c42c05aa821872a count=1 bs=1M
dd: can't open '/dev/disks/naa.600508b1001cccc92c42c05aa821872a': Function not implemented

嘆かわしい、実に嘆かわしいっ。

仕方が無いので、前時代的で格好の悪いパーティション操作系のコマンドを使うことになる。もういつから使ってるか分からない、あの fdisk だ。

ただ、ESXi の作者はすこしは正気が残ってたようで、fdisk コマンドは動きはするが非推奨となっている。MBRパーティションではなく GPT を使ってるからだ。

# fdisk -l /dev/disks/naa.600508b1001cccc92c42c05aa821872a

***

*** The fdisk command is deprecated: fdisk does not handle GPT partitions.  Please use partedUtil

***

Found valid GPT with protective MBR; using GPT

Disk /dev/disks/naa.600508b1001cccc92c42c05aa821872a: 390651840 sectors,  372M

Logical sector size: 512

Disk identifier (GUID): b380795f-8cc1-4991-b911-aed80429cf48

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 390651806

Number  Start (sector)    End (sector)  Size       Code  Name

   1            2048            6143        4096   0700

   2            6144       390651806        372M   0700

上記のように、fdisk を実行すると推奨されるのが partedUtil というコマンドだ。


● partedUtil で情報を取得する

partedUtil でのパーティション情報の取得には get/set とgetptbl/setptbl という2つの系統がある。どっちも fdisk にくらべればシンプルだが、より細かい情報が出るのは getptbl の方だ。

# partedUtil get  /dev/disks/naa.600508b1001cccc92c42c05aa821872a
24316 255 63 390651840
1 2048 6143 0 0
2 6144 390651806 0 0
# partedUtil getptbl  /dev/disks/naa.600508b1001cccc92c42c05aa821872a
gpt
24316 255 63 390651840
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 390651806 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

get/set では「パーティション番号」「開始ブロック」「終了ブロック」「タイプ」「属性」の順で、getptbl/setptbl では「パーティション番号」「開始ブロック」「終了ブロック」「UUID」「属性」となっている。実際には上記のように、UUIDのあと、そのUUIDの意味がテキストで表示されている。どの用途(ファイルシステムなど)でどのUUIDを使うかは、showGuids オプションで確認できる

# partedUtil showGuids 
Partition Type       GUID 
vmfs                 AA31E02A400F11DB9590000C2911D1B8
vmkDiagnostic        9D27538040AD11DBBF97000C2911D1B8
vsan                 381CFCCC728811E092EE000C2911D0B2
VMware Reserved      9198EFFC31C011DB8F78000C2911D1B8
Basic Data           EBD0A0A2B9E5443387C068B6B72699C
Linux Swap           0657FD6DA4AB43C484E50933C84B4F4F
Linux Lvm            E6D6D379F50744C2A23C238F2A3DF928
Linux Raid           A19D880F05FC4D3BA006743F0F84911E
Efi System           C12A7328F81F11D2BA4B00A0C93EC93B
Microsoft Reserved   E3C9E3160B5C4DB8817DF92DF00215AE
Unused Entry         00000000000000000000000000000000

Linux のパーティションが何故、と思われるかも知れないが、これらは ESXi のブートディスクで利用される。
実際にブートドライブを partedUtil で見たのが、以下だ。

# partedUtil getptbl /dev/disks/naa.600508b1001c7b1101f3c08c5b2c5784
gpt8920 255 63 143305920
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
3 15472640 143305886 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

EFI準拠のため、先頭に EFI パーティションが存在する。LinuxNative の部分がブート用に使用され、vmkDiagnostic がカーネルだんぶ領域だ。最後のVMFSは datastore1 に相当する部分にあたる。パーティションの物理的な所在と、パーティション番号が異なるのも注意を要する。

どのドライブがどのデバイス名を持っているかは、色々調べる方法がある。
こちらのブログのように esxcfg-scsidevs コマンドを使っても良いし、以下のように esxcli でも同じ結果を得られる。

# esxcli storage core  device list
naa.600508b1001c36b38da960b49ca5fbed
   Display Name: HP Serial Attached SCSI Disk (naa.600508b1001c36b38da960b49ca5fbed)
   Has Settable Display Name: true
   Size: 3815350
   Device Type: Direct-Access
   Multipath Plugin: NMP
   Devfs Path: /vmfs/devices/disks/naa.600508b1001c36b38da960b49ca5fbed
   Vendor: HP
   Model: LOGICAL VOLUME
   Revision: 1.28
   SCSI Level: 5
   Is Pseudo: false
   Status: degraded
   Is RDM Capable: true
   Is Local: false
   Is Removable: false
   Is SSD: false
   Is Offline: false
   Is Perennially Reserved: false
   Queue Full Sample Size: 0
   Queue Full Threshold: 0
   Thin Provisioning Status: unknown
   Attached Filters:
   VAAI Status: unknown
   Other UIDs: vml.0200030000600508b1001c36b38da960b49ca5fbed4c4f47494341
   Is Local SAS Device: false
   Is Boot USB Device: false
   No of outstanding IOs with competing worlds: 32

naa.600508b1001c7b1101f3c08c5b2c5784
   Display Name: HP Serial Attached SCSI Disk (naa.600508b1001c7b1101f3c08c5b2c5784)
   Has Settable Display Name: true
   Size: 69973

(後略)

iSCSI/FibreChannel での共有ディストレージやRAIDカード経由の接続の場合はだいたい naa. から始まる名称に、オンボードのSATA/SAS インターフェイスの場合は mpx. から始まる名称になる。

非常に多くの情報が出るので適宜 grep で削ってもいい。お目当てがどのデバイスかは、サイズとやベンダー名、Display Name あたりがヒントになるだろう。

なお、partedUtil について記載している VMware 社のKB1036609 では、ディスクを見つけるのに /dev/disks 以下を調べろ、というなかなか素敵なことが書いてある。

余談だが、VSANで使ってた、個別にマウントされていたHDDを HP社の SmartArray でRAID5で束ねた場合、partedUtil で見るとこんなことになる。

# partedUtil getptbl /dev/disks/naa.600508b1001c36b38da960b49ca5fbed
Error: The backup GPT table is not at the end of the disk, as it should be.  This might mean that another operating system believes the disk is smaller.  Fix, by moving the backup to the end (and removing the old backup)? This will also fix the last usable sector as per the new size. diskSize (7813837232) AlternateLBA (1953459631) LastUsableLBA (1953459598)
Error: The primary GPT table on '/dev/disks/naa.600508b1001c36b38da960b49ca5fbed' is OK, but secondary is corrupt. Fix secondary table? This will move secondary at the end in case it is not at the end already. It will also set LastUsableLBA to use all the space at the end. diskSize (7813837232) AlternateLBA (1953459631) LastUsableLBA (1953459598)
Warning: Not all of the space available to /dev/disks/naa.600508b1001c36b38da960b49ca5fbed appears to be used, you can fix the GPT to use all of the space (an extra 5860377600 blocks) or continue with the current setting? This will also move the backup table at the end if is is not at the end already. diskSize (7813837232) AlternateLBA (1953459631) LastUsableLBA (1953459598) NewLastUsableLBA (7813837198)
gpt
486388 255 63 7813837232
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 1953459598 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

間にすごく長いエラーメッセージが表示されるが、要は、先頭のGPTパーティションテーブルと、末尾にあるはずのバックアップテーブルが一致しない、というエラーになる。

すくなくとも SmartArray では、RAIDを組んだだけでは内容がクリアされない、以前の単一ディスクだったときのどれかのパーティションテーブルが見えてしまうことがあるようだ。
こういう場合は、partedUtil fixGpt <デバイス名> コマンドを実行することで、パーティションテーブルの復元が行われる。


● partedUtil でパーティションを削除する

ここまで分かれば、後は簡単だ。パーティションを削除すれば良い。
ブートドライブや共有ディスクを誤って殺ってしまわないよう、またパーティション番号にも注意して、以下のように partedUtil delete コマンドを実行する

# partedUtil getptbl /dev/disks/naa.600508b1001cb619f764cc6d47de5db0
gpt486388 255 63 7813837232
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 1953459598 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
# partedUtil delete /dev/disks/naa.600508b1001cb619f764cc6d47de5db0 2
# partedUtil delete /dev/disks/naa.600508b1001cb619f764cc6d47de5db0 1
#

delete のあとに、デバイス名とパーティション番号を指定し、うまくいけば、何のエラーも表示せずに消えてくれる。あとは、vSphereClient / WebClient よりストレージの再スキャンを行い、デバイスを再認識させる。

再認識後は、VMFSの作成などで再び選択肢に表示されるようになる。

● VSAN で使っていたSSDの場合

ただ、VSANで使われていた SSD の場合、2つできているパーティションの後者が削除されないという問題が生じた。

# partedUtil getptbl /dev/disks/naa.600508b1001cccc92c42c05aa821872a
gpt
24316 255 63 390651840
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 390651806 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
# partedUtil delete /dev/disks/naa.600508b1001cccc92c42c05aa821872a 1
# partedUtil delete /dev/disks/naa.600508b1001cccc92c42c05aa821872a 2
Error: Read-only file system during write on /dev/disks/naa.600508b1001cccc92c42c05aa821872a

Unable to delete partition 2 from device /dev/disks/naa.600508b1001cccc92c42c05aa821872a

どうやら、SSDについては ESXi の VSAN モジュールが握っており、簡単には解放させてくれないようだ。

これについては、こちらのブログに記載がある。手段としては以下の2つがある。

1. esxcli vsan cluster leave コマンドで VSANを終わらせる
2. 下記の vmkload_mod コマンドで VSAN関連のモジュールを排除し、解除させる
• vmkload_mod -u vsan
• vmkload_mod -u plog
• vmkload_mod -u lsocommon

ただ、ブログにも記載があるが、1. ではうまくいかないことが多いようだ。私の場合、先に1つパーティションを消して情報を欠損させているせいか、やはりうまくいかなかった。
ので 2. にある3つの vmkload_mod を実行した。すると、上記にある Read-only のエラーが出なくなり、パーティションが削除された。

なお、別解としては以下がある

3. SSDの2つあるパーティションのうち一方を削除後、ESXi を再起動

最初の VSANパーティションを削除することで、VSAN関連のモジュールがSSDを見つけ出す標を失ってしまう。それから ESXi もろとも再起動、再初期化することで VSANモジュールが握れなくしてしまうと言う訳だ。

再起動が一回かかるので面倒で時間はかかるが、強制的なモジュール排除などを必要としないのでまだ安全かと思われる。

[余談] Buffalo TS5400 シリーズで管理者パスワードを忘れた場合の対処

職場で Buffalo TS5400R という、ラックマウント型のNASが使えるようになった。

ISOイメージや製品インストーラやアップデータ、検証時のキャプチャ画像など、なにかと一時的なデータの量が多いので、一時的な物置として用意されたのだ。

使ってみると、UIは割と分かりやすく、また HTMLファイルを適当にアップロードすればWebサーバになったり、MySQLやPHPが内蔵されていて動的なWebページを持つサーバとしても利用できる、SOHOでのWebサーバなんてこれがあれば十分じゃないのか?という感じでなかなか良い。
( もっとも、 iSCSI機能については少々 挙動不審なところがある。iSCSI ストレージとして使いたいなら、Terastation IS (TS-RIXシリーズ)を買え、という事なのだろう...、まあ、iSCSI有効にして ESXi に繋ごうとするのがそもそもの間違いというか。)

折角だからと色々試みているうちに、気がついたら管理者パスワードを忘れてしまったのか、管理画面でユーザ:admin、パスワードを知っている限り入力してもログインできなくなった。

しょうがないのでパスワードリセットの方法を探したが、FAQはこのとおり、サポートに電話してもパスワードリカバリーUSBを作ってなければどうしようもない、修理扱いになる、との返事でした。まあ、これはサポートが言う事が正しく、作ってなかった私が悪いのだが。

と、嘆いていても仕方ないので、なんとかしてみることとした。

このNAS、後ろ側を見ると USBポートがあるのはともかく、何故か VGAコネクタと「HDD-USB」と書かれたスライドスイッチなんかがある。ディスプレイを繋ぐと、Linux を起動しているのがよく分かる。

ためしに、USBメモリに適当なx86なLinuxを突っ込んで、スライドスイッチをUSB側にして電源を入れたところ、一応起動はした。どうもCPUも x86っぽい。ならば、USBから起動することでパスワードリセットぐらいできるだろう。

ただ、そのLinuxの選定で苦労した。 gparted-live-0.18.0-2-i486 を使ったところ、どうも起動途中でドライバーが足りないっぽいメッセージで fail する。ubuntu-ja-12.10-desktop-i386 の場合は、こんどは CPUパワーか RAMか何か足りないのか、起動途中でハングアップする。

結局、systemrescuecd-x86-4.2.0 で何とか起動に成功した。この systemrescuecd だが、混まんドライベースになるが結構良くできている。

ともあれ、dmesg をもとにデバイスを判断し、mount /dev/md1 /mnt とかしてマウント、/mnt/etc/shadow ファイルを編集、admin ユーザのパスワードを消して再起動することでパスワードリセットに成功した。

デバイスが /dev/md* になるのは、LVM を使ってない場合に限る。このとき /dev/md0 が /boot に相当、/dev/md1 が / , /dev/md2 が swap になる模様だ。LVMが使われた場合も、割と Linux の標準的な構成になるはずなので、適当に探ってほしい。


なお、ISOイメージから USBメモリにブート可能で書き込むのには、UNetbootin を利用した。これも、Mac 版はどうもうまく動いてないというか、書き込みが終わってもブート可能になってない模様。(他のサイトにもあったが、MBR のアクティブフラグが原因かと考えフラグを立ててみたが、改善されず)
使ってる人も多いだろう  Windows版の場合はまったく問題ないので、深追いせず VMware Fusion 上の Windows7 でさっさと作ってしまった。仮想環境でも、 plopbootmanager を併用すれば起動確認もできる。

ともあれ、仮想化とは全く関係がないのだが、メモ代わりに残しておく。

「セキュリティが強化された Windowsファイアーウォール」が起動不良に陥る

本日ハマったのでメモ。

ふと気がついたら、リモート環境にある WindowsServer 2012 のRDP接続ができなくなっていた。vSphereClient 側から確認するにOSは正しく動いている。が、RDPだけ返答しない。

ファイアーウォールの問題かと思ってMMCを開こうとすると 0x6D9 のエラーを表示してパネルが開かない。そもそも、advfirewall サービスが動いていないようだ。

ググると、同じ問題で困ってる人は居るが、解決したらしい記述がない。

どうも、

a. netsh advfirewall reset
b. net start mpsdrv
c. net start bfe
d. net start mpssvc
e. regsvr32 firewallapi.dll

の手順でコマンドを試せば良いようだが、三つ目の net start bfe でこれまた「エラー 1075: 依存関係サービスが存在しないか、または削除の対象としてマークされています。」を表示する。

このエラー番号から調べて見つけたのが以下のページ

http://www.sevenforums.com/system-security/206716-how-turn-base-filtering-engine.html

こちらにリンクされている「RestoreBFE.exe」を実行、再起動するとBFEサービスも起動し、ファイアーウォールも正常に稼働、RDP接続もできるようになった。

イベントビューアでログを見ると、SQL Server のアップデートがかかってエラーしている記述がある。どうも、エラーが起こってアンインストールが行われる際に、依存関係か何かから BFEもアンインストールを試み? 削除マークだけ残ってる?? という感じっぽい。

再現方法が分からないので確証はないが、以上、私的なメモまで。

Fusion 6.0.3

4/17付けで VMware Fusion 6.0.3 がリリースされております。

リリースノートにも以下の記載があります。

Security Issues

VMware Fusion has been updated to resolve the Heartbleed issue described here. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2014-0160 to this issue.

件の OpenSSL heartbleed 問題にどうも抵触しているみたいなので、Fusion 6 を使ってる方はすぐにアップデートした方が良いです。

ESXi をクローンした場合、互いに通信できなくなる

● 職場で同僚が悩んでた件

ESXi on ESXi で仮想環境上に ESXi を実行しているのだが、どうも vMotion がうまくいかないとの事。vMotion 用の VMkernel Port はもちろん作ってるし、設定を見る限りでは疎通してもおかしくない。

とりあえずと調べているうちに(まあ色々妙な設定は見つかったのでなおしたのだがそれは略して根本だけを見ると)、どうも互いの ESXi 同士の ping / vmkping がいずれも通らないのが原因のようだ。

そして、よくよく見ると気がついたのが、ARPテーブルがうまく作れていない。
ESXi のARPテーブルは「esxcli network ip neighbor list」で確認できるが、相手の項目が作成されないのだ。
で、「esxcfg-vmknic -l」を見てみたら、双方の vmknic が同じMACアドレスを持っている。どうもこれが原因だと判明。

聞いたところ、どうも1台目の ESXi を構成した後、シャットダウンして、クローンを作って2台目を構成したとのこと。どうやら、それが悪かったようだ。

● vmknic のMACアドレス

VMkernel Port のMACアドレスだが、これは以下に見受けられる

・インストール時に指定した管理ポートは、管理用NICのMACアドレスがつく
・後で追加したものは「00:50:56」等から始まるVMwareの仮想用のMACアドレスがつく

ここでうっかりしてしまうのだが、上記の、最初の VMkernel Port (Management Network) のMACアドレスも「仮想」である。つまり、すべての VMkernel Port の MACアドレスは、仮想マシンの仮想NICと同じで仮想MACアドレスである。

VMkernel Port にどの仮想MACアドレスがつくかは、ESXi の管理領域の /etc/vmware/esx.conf に記載されている。つまり、この esx.conf の値を書き換えない限り、同じMACアドレスが割り当てられる。

先の問題は、クローンをしてしまった事から生じる。クローンを実施した折に ESXi を実行する仮想マシンのMACアドレスはもちろん差し替えられる。しかし、さすがに /etc/vmware/esx.conf を書き換えることはないので、起動すると、クローンされた ESXi は、クローン元の ESXi と同じMACアドレスを VMkernel Port に設定してしまう。

クローン元のESXi
vmnic0 (ESXiに繋がってるNIC)のMACアドレスと、
vmk0 のMACアドレスが同じであることが分かる

クローン先の ESXi
vmnic0 は 00:50:56:35:53:52 であるのに対し、
vmk0 は 00:0c:29:2a:a3:cf とクローン元のままだ

冒頭の症状、vMotion 用の VMkernel Port がお互いに通信できなかったのは、同じMACアドレスを持っているため、たとえ異なるIPアドレスを設定しててもL2的には相手が見つけられなかったからだ。

● 修正方法
最も手っ取り早いのは、ESXi はクローンしない、クローンした ESXi 同士をクラスタ挿せるなど連携で使わない、って事だろう。別々のネットワーク、異なる vCenterServer の配下であればまあ問題はないが、同じネットワーク、同じ vCenterServer でクラスタを組むときは個別にインストールする必要がある。ESXi のインストール時間などたかがしてれるので、それぐらいは毎度やってしまえと言うことだ。

クローンしてしまってこの問題に遭遇した場合は、クローン先の ESXi で以下のコマンドを実行するのが手っ取り早い

1. 「esxcfg-vmknic -l」で、VMkernel Port ポートグループと vmknic の対応を確認する

2. 「esxcfg-vmknic -d "<ポートグループ名>"」で、そのポートグループの vmknic を削除

esxcfg-vmknic -d で vmknic を削除
"Management Network" というポートグループが残留しているのがポイント
vSphereClient では分かりにくいが、VMKernel Port も仮想マシン用と同じ
ポートグループがあり、vmknic が一つだけ入っているというだけだ 

3. 「esxcfg-vmknic -a -i <IPアドレス>  -n >>」で、そのポートグループのvmknic を作成

残留している "Management Network" に vmk0 を作成
この時、新しいMACアドレスが裁判されているのが分かる

4. 「esxcfg-vmknic -l」で、設定を確認する(上図)



そもそも、vSphereClient では VMkernel Port が、ポートグループと vmknic でできていることが隠蔽されており、一つのポートのように見えている。このため、VMKernel Port を削除すると、vmknic とポートグループが一気に削除されてしまう。
WebClient ではこの二つが明確に別れて表示されるようになり、どちらを選択して設定ボタンを押したかで設定できる項目に違いが出てくる。

WebClient での表示
Management Network を選択するとこの通りポートグループ全体が選択される

WebClient での表示
ポートグループの仲の vmk0 を選択すると、vmknic だけが選択される

上記のコマンドは、この事を利用して VMKernel Port に設定されたチーミングやセキュリティ設定などを保存しつつ、また管理用の VMKernel Port がなくなって混乱する時間を最低限にしつつ、vmknic を作り直してMACアドレスを再生成させるという手順なわけだ。

※ 2014/5/28 付記

クローンを行う前に仮想環境上の ESXi で以下のコマンドを実行する事でも、回避はできる。

esxcfg-advcfg -s 1 /Net/FollowHardwareMac

察せられるように、NICのMACアドレスが変わったら取りなおすというものだ。
...今思いついたが、クローンした後でも、クローン先のESXiで個別に実行してから再起動しても何とかなりそうだな。

vExpert 2014 受賞しました

今年も vExpert 2014 を受賞できました。ありがとうございます。

https://blogs.vmware.com/vmtn/2014/04/vexpert-2014-announcement.html

Hyper-V on Fusion

知己からの相談。Hyper-V 上の Linux (CentOS 6.5)が正しく動かないと。
CentOS 6.5 は Hyper-V のサポートリストにないと返答し逃れようとしたら、いや、統合サービスがカーネルに統合されているし動くはずだとの主張。そして送られてきたスクリーンショットを見たら、ただの Hyper-V ではなく、Fusion 上の WindowsServer 2012 であった。

Hypervisor on Hypervisor はテクがいるんだよと煙に巻いたのだが、しかしやったことがない、できないでは何とも面白くないのでサンフランシスコ出張中、まだ真っ暗闇の3時頃にむくっと起き上がり手元で構築をやってみた時のメモを再構成したのが以下のものだ。

なお、WindowsSever 2012では面白みがないので、今回は Windows 8.1 Enterprise の Client Hyper-V を使ってみた。

● Fusion 上で Hyper-V を実行させ、その上でLinuxを動かす条件

条件は以下の通りだ。

1. Windows8 は 64bit 版がインストールされていること
2. 仮想マシンの設定の「プロセッサとメモリ」にある「この仮想マシンでハイパーバイザーアプリケーションを有効にする」にチェックが入っていること
3. 以下2行を VMX ファイルに書き足してあること

• mce.enable = "TRUE"
• hypervisor.cpuid.v0 = "FALSE"

4. Hyper-V 上の仮想マシンのMACアドレスを"固定"させること

64bit 版でないと Hyper-V は利用できないのでこれは当然と言える。2. の設定により、vmx ファイルに 

vhv.enable = "TRUE"

が書き込まれる。ESXi など VMware製品ではこの設定だけで動くが、Hyper-V の場合、「Hyper-V をインストールできません。: ハイパーバイザーが既に実行されています」と出る(下図)

これを回避するために、3. のオプションを指定し、MCE(Machine Check Exception)拡張を有効にし、CPUID命令でハイパーバイザを検出されないようにする必要がある訳だ。

ここまでで Hyper-V は動作するが、このままだと知己の言うとおりでHyper-V 上の仮想マシンでの Linux がインストール後の起動時に panic してしまう。

この事象の回避には、「Hyper-V 上の仮想マシンのMACアドレスを静的にする」ことが必要なわけだ。この点は少々厄介なので、以下の手順を見て欲しい。

● インストールの実際

では、実際のインストールを追ってみよう。

まず、Fusion で仮想マシンを作成する。Windows8.1 のメディアかイメージがあるなら話は早い。

Fusion のメニューから「ファイル」-> 「新規...」を選び、「ディスクまたはイメージからインストール」を選んだまま「続く」ボタンを押せばいい。

簡易インストールパネルでアカウント名やプロダクトキーを入力、仮想マシンを作成すればOSのインストールから初期設定、ライセンス投入、VMware Tools のインストールまで一気にやってくれる。

インストールが終わったら一旦仮想マシンを停止して、先の条件2と3のセットをしておこう。(もちろん、仮想マシンの作成の折に「設定のカスタマイズ」を押して、作成後すぐに仮想マシンを起動させず、設定を編集するタイミングを作っても良い。なお、このときフロッピードライブを削除しないように。)

また、メモリサイズもデフォルトの 2GB から Hyper-V上の仮想マシンの実行分増やしておいた方がいいだろう。

Windows8.1 のデスクトップの左下端には復活したスタートボタンがある。ここを右クリックするとコントロールパネルに素早くアクセスできる。

今回は「プログラムと機能」を選択、Hyper-V をインストールする。

インストール後に再起動がかかるので、またログインし直し、デスクトップの右側から「Hyper-V マネージャ」を検索、でてきたら右クリックして「管理者で実行」をする

(普通の実行でも問題ないかもしれない)

Hyper-Vマネージャが起動したら、まず仮想スイッチマネージャから仮想スイッチを一つ作っておく。インターネットに接続する必要がある場合は「外部」で作っておく。また、「外部」の仮想スイッチを作ると以後 Windows8側のNICがプロミスキャスモードで動こうとして、その結果認証のパネルが表示される。都度パスワードを入れて許可しておこう。

さて、次はHyper-Vでの仮想マシンの作成だ。

Hyper-Vマネージャの「編集」メニューから「新規」「仮想マシン...」を選択、ウィザードに従って仮想マシンを作成する。

「仮想マシンの世代」をきかれたら第一世代にしておく。第二世代は Windows 8,WindowsServer 2012 でないと意味がないからだ。

ネットワークの構成では、先に作った仮想スイッチを指定しておく。

メモリサイズとストレージ容量は適当でいいが、今回は 512MBと10GBを指定した。それぞれ動作チェックのため節約をしただけだ。

インストールは CentOSの ISOイメージから行うが、「Fusion 側でWindows8仮想マシンに ISOメディアをマウントして、Hyper-V側仮想マシンはDドライブを参照」と、「Windows8仮想マシンにISOメディアをコピーしておき、Hyper-V側仮想マシンでISOメディアをして」の二つのやり方が考えられるが、どうも前者はあまり安定しないようだ。面倒でも ISOイメージをコピーして、後者のやり方にした方がいい。

さて、ISOイメージを仮想CD-ROMにマウントさせたら、Hyper-V側で仮想マシンを起動する。

そして、CentOSのインストーラが起動したら、"Hyper-Vマネージャで仮想マシンの電源を落とす"。ここが重要なポイントだ。

Hyper-V側で仮想マシンを停止させた後、Hyper-Vマネージャで仮想マシンを右クリック、「設定...」を選択し設定パネルを開き、「ネットワークアダプター」の「+」ボタンを押し項目を展開、「高度な設定」から「MACアドレス」の「動的」のラジオボタンを「静的」に変更する。

動的に変更後、その下の6つの入力項目に00ではない、十六進の数値が入っていることをちゃんと確認した後、OKを押し設定を閉じる。

その後、Hyper-Vマネージャにて仮想マシンを起動、通常の手順で Linuxをインストールすればちゃんとインストールでき、その後もエラーなく利用が可能だ。

● Hyper-VのMACアドレスの仕様

Hyper-Vのデフォルトでは、MACアドレスの設定が「動的」になっており、仮想マシンの起動の際にMACアドレスが自動生成される。

ここまではまあ構わないのだが、困ったことに、このままだとMACアドレスは起動のたびに変わりうる。どうもそこで齟齬が起こり、パニックしているようだ。この件についてはマイクロソフト社のフォーラムにも記載がある。

手っ取り早く直すのに、MACアドレスを「静的」にして一意に固定してしまえばいいのだが、しかし一度も起動していないHyper-Vの仮想マシンは、MACアドレスが00-00-00-00-00-00 になっている。

これはこれで問題の元のため、「動的のまま一度起動することで適当なMACアドレスを割り当てさせ、その後停止、割り当てたアドレスのままで静的に設定を変更し、MACアドレスを固定する」という手順になる。

なお、クロックのところでパニックしているのでLinux側のクロックソースを直す、という解法もあるようだ。

ただ、CentOSを含むRHEL6系のOSでは、インストール時にMACアドレスを記憶してそのMACアドレスを持つNICに指定したIPアドレスを割り当てるようにする。MACアドレスがころころ変わると、その都度IPアドレスの設定をやり直す必要が出てくる。どのみち、MACアドレスは固定する必要がある。

そもそも Fusion 上で CentOSを動かせばこんな面倒はないのだし、やる人はそうそういないと思うが、引っかかると言えば引っかかるところなので、メモとして残しておく。