備忘録: Cisco CMLをHyper-Vで動かす

Cisco公式のNWシミュレーションツールCML2はVMWare上での動作しかオフィシャルサポートされていません。標準の設定ではHyper-V上で動作させることは出来ませんが２つの修正を加えることで動作させることが出来ました。
<font color="red">Ciscoは、CMLのHyper-V上の動作は保証していません。この記事はCMLで本来開放されている以外の設定を触るため、CMLが正常に動作しなくなる可能性もあります。</font>

# Hyper-Vを使うに至った理由
<font color="red">以下は私のWindowsやHyper-Vへの知識が低く誤った記載をしている可能性が十分にあります。</font>

生活にはWSL2が必須です。しかし、調べた限り、WSL2を有効にした状態ではVMWare Workstation(15.7)のVT-x仮想化がenableに出来なかったためです。
- Windows上でWSL2を用いる場合、Hyper-Vが(Hyper-Vマネージャで見えない)裏側で動作します。
- これによりCPUのVT-xがユーザからは無効に見えます(CPU-Zなどで確認可能)
- VT-xとWSL2との共存はWebを調べるとWindowsの`ハイパーバイザープラットフォーム`の機能を有効にし、VMWare Workstation 15.5以降であればVT-xとの共存は可能のように見えます。しかし、私の試した限りWSL2を有効にしたままVMWare WorkStationでVT-xを有効にした仮想マシンの起動ができませんでした

# Hyper-VでCMLを使う課題
- 課題1: VT-xの仮想化相当がenableになっていない
- 課題2: VMWareとHyper-VではNIC Driverの差分があり、I/F名の差分が出てCMLのExt-ConnのBridgeモードが動作しない

VMWareとHyper-Vに乗せたときのCMLの気持ちを示します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/30938/21dd5fb0-cba3-ef45-14b6-39be3420bb8f.png)


# インストール手順
- ISOファイル(`cml2_2.4.1-34_amd64-13.iso`と`refplat-20220211-fcs.iso`)をダウンロードする
- Hyper-Vのクイック作成からインストール元のISO`cml2_2.4.1-34_amd64-13.iso`を指定してマシン作成。
    - メモリは適当に容量を増やす。
    - ディスクサイズは問われないが標準で128G(Thin Provision)作成されるので特に触らない。
- <b>作業1:</b>作成後、インストール前に[このページ](https://learn.microsoft.com/ja-jp/virtualization/hyper-v-on-windows/user-guide/nested-virtualization)を参考にしながらVT-x enableを行う。VMwareでの`仮想化エンジン > Intel VT-x/EPTを仮想化`をONにするためである。
    - 仮想マシンをオフにする
    - 管理者モードでPower Shellを立ち上げ`Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true`を実行する。
    - ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/30938/1fdfa229-dbfe-d980-d484-249a2ad9c079.png)

- インストールは通常通り行う。VMWareでのインストールと同じく途中で`refplat-*.iso`に入れ替える。
- Hyper-Vの仮想スイッチマネージャで`外部ネットワーク`のSWを作成し、VMのネットワークに割り当てる。(既存の１つのNICをこれに切り替えます)
    - <img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/30938/d9de9176-9c80-3582-7d41-a0bd771b2597.png width=50%>
- また、割り当てたインタフェースの高度な設定から"無差別モード"をONにする
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/30938/fa99e624-1b29-1356-42e3-edd0029717a6.png)

- (以下の作業はHyper-Vのコンソール上で行います。sshで接続してもshellは取れません)
- <b>作業2:</b>起動した後に以下の作業を行う
    - `ip link show eth0` で MACアドレスを記録する
    - `sudo vi /etc/systemd/network/10-eth0.link`を作り以下のようなファイルを作る。MACAddressは記録したeth0のアドレス
        - ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/30938/18548c74-b026-8892-9378-1f0f55bcf83e.png)
    - `sudo cat /etc/NetworkManager/system-connections/bridge0-p1.nmconnect` (p1は他の文字列の可能性もある)をして、`interfase-name=eth0`がある場合、eth0をens160に書き換える
- 再起動する。`ip link show eth0`が存在しなくなったことを確認し、`ip link show ens160`が存在することを確認する。

# 作業2の補足:
- CMLはens160がCMLのI/F名だと前提にExt-ConnのBridgeの設定を行います。
- CML自身はLinuxのBridge機能を利用しており、`brctl addif bridge0 ens160`相当のコマンドが実行されるようです。
- VMWare上ではインタフェースは`vmxnet3`と認識され、この場合、`vmxnet3のeth0`は`ens160`にrenameされます。(これがどのような設定でrenameしているのかを筆者は見つけていません。)
    - この挙動は`dmesg`でrenameしているログが見えます
- 一方、Hyper-Vではインタフェースは`vmxnet3`ではないと認識され(おそらく`e1000`?)`eth0`のまま残ります
- この結果、bridgeにVM上の外部とのI/Fが接続されず外部NWとの接続に失敗します。

このため、上記のようにsystemd.linkで`ens160`へのrenameを行います。

なお、Ext-Connを`NAT`で使う場合上記の問題は起きません。これは次のように考えられます。

- Ext-Connの`NAT`とは、`virbr0`:IPアドレスを持つL3インタフェースと接続され、外部との間はNATされます。
- iptablesで以下のようにNATが書かれています(`iptables --list -t nat`)が、これにI/F名は含まれません。そのため外部への接続性が`eth0`でも`ens160`でもNAPTは正常に動作します。
    - <img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/30938/e13ae8e4-7805-b1a8-7122-c1453a269f99.png width=50%>

# 最後に
繰り返しですが、<font color="red">Ciscoは、CMLのHyper-V上の動作は保証していません。この記事はCMLで本来開放されている以外の設定を触るため、CMLが正常に動作しなくなる可能性もあります。</font>