仮想マシンが、ネットワーク接続できないときに見直すこと

開発環境として重宝される仮想マシンのVirtualBox、たとえばテスト環境や開発環境で使用しているマシンを振り分けたい場合は、クローンという便利な機能があります。

ところが、このvdiのマシンをクローンしてipアドレスを振り分けても、ネットワークに接続できない現象が発生します。本記事は、この解決方法です（vmdxでは問題ないようです）。

![vm1jpg.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/272191/edb60d18-31a6-2ee7-6cf0-edac230870ae.jpeg)

この**75@Nginx with Nodejs**がクローンで生成した仮想マシンとなります。


# 接続設定
まずは、クローン元のipアドレスを調べてみると**192.168.11.76**でした。なので、現状ではクローンされた仮想マシンのアドレスも192.168.11.76のままのはずなので、これを手動で192.168.11.75に切り替えてみます。

```
# nmcli c modify enp0s3 ipv4.addresses 192.168.11.75
```

ところがftpやブラウザに接続できなかったのでipアドレスを調べてみると、192.168.11.39と全く別のアドレスが表示されていることがわかりました。
![ipaddr.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/272191/9a6289ec-5ce9-e9bb-edfd-45ce5a7e77b9.jpeg)
不思議に思い、GUIで確認してみます。すると、このように表示されていました。**nmtui**（network manager text user interface）でネットワーク接続用のGUIを起動することができます。

```
#nmtui
```

![gui1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/272191/68b6d71b-b68c-201c-bbca-54dcd30f4c13.jpeg)

とりあえず、この文字化けしているものが気になりますが、enp0s3というネットワークを確認してみると、設定した通りになっているようです。

![nmtui_edit.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/272191/d3df233a-cb22-cd43-5333-705d44f34182.jpeg)

手動設定の反映にはネットワークの再起動が必要なのかと思い、再起動してみるとエラーが表示されました。
![cui_errormes.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/272191/72636985-5504-d768-d8f5-de661bb6e96f.jpeg)
これを`journalctl -xe`コマンドで確認してみます。どうも赤く表示されている警告があります。
![journal.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/272191/7d529188-da04-c6a0-977d-c87340e89968.jpeg)

そこを読んでいるとこうあります。
**failed to start lsb bring up/down networking**

つまりは、ネットワークに接続できないというエラーです。

## 原因は？

しばらく原因を考えてみると、ふと気になるものがありました。さっきの文字化けしたネットワーク情報の中身を確認します。
![nopperabou.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/272191/631f1c9d-bd37-8fa4-3270-ff28ae14c2a9.jpeg)
DHCPによって自動でipアドレスが振り分けられ、MACアドレスが設定されているようです。このMACアドレスをメモ帳にでも控えておきます。改めて、元のターミナルからip addrで調べてみると、どうやらこの文字化けしたノッペラボウのネットワークにつながっていたようです。

# 結論
クローンのマシンがipアドレスを変えただけで接続できないのは、仮想マシンの標準エンコードが異なるためにネットワーク名が文字化けしてしまい、**ネットワーク名が曖昧になってしまう現象が発生することと、それによって本来接続すべきMACアドレスが異なってしまうため**です。

### 原因１：仮作成されたネットワーク
vdiのクローンを作成すると、エンコードのせいでネットワーク名は新規で仮作成されることになり、DHCPによってipも自動生成されます。とはいえ、名前がノッペラボウ状態なので、このままでは何もできませんし、従来のネットワークを妨害しているためネットワークの再起動もできません。なので、この仮作成されたネットワークを削除しておく必要があるのですが、今回は既存のネットワーク名を使用するので、**MACアドレス**の情報だけメモ帳などに控えておきます（万が一、すぐに消してしまってもip addrコマンドでわかるので大丈夫です）。

MACアドレスを控えたら、この仮ネットワーク名は不要なので削除しておきます（再作成される場合もありますが、構わず削除してしまってください）。
![gui_delete2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/272191/33277d4f-92e2-4629-3407-6c2c3099bc3d.jpeg)

### 原因２：MACアドレス
ネットワークが自動生成されるということは、それに合わせてMACアドレスも自動的に割り振られます。そして、ネットワークはそのアドレスを探そうとします。なので、接続させたいネットワーク名の方のMACアドレスを、割り振られたアドレスに書き換えます。
![gui_changemac.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/272191/6970ce4a-4272-9c67-7653-2970f2d815c0.jpeg)
あとはネットワークを再起動するだけで、晴れてネットワーク接続が可能になります。
![cui_restart.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/272191/7ca2f8f2-29d1-983f-95f8-94d3f35b593a.jpeg)
## 応用
VMwareからovftoolエクスポートしたvmxファイルをVirtualBoxにインポートした場合やマシンを別の場所に移行した場合もネットワーク接続できない現象が発生しますが、この対応で解決します。

※誤ってvmdkファイルをインポートしようとすると、起動時にカーネルパニックが発生しますので間違わずに。