えんでぃの技術ブログ

えんでぃの技術ブログ

ネットワークエンジニアの視点で、IT系のお役立ち情報を提供する技術ブログです。

Fedora36の変更点

fedora_logo

Fedoraの変更点シリーズ

過去リリース分の記事は、以下のリンクを参照してください。

Fedoraの変更点シリーズ

お伝えしたいこと

Fedora36のリリースノートを読んで、個人的に気になった項目をまとめます。

公式情報の見方

Fedora 36の変更点は、以下のリンクに載っています。
概要はリリースノートに、詳細情報はChange Setsのページに書いてあります。

Change Setの各サブタイトルのリンクから詳細情報に飛べるようになっています (下図赤枠部)。
詳細を知りたい時に便利なので、こちらも活用ください。

fedora_change_sets

Fedora36の既知の問題は、以下にまとめられています。

他バージョンのFedoraについて知りたい場合は、以下のリンクを参照してください。

Release Notes & Changes

remove-retired-packagesコマンドがインストール可能に

Fedora公式リポジトリremove-retired-packagesというパッケージの配布が開始されました。

remove-retired-packagesコマンドを使うと、その名の通りretired packagesを自動的に検出してアンインストールを提案してくれます。

retired packagesとは、Fedora公式リポジトリで配布されなくなったパッケージのことです。
retired packagesになる主な理由は、アップストリームの更新が停止したことが挙げられます。

デフォルトでは1世代前のFedoraバージョンからretired packagesを検出して、対象のパッケージに対してdnf removeを実行します。
remove-retired-packages 34のように引数を指定することで、検索範囲を広げてくれます。

更新が停止したパッケージを残しておくとセキュリティリスクがありますので、Fedoraをバージョンアップするたびにこのコマンドを実行することが推奨されます。

過去記事のFedoraのOSバージョンアップ手順remove-retired-packagesの使い方を追記しましたので、詳細はこちらをご覧ください。

/etc/sysconfig/network-scripts/ifcfg-* がデフォルト無効に

Fedora36以降、NetworkManagerはデフォルトで/etc/sysconfig/network-scripts/ifcfg-*ファイルを一切使わなくなります。
それどころか、/etc/sysconfig/network-scripts/フォルダ自体存在しなくなります。
追加のRPMパッケージをインストールすれば従来の構成に戻すことは可能ですが、ifcfg-*は今後なくなっていく流れですので、それに逆行することは推奨しません。

Connectionの定義ファイルを直接見ることがない方にとっては、この変更点はほぼ影響ありません。
例えば、普段nmcliを使っている方に取ってはあまり気にならないと思います。
もしもifcfg-*ファイルを編集してnmcli reloadsystemctl restart NetworkManager.serviceなどで設定を再読込する運用をしている方がいれば、今回の変更は重要なものになります。
少数派だと思いますが...。

では、詳細に移ります。
この先は興味のある方のみお読みください。

全体像を理解するために、今までのLinuxのネットワーク設定変更の主だった動きを追ってみます。
私の知識の偏りにより、RHELFedoraが混在した時系列になっていますがご了承ください。

RHEL6の頃、ネットワーク設定変更といえば以下の流れが主流でした。

  • /etc/sysconfig/network-scripts/ifcfg-*ファイルを編集する
  • service network restartによって反映する

RHEL7以降は、NetworkManagerを常時有効化することが主流となりました。
NetworkManager利用した設定変更の方法は複数ありますが、nmcliコマンドによる変更が最も基本的だと思います。

NetworkManagerには、/etc/NetworkManager/NetworkManager.confという設定ファイルがあります。
この設定ファイルにはpluginsという設定項目があり、デフォルトではコメントアウトされています。

#plugins=keyfile,ifcfg-rh

nmcliなどで変更したconnection設定はOS再起動後ももちろん残ります。
その裏では、NetworkManagerが設定内容をファイルに保存しています。

私はあまりやったことがないのですが、NetworkManagerを使っている環境においてもこの設定ファイルを書き換えて、nmcli connection reloadコマンドによって設定ファイルを再読込させることが可能です。
ファイルを書き換えるよりも、nmcli connection modifyコマンドを使うほうが一般的だと思いますが...。

さて、この「Connection設定が保存されたファイル」がどのような形式で、どういったファイルパスに保存されるかを指定するのが上述のplugins設定です。
plugins設定はNetworkManager.confで明示的に指定することが可能ですが、コメントアウトされている場合にはディストリビューション固有のデフォルト値を取ります。

pluginsの取りうる値は、man NetworkManager - #PLUGINSに書いてあります。

ここで紹介するpluginsは以下の2つのみです。

plugins 説明
keyfile
  • 最も基本形のフォーマット
  • NetworkManagerと必ず同梱される
  • INI形式
  • /etc/NetworkManager/system-connections/*に格納される
ifcfg-rh
  • RHEL系のレガシーなフォーマット
  • /etc/sysconfig/network-scripts/ifcfg-*に格納される

ここでFedoraバージョン依存の話が出てきます。

Fedoraのバージョンが上がるにつれて、pluginsのデフォルト値は以下のように変遷しました。1

バージョン pluginsのデフォルト値
Fedora32以前 ifcfg-rh,keyfile
Fedora33以降 keyfile,ifcfg-rh

ifcfg-rh,keyfileは、「基本的にifcfg-rhを優先するが、もしこのPluginが利用不可だった場合にはkeyfileを使う」という意味です。
keyfile,ifcfg-rhはその逆で、「keyfileを優先し、次にifcfg-rhを使う」という意味になります。

keyfile Pluginは、NetworkManagerRPMファイルに必ず同梱されます。
一方で、ifcfg-rhについてはFedoraのバージョンによって以下のように構成が変わりました。
これがFedora36の差分です。

バージョン RPMパッケージ
Fedora35以下
  • NetworkManagerに同梱される
  • 初期状態でifcfg-rhプラグインを利用可能
Fedora36以降
  • NetworkManager RPMパッケージに同梱されない
  • 初期状態ではifcfg-rhプラグインを利用不可
  • NetworkManager-initscripts-ifcfg-rh
    RPMパッケージを別途インストールすれば使える

Fedora36以降は、ifcfg-rhプラグインがデフォルトでインストールされません。
また、/etc/sysconfig/network-scripts/ディレクトリもデフォルトで存在しません。

レガシーなifcfg-rhは今後なくなっていく流れですので、今後はkeyfileを使うことを前提に考えると良いと思います。

NetworkManager-initscripts-ifcfg-rh RPMパッケージを導入してifcfg-rhを使い続けるという選択肢もありますが、恐らくあまり良い選択ではありません。
このパッケージが今後提供されなくなる可能性が少なくないためです。

Bugs

Bugsの中から気になる情報を拾います。

Fedora36にアップデートした後SELinuxの不具合が出る

タイトルのとおりです。
投稿された事例では、dnf upgrade, flatpak update, setseboolなどのコマンドを実行した時にWarningが出たとのことです。

回避策は、Fedoraをバージョンアップする前にsudo dnf upgradeでパッケージを最新化しておくことです。
これはFedoraバージョンアップの公式手順にも記載されていることですので、マニュアル通りに作業していれば問題ありません。

Fedora36で事象が発生してしまったときのワークアラウンドとしては、以下が紹介されています。

  1. SELinux関連パッケージを再インストールする
  2. 1で直らなかった場合は以下を実施
    1. SELinuxの関連モジュールを停止する
    2. SELinux関連パッケージを再インストールする
    3. SELinuxのrelabelを行う

サイト上で紹介されているコマンドは一例です。
環境に応じて実行するコマンドを変更する必要があると思います。

ちなみに、私がもし事象を踏んだときは以下の手順で対処すると思います。
私は事象を踏んでおらず、未検証の手順なのでご参考までに...。

まず、事象を踏んだときのコマンドを覚えておきます (sudo dnf upgradeなど)

続いて、SELinux関連パッケージを再インストールします。
この時、再インストールすべきパッケージは以下のコマンドで洗い出します (※)
(※) SELinuxのコアなパッケージはselinux-policyselinux-policy-targetedの2つです。そして、製品に対応したSELinuxの追加ルール (Security Policy) をインストールするパッケージは、製品名-selinuxというパッケージ名であることが多いです。したがって、以下のコマンドで必要なパッケージは一通り洗い出せます

dnf list installed *selinux*

上記を実施後、事象が継続しているかを確認します (例えば、sudo dnf upgradeを実行し、Warningが発生するかを確認します)

事象が継続している場合、以下の手順を実施します。

個人的には、sudo fixfiles onboot-Fを指定する必要はないかなと思います。
-Fを指定しても害はありませんが、通常の環境 (targeted policy) では指定してもしなくても差はありません。

まとめ

興味を持ったトピック限定ですが、Fedora36の更新点をまとめました。

FedoraにSlackをインストールする方法 (Snap利用)

お伝えしたいこと

Snapによって、FedoraにSlackをインストールする手順を紹介します。

FedoraでSlackをインストールする場合、現状Snapを使うのが最も無難な方法だと思います。
その理由については、#(参考) Snapを使う理由に記載しましたので、興味のある方はご確認ください。

Snapとは

SnapはLinuxにソフトウェアをインストールするパッケージの1種です。
以下の特徴を持ちます。1

Snapdのインストール

snapコマンドはsnapdデーモンと共に動作します。
Fedora上でsnapコマンドを使用するために、snapdをインストールします。

sudo dnf install snapd

snap versionsnapsnapdのバージョンが表示されれば、正しくインストールできています。

snap version
# snap    2.55.3-2.fc35
# snapd   2.55.3-2.fc35
# series  16
# fedora  35
# kernel  5.16.12-200.fc35.x86_64

インストール後、一旦ログインし直します。
再ログイン後、PATHの末尾に/var/lib/snapd/snap/binが追加されます。
これにより、Snapでインストールした実行ファイルにPATHが通るようになります。

echo $PATH
/home/stopendy/.local/bin:/home/stopendy/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/var/lib/snapd/snap/bin

なお、PATHの追加は、/etc/profile.d/snapd.shにて行われていました。

Slackのインストール

Snapでパッケージをインストールする際は、以下の流れで進めます。

  1. パッケージを探す
  2. Confinementを確認する
  3. インストールする

パッケージを探す

snap findコマンドでパッケージを部分一致検索できます。

snap find slack
# Name   Version  Publisher  Notes  Summary
# slack  4.25.1   slack✓     -      Team communication for the 21st century.
# (以下略)

Publisherslack✓と記載されている通り、チェックマークがついています。
これはパッケージメンテナがSnapの運営元によって公式であると確認済みであることを示しています (※)
(※) snap find --helpより

パッケージは、snapcraftのWEBサイト上でも検索できます。
https://snapcraft.io/slack

Confinementを確認する

オンラインリポジトリ上のSnapのConfinementを確認するには、snap info --verboseコマンドを使います。

snap info --verbose slack
#   confinement:       strict
# (一部のみ抜粋)

Confinementは、Snap上で動作するアプリケーションがシステムに対してどの程度アクセス権限を持つかを表します。
Confinementの値によってはインストール手順が若干変わってくるので、ここで確認しておく必要があります。

ConfinementはSnapパッケージがビルドされた時点で決まっています。
したがって、私達ユーザーが選ぶことはできません。

Confinementは3つの値を取りえます。
私達が使うパッケージは、通常strictかclassicのいずれかです。3, 4

  • strict
    • 最も一般的なconfinement
    • アプリケーションからシステムへのアクセスを適切に制限する
    • アクセス先によっては、ユーザー操作を求める (カメラなど)5
    • 許可されないアクセスは拒否する
  • classic
    • アプリケーションからシステムへのアクセスを無条件で許可する
    • classicのパッケージをインストールする前に#初期設定が必要
    • sudo snap install --classicでインストールする
  • devmode
    • 開発者向けのモード
    • 許可されないアクセスはログ出力するが、実際には許可される
    • アプリが必要とする権限の洗い出しに使えそう
    • sudo snap install --devmodeでインストールする

インストールする (strict confinementの場合)

以下のコマンドでSlackをインストールします。
Slackパッケージのconfinementはstrictなので、特にオプション指定は不要です。

sudo snap install slack

その他の基本コマンド

インストール済みのSnapパッケージを一覧表示します。

snap list
# Name   Version  Rev  Tracking       Publisher  Notes
# slack  4.25.1   61   latest/stable  slack✓     -
# (一部抜粋)

パッケージを更新するコマンドです。

sudo snap refresh

Snapパッケージを削除するコマンドも記載します。

デフォルトでは、snap restoreによって復元するためのデータを保管します。
この場合はsnap remove後もsnap listでパッケージが表示されます。
--purgeオプションを指定することで、復元用のデータを残さずに削除します。

# sudo snap remove --purge slack

(参考) Snapを使う理由

2022年3月1日以降、SlackはFedora公式リポジトリで配布されなくなりました。

slack.com - System requirements for using Slack

slack_system_requirements

SlackをFedora Linux上で動作させる公式の手段は主に2つです。

  1. RPMファイルを公式サイトからダウンロードしてインストールする
  2. Snap版のSlackをインストールする

1のRPMは、Slackのリポジトリ情報を含みません。
したがって、今後Slackをバージョンアップしたいときには都度RPMファイルをダウンロードしてインストールする必要が出てきます。
これではあまりに不便です。

そこで、2のSnap版が出てきます。
Snap版であればオンラインリポジトリにSlackが配布されているので、sudo snap refresh slackコマンド1つでSlackをバージョンアップできます。

Fedora上でSlackを使いたい場合には、Snapを使うのが正攻法だと思います。

管理が面倒になるので、DNF以外のパッケージマネージャーを使うことには多少なりとも抵抗を覚えるかもしれません。
しかし、FedoraからSlack公式のリポジトリを使うにはSnapしか現状なさそうなので、私は割り切りました。

(参考) classic confinementのパッケージインストール

classicの場合の手順についても触れておきます。
今回はVS Codeをモデルにします。

VS CodeFedoraリポジトリで提供されるので、わざわざSnapでインストールする必要はありません。
ここでVS Codeをインストールしているのは、あくまで例示のためです。

Confinementの確認

VS Codeのconfinementは、2022年5月現在classicです。

snap info code --verbose
# publisher: Visual Studio Code (vscode✓)
#   confinement: classic
# (一部抜粋)

初期設定

Classic confinementのパッケージをインストールするには、/snapシンボリックリンクを作成しておく必要があります。6

sudo ln -s /var/lib/snapd/snap /snap

シンボリックリンクを作成せずにインストールしようとすると、以下のようなエラーが出ます。

sudo snap install --classic code
# error: cannot install "code": classic confinement requires snaps under /snap or symlink from /snap
#        to /var/lib/snapd/snap

インストール

インストールの際は--classicオプションを付与します。

sudo snap install code --classic

--classicオプションを付与しないと、以下のエラーが出ます。

sudo snap install code
# error: This revision of snap "code" was published using classic confinement and thus may perform
#   arbitrary system changes outside of the security sandbox that snaps are usually confined to,
#   which may put your system at risk.

#   If you understand and want to proceed repeat the command including --classic.

まとめ

Snapによって、FedoraにSlackを導入する手順を紹介しました。

Linux PC関連まとめ

endy-tech.hatenablog.jp

GNS3で踏みがちなトラブルと回避方法

お伝えしたいこと

GNS3は幾度もリリースされ、今ではかなり安定して動作します。

しかし、それでもGNS3を使っていると現実のネットワーク機器では考えられないようなトラブルに見舞われることがあります。
VMが起動しなかったり、ケーブル直結なのにARPが通らなかったり...。

本記事では、GNS3を使っている時に踏みがちなトラブルと回避方法を紹介します。

文字化け

GNS3において、日本語 (※2バイト文字) は全力で避けてください。
GNS3上のマシン名はもちろんのこと、GNS3のバックエンドで動作しているVirtualBoxQEMU上のVM名やファイルパスも含めてです。
VMだけでなく、仮想ディスクやISOファイルのファイル名、ファイルパスも気をつけてください。

GNS3が発行する命令に日本語が混ざると、文字化けしてエラーになります。
結果として、仮想マシンの起動/停止/追加/削除が一切できなくなります。

参考情報として、GNS3が各種連携ソフトに命令を送るイメージを下表に示します。
以下のnameに日本語が混ざると不具合の原因になります。

仮想化エンジン コマンドイメージ
VMware Workstation Player vmrun [options...] name
VirtualBox VBoxManage [options...] name
Docker docker [options...] name
QEMU qemu-system-x86_64 [options...] name

GNS3 GUI上の操作は電源を切ってから

GNS3 GUI上の操作とは、以下のようなものを指します。

  • GNS3上のケーブル配線
  • GNS3のノードを右クリックしてConfigureからの設定変更

もちろん、コンソール接続や電源OFF操作などは問題ありません。

これらの操作を行うと、本来通るはずの通信が通らなくなることがあります。
結果として、ケーブルで直結されたLinuxからARPを出してもL2スイッチ上でMACアドレステーブルを学習しない...なんてホラーが起こりえます。
「VACL設定したっけ...?」と頭を悩ませるより先に、まずはGNS3観点で疑いましょう。

この事象から復旧するには、以下のいずれかの操作が必要です。

  • 操作箇所に隣接する全てのVMの電源OFF/ON
  • 操作箇所に隣接する全てのVMの削除/再作成
  • GNS3の再起動
  • ホストマシンのOS再起動

面倒ですが、ホストマシンのOS再起動が最も確実です。

仮想マシンをグループに所属させないこと

VirtualBoxは、仮想マシンを右クリックしてグループに追加できます。
...が、この機能を使ったときGNS3が正しく動作しないことがあります。
あまり仮想マシンをグループに追加しないほうが良いと思います。

具体例としては、以下の操作を行った時にGNS3 Projectを開けなくなりました。
結果として、GNS3 Projectを作り直すことになりました...。

  • VirtualBox VMVirtualBox上でグループに追加する
  • GNS3上でUse as a linked base VMを有効化する
  • GNS3 Projectを保存して、GNS3を一旦終了する
  • 保存したGNS3 Projectを開き直す

セキュリティソフトに要注意

GNS3は内部的に様々な実行ファイルを実行し、またlocalhostに対してTCP/UDP通信を行います。

GNS3をWindowsで動かしているとき、Windowsファイアウォールがしばしばこのような通信をブロックします。
結果として、 GNS3上ではケーブルが直結しているのに何故か通信が通らない といったことになります。
原因は、GNS3上の通信に利用されているUDP Tunnel通信をブロックしているためです。

Windowsファイアウォールであれば、設定にもよりますが通信をブロックしたときにポップアップが出ると思います。
そこで通信を許可するための操作を行えば問題ありません。

ここで誤って「拒否」を選択してしまった場合はWindows Firewallに拒否ルールが追加されてしまいます。
その場合は、Windowsファイアウォールの規則を編集し、該当の拒否ルールを削除するようにしてください。
アプリケーションにGNS3やDynamipsが含まれていれば、それが問題のルールだと思います。

まとめ

GNS3周りの主なトラブルと回避方法を紹介しました。
皆様の時間節約につながれば幸いです。

GNS3とlibvirtの仮想ネットワークをブリッジ接続する

お伝えしたいこと

GNS3上に追加した仮想マシンlibvirtの仮想ネットワークに接続する方法を紹介します。

仮想マシンは、必ずしもQEMU上で動作している必要はありません。
例えば、VPCSのような仮想マシンではないノードも含めてlibvirtの仮想ネットワークに接続し、DHCPIPアドレスを付与したり、ホストマシンと通信させることが可能です。

libvirtネットワークに接続することで、ホストマシンからVMへのSSHや、VMからインターネットへのアクセスが可能となります。

前提条件

本記事の手順は、GNS3とlibvirtベースのKVM環境のセットアップが完了していることを前提としています。
セットアップがこれからの方は、それぞれ以下のリンクを参照してください。

KVM環境について補足すると、仮想ネットワークが作成済みであることが一番重要です。
仮想ネットワークの構成については、以下のコマンドで確認できます。

仮想ネットワークが作成済みで、NATやDHCPIPアドレス範囲が適切に設定されていることをご確認ください。

virsh net-list
#  Name        State    Autostart   Persistent
# ----------------------------------------------
#  default     active   yes         yes

virsh net-dumpxml default
# <network>
#   <name>default</name>
#   <uuid>b130cf72-a5eb-4414-9fd8-7d1182f2b50b</uuid>
#   <forward mode='nat'>
#     <nat>
#       <port start='1024' end='65535'/>
#     </nat>
#   </forward>
#   <bridge name='virbr0' stp='on' delay='0'/>
#   <mac address='52:54:00:96:e6:67'/>
#   <ip address='192.168.122.1' netmask='255.255.255.0'>
#     <dhcp>
#       <range start='192.168.122.101' end='192.168.122.254'/>
#     </dhcp>
#   </ip>
# </network>

(参考) 前提知識

本ブログで実施する手順について、前提知識となる情報をこちらのセクションで紹介します。
既にご存知の方は読み飛ばしても結構です。

libvirtの仮想ネットワーク

libvirtの仮想ネットワークは、VirtualBoxでいうところのホストオンリーとNAT相当の機能を持ちます。

libvirtの仮想ネットワークとVMを接続することで、VMから以下の通信ができるようになります。

  • ホストマシンとの通信 (SSH, HTTPS, SCP, ...)
  • libvirt組み込みのDHCP/DNSサーバの利用
  • ホストマシン外部への通信 (インターネット通信など)
  • 仮想ネットワークを介した他VMとの通信

GNS3のCloud node

今回は、GNS3のCloud nodeを使ってlibvirtネットワークとの接続を行います。

Cloud Nodeとは、いわゆるブリッジ接続を提供する機能のことです。
GNS3上で以下のようにCloud Nodeを追加して配線することで、ホストマシン上のNICとブリッジ接続できます。

gns3_cloud

Cloudと聞くと「AWSなどのクラウドサービスと接続する機能?」と思われるかもしれませんが、実際には単なるブリッジ接続のことです。
ブリッジ接続とは、「ホストマシンのNICとL2スイッチ越しに接続された状況」を仮想的に実現する機能です。
もちろん、ホストマシンのNICが複数存在する場合は「どのNICとブリッジ接続するか」を設定することができます。

仮にCloud nodeがホストマシンのEth0とブリッジ接続するよう構成したと仮定します。
この時、論理的には以下のような構成になります。

bridge_nw_diagram

手順

本セクションで、GNS3上で動作しているVMlibvirtの仮想ネットワークと接続するための手順を紹介します。
前述の通り、GNS3のCloud nodeを使用します。

virbrインターフェース番号を調べる

libvirtの仮想ネットワークは、ホストマシン上ではvirbrX (※Xには0以上の数字が入る) というインターフェース名で表現されます。
Cloud nodeでブリッジ設定を行うために、まずはこのインターフェース名を調べておく必要があります。

まず、目的の仮想ネットワーク名を調べます。
今回はdefaultという仮想ネットワーク名が対象だったとします。
(※) gns3という名前で、GNS3検証環境用の仮想ネットワークを作るのも良いと思います。それにより、既存のKVM仮想マシンが持つIPアドレスとの重複を気にせず、より自由にIPアドレスを割り当てられるようになります

virsh net-list

#  Name        State    Autostart   Persistent
# ----------------------------------------------
#  default     active   yes         yes

続いて、defaultに対応するインターフェース名を確認します。
以下の情報より、virbr0であることがわかりました。

以降のセクションでvirbr0に対するブリッジを設定します。
インターフェース番号が異なる方は読み替えてください。

virsh net-info default

# Name:           default
# UUID:           b130cf72-a5eb-4414-9fd8-7d1182f2b50b
# Active:         yes
# Persistent:     yes
# Autostart:      yes
# Bridge:         virbr0

(参考) GNS3上でCloud Nodeを使用する

GNS3の初期設定なしでCloud nodeを使うための手順を紹介します。
初期設定したほうが便利なので、こちらの手順は参考程度にご覧ください。

まず、GNS3を起動します。
そして、End devicesセクションからCloud nodeを追加します。
また、Cloud nodeと接続するための仮想マシンももう一台追加しておきます。

use_default_cloud1

cloudをダブルクリックして、設定画面を開きます。
Show special Ethernet interfacesにチェックを入れて、ドロップダウンリストからvirbr0を選択してAddから追加します。
OKを選択して設定画面を閉じます。

use_default_cloud2

VMからcloudのvirbr0に対して配線します。
これでVMvirbr0にブリッジ接続したことになります。

use_default_cloud3

ここで設定としては一旦完了です。
以下で正しくネットワークが構成されていることを確認します。

今回の環境では、virbr0は以下の構成になっているとします。
(※) 仮想ネットワークの定義は、#前提条件に記載したvirsh net-dumpxmlを参照してください

  • NAT有効 (インターネット接続性あり)
  • NWアドレスは192.168.122.0/24
  • DHCP有効 (192.168.122.101-254)

VMを起動してIPアドレス設定や疎通性を確認します。
VMではDHCPが有効化されているため、仮想ネットワークからIPアドレスが割り振られました。
また、インターネット通信が可能であることも確認できました。
curlのオプションは、HTTP応答ステータスコードのみを表示するよう出力を整形するためのものです。

ip address show ens3

# 2: ens3
#     inet 192.168.122.250/24
# (一部のみ抜粋)

curl -so /dev/null -w '%{http_code}\n' https://www.google.co.jp

# 200

以降のセクションでは、Cloud nodeの設定を保存して使いまわすための手順を紹介します。

Cloud Nodeの登録

まず、GNS3の設定画面を開きます。
(※) Edit > Preferences、またはCtrl+Shift+P

Cloud nodesの画面でNewを選択してCloud nodeを追加します。

add_cloud1

作成するノードの名前を聞かれるので、わかりやすい名前を設定しましょう。
今回はホストからのログインやインターネット通信に使う「管理用ネットワーク」という意味を込めてManagement networkとしました。

add_cloud2

Cloud Nodeの編集

作成したCloud nodeを更に編集します。
以下の画面のようにEditを選択し、更に編集しましょう。

edit_cloud1

Ethernet interfaces

Ethernet interfacesでは、virbr0のみをブリッジ先として登録しておきます。
他のインターフェースは配線の際に邪魔になるので、除外しておきましょう。

操作方法としては以下のようになります。

  • Show special Ethernet interfacesにチェックを入れる
  • ドロップダウンリストからvirbrXを選択する
  • Addを選択する

edit_cloud2

Misc.

Misc.タブでは、お好みに合わせて枠で囲んだ箇所を中心に設定します。

ネットワーク名はmgmt_NW{0}という名前をつけました。

アイコンはAffinity Circle Greencloudに変更しました。
他のアイコンと区別しやすいように、管理用ネットワークのアイコンや配線を緑色に統一しようという思想です。

edit_cloud3

こちらで設定は完了です。
OKを選択して設定画面を閉じてください。

登録したNodeを使う

登録したCloud nodeをドラッグ&ドロップして追加すれば、保存した設定のCloud nodeを直ちに使うことができます。
アイコンがわかりやすくて便利だと思います。

Cloud nodeの便利な使い方

Cloud nodeの使い方について、便利なテクニックをいくつか補足します。

L2スイッチに接続して使う

GNS3上で、Cloud nodeには1本しか配線できません。
したがって、複数のVMと配線したい時は間に組み込みのL2スイッチを配置するのが定石です。

私の環境では、前述の通りに作成したCloud nodeとセットで使うためのL2スイッチをカスタマイズして作成しました。
動作はデフォルトのcloudと全く同じなのですが、見やすさのためにノード名とアイコンのみカスタマイズしました。
これも管理ネットワークを緑色に統一するためです。

L2スイッチを追加するには、GNS3の設定画面のBuilt-in > Ethernet switchesから設定してください。

設定内容を以下に示します。
Default name formatSymbolのみ編集しました。
SymbolはAffinity Circle Greenswitchです。

edit_l2_switch

配線の色も変更する

GNS3上でケーブルを右クリックすると、ケーブルの色や太さを変更することができます。
ケーブル本数が増えるとどうしても見づらくなってしまうので、管理用途とサービス用途でケーブルの色を変えることで対策できると便利です。
下図に例を示します。

green_cables

複数のCloud nodeを追加しても良い

Cloud nodeに接続するホストが増えてくると、だんだんと配線がつらくなってくると思います。
例えば上記の構成図において、更に上にもう一台L3SW2が増えた場合はどうでしょうか?
一番下のmgmt_SW1から配線しようとすると、ケーブルが重なって見づらくなってしまいます。

そんなときは、同じCloud nodeをもう一つ追加して配線しちゃいましょう。
こういった配線でも、全てのL3SWとServerは問題なく管理ネットワークと接続できます。

multiple_clouds

まとめ

GNS3のCloud nodeを使って、libvirtの仮想ネットワークとVMを接続する手順を紹介しました。

今回の手順により、VMへの管理アクセス、VMからのインターネット接続、そしてVM間通信が全て可能となります。
しかしあれこれ繋いでしまうと広大なL2ネットワークになってしまうので、ほどほどに。
virbrとのブリッジ接続は、主に管理用のネットワークに使うと良いと思います。

もちろん、物理ネットワーク機器とGNS3上のVMをブリッジ接続するためにCloud nodeを利用するのも良い使い方です。
その場合は、eth0などの物理NICとブリッジ接続するようCloud nodeを設定します。
これが一番王道的なブリッジ接続の使い方ですね。

GNS3・QEMU上でvEOSを起動する

お伝えしたいこと

Arista vEOSをGNS3上で起動するためのセットアップ手順を紹介します。
Arista vEOSとは、Arista社が提供するL3SWの仮想アプライアンス (VM版) です。

今回は仮想化ドライバにQEMUを使います。
QEMUは、GNS3をLinux上で動かしている方に向いています。

Arista vEOSのダウンロード

Arista Software Downloadのページからダウンロードします。
(※) URLの通り、トップページからSupport > Software DownloadのリンクでSoftware Downloadページにアクセスできます

このページにアクセスするには、Arista社にユーザー登録する必要があります。
vEOSを利用するだけであれば、Arista社から製品を購入していなくてもアカウント登録できます。
アカウント登録完了から実際にログインできるまで、数十分ほどラグがあったと思います。

ログインできたら下の方へスクロールし、vEOS-lab配下の以下2ファイルをダウンロードしてください。

  • Aboot-veos-serial-x.x.x.iso (最新版を選択)
  • vEOS64-lab-x.xx.xM.vmdk (Mがつく中で最新版を選択)

download_veos

(参考) AbootとAboot-serial

AbootはvEOSのBootloaderです。
Aboot-veosはシリアルコンソール非対応版、Aboot-veos-serialはシリアルコンソール対応版です。

vEOSをGNS3上で動かす場合はシリアルコンソールに対応していたほうが便利なので、Aboot-veos-serialを使いましょう。

(参考) vEOSの推奨バージョンの選び方

Arista Software DownloadRecommended Releasesタブに記載がありますが、Arista vEOSの推奨バージョンはMがつく中での最新版です。

MはMaintenance Releaseという意味であり、いわゆる安定版です。
基本的にはM付きの最新版を選ぶのが無難です。

Fというフラグがついたバイナリもありますが、これはFeatureの略です。
最新版の機能を追加したリリースであることを意味しています。
どうしても試したい機能が最新版でリリースされたときのみ、最新版のF付きリリースを試しても良いかもしれません。

vEOSをGNS3に登録する

手順の大半はGNS3・QEMU上でLinuxを起動すると同様です。
したがって、今回はややシンプルに手順を説明します。

詳細が気になった方は、上記記事をご確認ください。

(参考) vEOSの動作要件

CloudEOS and vEOS Router - Using the vEOS Router on KVM and ESXiによると、vEOSの動作要件は以下のとおりです。

項目 推奨値
vCPUコア数 最低2コア、最大16コア
RAMサイズ 最低4GiB
ディスクサイズ 最低8GiB
仮想NIC 最大8まで

仮想ディスクファイルの格納

#Arista vEOSのダウンロードでダウンロードした2ファイルを~/GNS3/images/QEMU/配下に格納してください。
これらのファイルは、現在のユーザーが読み書きできる必要があります。
(正確には、gns3serverプロセスが読み書きできる必要があります)

ls -l ~/GNS3/images/QEMU/Aboot-veos-serial*.iso ~/GNS3/images/QEMU/vEOS64-lab*.vmdk
# -rw-r--r--. 1 endy endy   6291456 Apr 29 12:06 /home/endy/GNS3/images/QEMU/Aboot-veos-serial-8.0.1.iso
# -rw-r--r--. 1 endy endy 473235456 Apr 29 12:07 /home/endy/GNS3/images/QEMU/vEOS64-lab-4.26.5M.vmdk

GNS3にQEMU仮想マシンとして登録する

本セクションでは、準備した仮想ディスクファイルをGNS3に登録します。

まずはGNS3を起動し、Edit > Preferences (Ctrl+Shift+P) から設定画面を開きます。

左のメニューからQEMU VMsを選択し、NewボタンからQEMUで再生する仮想マシンを新規登録します。

create_qemu_vm1

わかりやすい仮想マシン名を入力します。
今回はvEOSとします。

register_veos1

QEMUコマンドのパスを指定します。
今回は/usr/bin/qemu-kvmとします。

RAMサイズはvEOSの動作要件に合わせて4096 MiBとします。

register_veos2

コンソールタイプを選択します。
シリアルコンソールが便利なので、telnetを選択します。

register_veos3

セットするディスクファイルを選択します。
ここではAboot-veos-serial-x.x.x.isoを選択します。
vEOS64-lab-x.xx.xM.vmdkは、後ほどVMの編集画面でセットします。

register_veos4

QEMU仮想マシンをカスタマイズする

前セクションで登録した仮想マシンを更にカスタマイズします。
作成した仮想マシンを選択し、Editから更に設定変更します。

edit_veos1

以降のセクションでは、変更した箇所をピンクの枠で囲みます。

General settings

アイコンはL3SWに近い印象のswitch_multilayerを選択しました。
CPUコア数は、ホストマシンのスペックに応じてご検討ください。

edit_veos2

HDD

Disk interfaceはvirtioを選択します。

また、ディスクファイルは以下のようにセットしてください (※)
ディスクファイルは~/GNS3/images/QEMU/配下に格納されています。
(※) CloudEOS and vEOS Router - Launching vEOS in LinuxBridge ModeによるとISOファイルをHDCに、ディスクファイル (qcow2)をHDAにセットしていますが、これでは動きません。Abootを先に起動し、Abootからディスクファイル内のEOSを起動するのが本来の起動順序なので、Abootの方が起動の優先順位を高くする必要があります。LinuxQuestions.org - IDE master/slaveの情報も踏まえ、起動デバイスであるAbootをPrimary Masterに配置するのが良いでしょう

接続先 ディスクファイル
HDA
(Primary Master)
Aboot-veos-serial-x.x.x.iso
HDB
(Primary Slave)
vEOS64-lab-x.xx.xM.vmdk

edit_veos3

CD/DVD

CD/DVDは特にいじりません。

edit_veos4

Network

Arista vEOSを含め、多くのNW機器の仮想アプライアンスは先頭ポートがManagement、2ポート目以降がサービスポートという扱いになります。
Arista vEOSの場合、ポートアサインは下表のようになります。
(※) ポートアサインは実機にログインして確認しました

VMNIC番号 vEOS上のinterface#
0 Management1
1 Ethernet1
2 Ethernet2
3 Ethernet3
4 Ethernet4
5 Ethernet5
6 Ethernet6
7 Ethernet7

GNS3上も上記のような表示名で見せるために、下図のような設定としました。
Ma1のような省略表記にした理由は、トポロジ上のNIC番号は短い表記の方が扱いやすいためです。

NIC数は動作要件に合わせて8に、性能向上のためにドライバはvirtioにしました。

edit_veos5

Advanced

Advancedは特にいじりません。

edit_veos6

Usage

最低限のコメントのみ書いておきました。

edit_veos7

vEOSの起動

登録したvEOSをGNS3上で起動します。

SwitchのカテゴリからvEOSをドラッグ&ドロップで追加します。

launch_veos1

vEOSのアイコンを右クリックし、Startを選択して起動します。

launch_veos2

vEOSのアイコンをダブルクリックしてシリアルコンソール接続します。
ターミナルが起動しない場合は、GNS3・QEMU上でLinuxを起動する - #Console applicationsを参考にしつつ、GNS3が既定で呼び出すコンソールアプリケーションを設定してください。

(参考) Arista vEOSへのログイン

起動には数分かかります。

大量のsyslogメッセージが見えてきた頃にEnterキーを押すとログインプロンプトが出てきます。

adminユーザーでログインします。
パスワードは不要です。

ログイン後、以下のコマンドを実行してZTP (※) を停止します。
ZTPを停止しないとstartup-configを生成できないためです。

zerotouch cancel

zerotouch cancelを実行すると、vEOSが再起動します。
起動してきたら再びログインし、以下のコマンドを実行します。

enable
copy running-config startup-config

これでZTPが恒久的に停止します。

(参考) ZTPとは

ZTPとは、Zero Touch Provisioningの略語です。
LinuxでいうPXE Bootと似たような概念です。

ZTPを利用すれば、Aristaの管理ポートを接続して電源投入するだけでコンフィグ投入が自動的に完了します。
ZTPの原理は、専用のZTP用サーバからDHCPIPアドレスを受け取り、startup-configかスクリプトをダウンロードしてセットアップを行うというものです。

(参考) ZTPを無効化する方法

参考: YouTube - Networking Institute - Implementing Zero Touch Provisioning(ZTP) on Arista Switches
(※) 無料ユーザーではArista公式情報から詳細な情報を得られませんでした。Networking Instituteは、非公式ながらAristaの情報について正確かつ詳細に解説しているので、今回こちらを情報源とさせていただきました

Arista EOSの起動時、以下の2つの条件を満たせばZTPが開始されます。
(※) zerotouch cancelという例外パターンもありますが、この後説明します

  • /mnt/flash/startup-configが存在しないこと
  • /mnt/flash/zerotouch-configDISABLE=Trueと書かれていないこと

初期状態のArista EOSは、上記のどちらのファイルも存在しないためZTPを開始する条件が揃っています。

ZTPを停止する方法は大きく分けて2つあります。

  • zerotouch cancelを実行し、再起動後にcopy running-config startup-configを実行する
  • zerotouch disableを実行する

zerotouch cancelを実行すると、直後にEOSが再起動します。
そしてZTPが無効化された状態でEOSが起動します。

zerotouch cancelによるZTPの無効化は一時的なものです。
copy running-config startup-configによって/mnt/flash/startup-configを生成すれば、ZTPの無効化が永続的なものとなります。
startup-config生成前に再び再起動すると、ZTPが有効化されて起動してきます。

zerotouch disableによるZTPの有効化は永続的なものです。
このコマンドの実行により/mnt/flash/zerotouch-configDISABLE=Trueが書き込まれます。
これにより、startup-configの有無に関わらずZTPが永続的に無効化されます。

(任意) ZTPを予め無効化しておく

ZTPを使わない場合、毎回zerotouch cancelを実行するのは面倒だと思います。
そこで、本セクションでは予めZTPを無効化した上でテンプレート化するための手順を紹介します。

まず、~/GNS3/images/QEMU/配下にあるvEOSのvmdkファイルをコピーしておきます。

cd ~/GNS3/images/QEMU/
cp -pi vEOS64-lab-4.26.5M.vmdk vEOS64-lab-4.26.5M_zerotouch_disable.vmdk

続いて、GNS3を起動して設定画面を開きます (Ctrl+Shift+P)
QEMU VMsセクションにて、作成済みのvEOSの設定をコピーします。
新しいVMの名前を求められるので、vEOS (ZTP Disabled)としておきます。

copy_veos_vm_settings

続いてEditからvEOS (ZTP Disabled)の設定をカスタマイズします。

edit_veos_ztp_disabled1

General settingsタブで、Default name format{name}-{0}からvEOS-{0}に変更します。

edit_veos_ztp_disabled2

HDDタブで、HDBに先ほどコピー作成したvmdkファイルをセットします。
(※) vEOS64-lab-x.xx.xM_zerotouch_disable.vmdk

edit_veos_ztp_disabled3

Advancedタブで、Use as a linked base VMのチェックを外します。
これにより、GNS3上にVMを追加した際のVMクローン処理が無効化され、VMテンプレートを直接書き換えることができます。

edit_veos_ztp_disabled4

作成したvEOS (ZTP Disabled)をGNS3上で起動します。

launch_veos2

起動したvEOSにシリアルコンソールで接続し、adminユーザーでログインします。
そして以下のコマンドを実行することでZTPを恒久的に無効化します。

zerotouch disable

vEOSの再起動後、再びadminユーザーでログインします。
そして、以下のコマンドによってOSをシャットダウンします。

enable
bash
sudo shutdown -h now

vEOSをGNS3上で右クリックして削除します。
これによってvEOS (ZTP Disabled)はGNS3のトポロジ上からは消えますが、実際にはZTPが無効化された設定込のデータが~/GNS3/images/QEMU/vEOS64-lab-x.xx.xM_zerotouch_disable.vmdkに残っています。

delete_veos_on_gns3

最後に、vEOS (ZTP Disabled)の設定を開き、AdvancedタブからUse as a linked base VMを再び有効化します。

edit_veos_ztp_disabled5

以上の操作により、ZTPが無効化されたvEOSテンプレートを作成できました。

まとめ

Arista vEOSをGNS3上にQEMU VMとして追加する手順を紹介しました。
前回記事LinuxVPCSと組み合わせれば、vEOSを使った一通りのハンズオンができると思います。

参考サイト

ネットワークチェンジニアとして - Arista vEOSの基本的な使い方

Arista vEOSのダウンロード方法について、本ブログよりも更に丁寧に解説されています。
またGNS3ではありませんが、ESXiへのvEOS登録手順が解説されています。

vEOSのダウンロードとセットアップ手順を調べる際、大いに参考にさせていただきました。

記事内のリンクにvEOSでよく使いそうなMLAGやVXLAN、EVPNの解説もあります。
こちらは、GNS3セットアップ後の検証を行う上で大変役に立ちます。

GNS3・QEMU上でLinuxを起動する

お伝えしたいこと

LinuxをGNS3上で動作させる手順を紹介します。

GNS3上でQEMUベースのLinux VMを登録する手順を扱います。
Linux上でGNS3 Serverを動作させる構成において役に立つと思います。

本記事は、ホストマシンがGNS3とKVM環境をセットアップ済みのLinuxであることを前提にしています。
KVMのセットアップ手順については、KVMの初期設定、及びvirsh, virt-installによるVM作成を参照してください。

Linuxの準備

GNS3上でQEMU仮想マシンを動作させるには、GNS3に仮想ディスクファイル (※qcow2など) を登録する必要があります。
もちろん、その仮想マシンファイルにはLinuxがインストールされている必要があります。

シリアルコンソールに対応したい場合は、Linuxインストール後に#(任意) シリアルコンソールへの対応も実施しておいてください。
シリアルコンソールに対応しておいた方が使い勝手が向上するため、任意とは言いつつも実施しておくことをおすすめします。

(参考) Linux VMの作成手順

ご参考までに、KVMLinux VMを作成するための簡易手順を示します。

CLIで行う場合は、以下のようなコマンドでLinuxマシンを新規作成、及び起動します。
以下のコマンドはCentOS Stream 8の例です。

virt-install \
--name centos_stream8 \
--memory 1024 \
--vcpus 2 \
--disk size=20 \
--cdrom /home/shared/libvirt/images/isos/centos/CentOS-Stream-8-x86_64-latest-dvd1.iso \
--os-variant centos-stream8 &

やり直し用に、VMの強制終了、及び削除のコマンドサンプルも示します。

virsh destroy centos_stream8 ; virsh undefine centos_stream8 --storage vda

CockpitなどのGUIによるVM作成手順については、KVMの基本操作集 - #VMの作成を参考にしてください。

(任意) シリアルコンソールへの対応

本セクションの作業は任意です。
この手順によって、Linuxにシリアルコンソール接続できるようにします。

GNS3上でLinuxを操作する場合はシリアルコンソールに対応させたほうが便利なので、本セクションの手順も含めて実施することを推奨します。

(参考) シリアルコンソールとは

GNS3にKVMベースのLinux VMを追加したとき、管理アクセスの選択肢としてデフォルトでは主に以下の選択肢が挙げられます。

  1. GNS3上のネットワーク経由でログインする
    • SSHHTTPSを初めとして各種プロトコルが使える
    • ファイル転送もできる (SCPやFTPなど)
    • GNS3上の配線に依存する
    • 管理IPアドレスの設定が必要
  2. グラフィカルコンソール経由でログインする
    • サーバー本体に直接キーボード、マウス、ディスプレイを接続するのと同等
    • GUIにも対応可能
    • ホストマシンからコピペしづらいのが不便

グラフィカルコンソールとは、以下の画面のことです。

graphical_console

上記2つの方式にはそれぞれ弱点があります。
1はネットワークアクセスのために配線と初期設定が必要です。
2はホストマシンからのコピペがしづらいです。

そこで、本セクションでは第三の選択肢としてシリアルコンソール経由でのログインを使えるように設定変更します。

シリアルコンソールとは、例えばネットワーク機器にロールオーバーケーブルで接続してアクセス可能な画面のことです。
シリアルコンソールを使えば、ネットワーク接続性がなくてもコピペに対応したCLIアクセスが可能です。
その代わり、ファイル転送やGUI表示はできませんので、そこは他の方式と使い分けが必要です。
CLIベースのLinuxであれば、グラフィカルコンソールよりもシリアルコンソールの方が便利です。

Linuxをシリアルコンソールに対応させるには、Linux側で初期設定が必要です。
その手順は次のセクションで紹介します。

Linuxの設定変更

対象のLinuxマシンにログインして、GRUB 2の設定を変更することでシリアルコンソールを有効化します。

まずは、変更前の設定を事前に確認しておきます。

# (更新行のみ抜粋)

sudo grubby --info=ALL

# index=0
# args="ro crashkernel=auto resume=/dev/mapper/cs-swap rd.lvm.lv=cs/root rd.lvm.lv=cs/swap rhgb quiet $tuned_params"

# index=1
# args="ro crashkernel=auto resume=/dev/mapper/cs-swap rd.lvm.lv=cs/root rd.lvm.lv=cs/swap rhgb quiet"

sudo cat /etc/default/grub

# GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/cs-swap rd.lvm.lv=cs/root rd.lvm.lv=cs/swap rhgb quiet"

続いて設定を変更します。

sudo grubby --update-kernel=ALL --args="console=tty0 console=ttyS0,115200"

設定を確認します。
grubby --info=ALLargsと、/etc/default/grubGRUB_CMDLINE_LINUXのそれぞれに、console=tty0 console=ttyS0,115200が追記されていることがわかります。

# (更新行のみ抜粋)

sudo grubby --info=ALL

# index=0
# args="ro crashkernel=auto resume=/dev/mapper/cs-swap rd.lvm.lv=cs/root rd.lvm.lv=cs/swap rhgb quiet console=tty0 console=ttyS0,115200 $tuned_params"

# index=1
# args="ro crashkernel=auto resume=/dev/mapper/cs-swap rd.lvm.lv=cs/root rd.lvm.lv=cs/swap rhgb quiet console=tty0 console=ttyS0,115200"

sudo cat /etc/default/grub 

# GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/cs-swap rd.lvm.lv=cs/root rd.lvm.lv=cs/swap rhgb quiet console=tty0 console=ttyS0,115200"

OS再起動して更新を反映します。

sudo reboot

ご参考までに、consoleオプションを削除して元の値に戻したい場合は以下のコマンドを実行します。
今回の手順ではもちろん実行する必要はありませんので、コメントアウトしてあります。

# sudo grubby --update-kernel=ALL --remove-args="console"

(参考) 実施した手順の意味

上記のgrubbyコマンドで一体何を変更したのかを補足します。
気になる方のみお読みください。

(参考) grubbyとは

grubbyとは、Boot Entryの設定値を表示、変更するコマンドラインツールです。
RHELではこのコマンドによってGRUB 2の設定変更をすることが推奨されています。1

grubbyコマンドを使用するパターンも含めて、GRUB 2の設定を変更する方法は3つあります。
興味のある方は、以下のリンクもご確認ください。
参考: RHEL7 - System Administrator’s Guide - 26.2. Configuring GRUB 2

(参考) Boot Entryとは

過去記事を参照してください。

(参考) consoleオプション

今回書き換えたのは、GRUB 2からLinux Kernelに渡すパラメータの1つです。
consoleオプションの仕様は、以下のLinuxカーネルのドキュメントに記載があります。
参考: The Linux kernel user’s and administrator’s guide - Linux Serial Console

Linuxのデフォルトではグラフィカルコンソール (/dev/ttyX) のみが有効化され、シリアルコンソール (/dev/ttySX) は有効化されません。
今回はconsoleオプションを2回指定することで、グラフィカルコンソールとシリアルコンソールをそれぞれ有効化しています。

シリアルコンソールの指定ではconsole=ttyS0,115200を指定していますが、これは以下のような意味を持ちます。

  • /dev/ttyS0バイスを生成する (※ttyS0は、COM1と同義)
  • ボーレートを115200に指定している (※デフォルトは9600。115200に変更することで表示速度を上げている)

RHEL7のSystem Administrator’s Guideでもconsoleオプションについて言及されています。2,3
ここで言いたいことは、今回実施した手順はRHELのドキュメントでもある程度裏打ちされたものであるということです。

LinuxをGNS3に登録する

VM設定の全体像

先に設定の全体像を示しておきます。
GNS3に既に慣れている方は、以下の画面だけで手の動かし方が十分に伝わると思います。

先にCentOS Stream8の例を示します。

centos_stream_8CentOS Stream 8の設定

CentOS Stream 9のVMを建てる場合のみ、QEMUのオプションに-cpu hostを追加で指定する必要があります。
このパラメータを指定するのは、CentOS Stream 9とQEMUの相性問題を回避するためです。
詳細は#Advancedを参照してください。

centos_stream_9CentOS Stream 9の設定

仮想ディスクファイルの格納

ここまでの手順で、Linux VMの作成が完了しているはずです。
作成した仮想マシンから、仮想ディスクファイルを取り出しましょう。

KVM環境の場合は、virsh domblklist 仮想マシン名で仮想ディスクファイルのパスを確認できます。

virsh domblklist centos_stream8

#  Target  Source
# ---------------------------------------------------
#  vda     /home/shared/libvirt/images/centos_stream8.qcow2

作成した仮想マシンから仮想ディスクファイルを取り出し、~/GNS3/images/QEMU/に格納しておきます。

cp /home/shared/libvirt/images/centos_stream8.qcow2 ~/GNS3/images/QEMU/

取り出した仮想ディスクファイルが現在のユーザーから読み書きできることを確認してください。
権限が足りていない場合は、chmodchownで変更しておきましょう。

sudo chown $USER:$USER ~/GNS3/images/QEMU/centos_stream8.qcow2
chmod 644 ~/GNS3/images/QEMU/centos_stream8.qcow2

ls -lh ~/GNS3/images/QEMU/centos_stream8.qcow2
# -rw-r--r--. 1 endy endy 11G Apr 13 21:06 /home/endy/GNS3/images/QEMU/centos_stream8.qcow2

この段階で仮想ディスクファイルは既に取り出せたので、#Linuxの準備で作成したVMは削除しても問題ありません。

GNS3にQEMU仮想マシンとして登録する

本セクションでは、準備した仮想ディスクファイルをGNS3に登録します。

まずはGNS3を起動し、Edit > Preferences (Ctrl+Shift+P) から設定画面を開きます。

左のメニューからQEMU VMsを選択し、NewボタンからQEMUで再生する仮想マシンを新規登録します。

create_qemu_vm1

仮想マシン名を入力します。
今回はCentOS Stream 8とします。

create_qemu_vm2

QEMU Binaryとメモリ容量を設定します。

QEMU Binaryは、/usr/bin/qemu-kvmを選択します。
ただ、ほとんどの方はデフォルトのまま/bin/qemu-system-x86_64を選んでも同じ意味になります (※)
RAMにはLinux VMに割り当てたいメモリ容量を指定します。
(※) Fedoraの環境では/bin/usr/bin/へのシンボリックリンクです。/usr/bin/qemu-kvmは、KVMに対応したCPUアーキテクチャのバイナリに対するシンボリックリンクとなっており、x86_64アーキテクチャのCPUを使っているなら/usr/bin/qemu-system-x86_64と同じ意味になります。ここで大事なのは、ホストマシンのCPUアーキテクチャに対応したQEMUバイナリを選択することです。CPUアーキテクチャuname -mコマンドなどで確認できます。ARMなど他アーキテクチャのCPUを使っている方は選択肢が変わることもあります。わからない方は/usr/bin/qemu-kvmを選んでおけばほぼ間違いないと思います

create_qemu_vm3

最後に、GNS3からコンソール接続するときの方式を選択します。

シリアルコンソールを使いたい場合は、telnetを選択してください。
グラフィカルコンソールを使いたい場合は、vncspiceを選択してください。
今回、私はtelnetを指定しました。

create_qemu_vm4

最後に、QEMUにセットする仮想ディスクファイルを決定します。
今回は予め用意しておいたcentos_stream8.qcow2を指定します。

create_qemu_vm5

QEMU仮想マシンをカスタマイズする

前のセクションの手順により、GNS3上にQEMU仮想マシンが登録されました。
作成した仮想マシンを選択し、Editから更に設定変更します。

edit_qemu_vm1

General settings

まずはGeneral settingsタブです。
変更した箇所をピンクの枠で囲いました。
vCPUs以外はほぼ見た目にしか影響のない変更です。
お好みに合わせてカスタマイズしてください。

edit_qemu_vm2

各設定の意味を下表にまとめました。

設定項目、デフォルト値、意味 今回の設定値
Template name
デフォルト: なし

  • VMテンプレート名
  • わかりやすい名前をつける
CentOS Stream 8
(※) デフォルトと同じ
Default name format
デフォルト: {name}-{0}

  • GNS3トポロジに追加後のノード名
  • 短い方が扱いやすい
  • {}で変数が使える
    • {name}: Template nameの値
    • {0}: 0から始まる連番
cs8-{0}
Symbol
デフォルト: :/symbols/qemu_guest.svg

  • アイコン
  • お好みで選択する
:/symbols/affinity/circle/blue/server.svg
Category
デフォルト: End devices

  • VMのカテゴリを選択
  • 見た目にのみ影響する
  • わかりやすいものを選択する
End devices
(※) デフォルトと同じ
RAM
デフォルト: なし

  • VMのメモリ容量
2048 MB
(※) デフォルトと同じ
vCPUs
デフォルト: 1

  • VMのCPUコア数
4
Qemu binary
デフォルト: 環境依存

  • VM起動用のQEMUコマンドを指定する
/usr/bin/qemu-kvm
(※) デフォルトと同じ
Boot priority
デフォルト: HDD

HDD
(※) デフォルトと同じ
On close
デフォルト: Power off the VM

  • GNS3上でVMを "Stop" したときの動作
  • Power offが最も確実で早い
  • shutdownは、OSハング時は使えない
Power off the VM
(※) デフォルトと同じ
Console type
デフォルト: なし

  • VMへのコンソールアクセス方法
  • telnet: シリアルコンソール
  • vnc: グラフィカルコンソール
  • spice: グラフィカルコンソール
  • spice+agent: グラフィカルコンソール
  • none: 表の下に記載 (※1)
telnet
Auto start console
デフォルト: OFF

  • ON: VM起動時にコンソールを開く
  • OFF: コンソールを自動起動しない
OFF
(※) デフォルトと同じ

(※1) Console typeでnoneを指定すると、QEMUコマンドラインオプションに-serial, -vnc, -spiceなどのオプションを指定しない。Auto start consoleの設定に関わらず、VM起動と同時にQEMUの内蔵コンソールが起動する。内蔵コンソールは、グラフィカルコンソールとシリアルコンソールを切り替える機能を持つ。ウィンドウを閉じるとVMを停止する

HDD

HDDタブでは、HDA (Primary Master)のDisk interfaceをvirtioに変更します。

デフォルトのnoneが選択されている場合、VM起動時に自動的にideに変更されます。
このハードウェアの値がideでもvirtioでもVMは問題なく起動しますが、virtioの方が性能が出やすいようなのでここで変更しています4

edit_qemu_vm3

CD/DVD

特に何も変更せず、空欄のままです。

今回は既にLinuxをインストール済みのため、CD/DVD (ISOファイル) をセットする必要はありません。

edit_qemu_vm4

Network

Networkタブは下図のように設定しました。
変更した箇所を枠線で強調してあります。

edit_qemu_vm5

設定値を下表にまとめます。

設定項目、デフォルト値、意味 今回の設定値
Adapters
デフォルト: 1

  • NIC
  • 後から変更できるのでお好みで
3
First port name
デフォルト: なし

なし
(※) デフォルトと同じ
Name format
デフォルト: Ethernet{0}

  • NIC番号の命名を変更する
  • First port nameが未設定の場合、
    1番目以降のNIC番号を設定する
  • First port nameが設定済の場合、
    2番目以降のNIC番号を設定する
  • {}で囲うことで変数を使える
  • {port0}: 0から始まる連番
  • {port3}: 3から始まる連番
  • Eth{segment0}/{port0}: (※2)
  • 参考: GNS3 - Port name formatting
ens{port3}
(※3)
Segment size
デフォルト: 0

  • Name formatに影響するパラメータ (※2)
  • 0は、1と同じ意味になる
0
(※) デフォルトと同じ
Base MAC
デフォルト: __:__:__:__:__:__

  • 1つ目のNICMACアドレスを指定する
  • 2つ目以降は、Base MACの値に1を足して生成
  • __:__:__:__:__:__: Base MACを自動生成する
  • 11:11:11:11:11:11: 左記のBase MACを利用
__:__:__:__:__:__
(※) デフォルトと同じ
Type
デフォルト: Intel Gigabit Ethernet (e1000)

Paravirtualized
Network I/O
(virtio-net-pci)
Custom adapters
デフォルト: 設定なし

  • NICに対して番号とドライバを個別指定する
設定なし
(※) デフォルトと同じ
Replicate network connection states in Qemu
デフォルト: ON

  • 正確な意味は不明だが、検証により以下を観測した
  • ON: GNS3の配線によって実機上でlink up/downする
  • OFF: 実機上で常にlink upする
ON
(※) デフォルトと同じ
Use the legacy networking mode
デフォルト: OFF

  • QEMU 2.9.0未満でのみ使用可能なモード
  • 現在のQEMUは6.1.0以上
  • このオプションを使うことはない
OFF
(※) デフォルトと同じ

(※1) ネットワーク機器の仮想アプライアンスの場合、1番目のNICがしばしば管理インターフェースとして扱われる。そして2番目のNICからサービスポートとなる。その場合、First port nameをmgmt0、Name formatをEth1/{port1}と設定すると、先頭ポートから順にmgmt0, Eth1/1, Eth1/2, ...という番号付けができる。このようにポート番号付けの規則をチューニングすることで、GNS3上の表示と実機のshow interface出力の間で整合性を取ることができる

(※2) {segment0}は、Segment sizeと共に使う。Segment sizeが3だった場合、Eth{segment0}/{port0}Eth0/0, Eth0/1, Eth0/2, Eth1/0, Eth1/2, ...のように3ポート周期でセグメント番号が変わる。{segment1}と指定することで、1から始まる連番を指定することも可能。ネットワーク機器の仮想アプライアンスに対して有効

(※3) GNS3上でLinux VMQEMUで動作させた場合、Linux実機上でポート番号がens3, ens4, ...アサインされた。したがって、Name formatens{port3}に設定した

Advanced

Advancedタブについては、よく使うオプションにのみ言及しています。

特にCentOS Stream 9を使う場合は、Aditional settings > Optionsに追加設定が必要であるため、忘れないようにしてください。

Use as a linked base VMオプションについても念のため補足します。
このオプションが有効の場合、GNS3のトポロジにVMを追加する前に内部的にVMクローンするようになります。
つまり、このオプションが有効である限りはテンプレートVMを書き換える心配がありません。
テンプレートVMを書き換えたい場合には一時的にOFFにします。

edit_qemu_vm6

設定項目、デフォルト値、意味 今回の設定値

Aditional settings > Options
デフォルト: なし
  • 原則、なし
  • CentOS Stream 9のみ
    -cpu host (※1)

Aditional settings > Use as a linked base VM
デフォルト: ON
  • ON: 仮想ディスクをコピーしてVM起動する
  • OFF: オリジナルのディスクでVM起動する
ON
(※) デフォルトと同じ

(※1) CentOS Stream 9をQEMUで起動する時、-cpu hostオプションを指定しないとKernel Panicになるという事象が報告されています5。私の環境においても2022/3/28リリース版のCentOS Stream 9のISOファイルにて再現しました。virt-installやCockpitなど、libvirtを介する環境で作成したVMはオプションが正しく設定されているためか再現しませんでした。GNS3はlibvirtを介さずQEMUコマンドを直接実行してVMを起動するため、CentOS Stream 9 VMを起動する場合は-cpu hostを指定するワークアラウンドが必要です。-cpu host自体はQEMUの推奨オプションであり、CentOS Stream 9以外のホストに対して同様に指定しても特に悪影響はありません

Usage

Usageタブにはコメントを自由に書けます。
お好みで、VMの説明を簡単にメモすると便利です。

空欄のままでも問題ありません。

edit_qemu_vm7

共通設定

Generalセクションで特定のVMに閉じない一般的な設定ができます。
今回作成したLinux VMに関連する設定もあるので、ここで触れておきます。

Console applications

#General settingsConsole typetelnetに設定している場合、電源起動済みのVMをダブルクリックすることでシリアルコンソール接続できます。
以下の画面で、シリアルコンソール接続に使用するアプリケーションを指定します。

console_applications1

console_applications2

デフォルトはXtermになっていますが、環境によってはXtermが入っていないこともあると思います。
Xtermから変更する場合、お使いのターミナルソフトウェアに合わせてGnome TerminalKonsoleなど選択してください。

シリアルコンソール起動時のコマンドは自分自身で指定することも可能です。
私はTilixを使っているため、以下のように設定しました。

tilix -t "%d" -a session-add-down --focus-window -e "telnet %h %p"

%dはコンソール画面のタイトル、%hはコンソール接続先のIPアドレス%pはコンソール接続先のポート番号です (※)
組み込み変数の意味について、詳細は上記スクリーンショットを参照してください。
(※) GNS3のシリアルコンソール接続は、内部的にtelnet通信を使用します

VNC

#General settingsConsole typeVNCに設定している場合、VNCプロトコルによるコンソール接続になります。
以下の画面で、VNCコンソール接続に使用するアプリケーションを指定します。

vnc1

デフォルトはTightVNC (vncviewer) が選択されています。
私の環境ではRemote Viewer (remote-viewer)がインストール済みなので、それを選択しました。
Remote Viewerは、sudo dnf install remote-viewerでインストールできます。

Spice

#General settingsConsole typeSpiceに設定している場合、Spiceプロトコルによるコンソール接続になります。
以下の画面で、Spiceコンソール接続に使用するアプリケーションを指定します。

spice1

デフォルトはRemote Viewer (remote-viewer) が選択されています。
私の環境としてはこのままで問題ないので、特に変更しませんでした。

Linuxの起動

いよいよ、GNS3上でLinuxを起動します。

まず、作成したCentOS Stream 8をGNS3上に追加します。

add_vm

GNS3トポロジ上のVMを右クリックし、Startを選択することでVMを起動します。

start_vm

VMをダブルクリックするか、右クリックしてConsoleを選択することでコンソールを起動します。
ログインプロンプトが確認できれば、無事成功です。

connect_to_console

後はケーブル配線して好きなトポロジを組んでみましょう。
作成したVMSSHログインする方法は別の記事で紹介します。

(参考) GNS3で起動したVMKVMを使っているか?

GNS3で起動したVMは、KVMを使うようになっています。

GNS3からQEMUVMを起動した後にps -ef | grep qemuコマンドを実行すると、-enable-kvmを指定していることがわかります。

また、VM起動前後でlsmod | grep kvmを実行して値を比較することでもKVMの利用を確認できます。
VM起動後は、intel_kvm行、またはkvm_amd行の右端にあるカウントが増加しています。
これは、VMKVMカーネルモジュールを利用していることを表しています。
以下のコマンドでは、VM起動前では0だったものが、VM起動後では6に増加しています。
参考: KVMの初期設定、及びvirsh, virt-installによるVM作成 - #KVMの動作確認 (2/2)

################
# VM起動前
################
lsmod | grep kvm
# kvm_intel             360448  0
# kvm                  1028096  1 kvm_intel
# irqbypass              16384  1 kvm


################
# VM起動後
################
lsmod | grep kvm
# kvm_intel             360448  6
# kvm                  1028096  1 kvm_intel
# irqbypass              16384  5 kvm

まとめ

GNS3にLinux VMを追加し、コンソール接続する手順を紹介しました。

手順に書き起こすと長いですが、要点にまとめると3ステップなシンプルな手順です。

  1. Linux VMをインストール済みのqcow2ファイルを用意する
  2. qcow2ファイルをGNS3に登録する
  3. GNS3上で起動する

一度登録すれば、Use as a linked base VM機能によって同じVMを何台でも作り放題になります。
GNS3によるネットワーク検証に役に立ちますので、ぜひお試しください。

FedoraへのGNS3インストール

gns3_topology

前の記事

お伝えしたいこと

FedoraにGNS3クライアントとGNS3サーバをインストールする手順をお伝えします。
ここでご紹介する手順は、以下サイトの内容を元にしています。

Computing for Geeks - How To Install GNS3 on Fedora 35/34/33/32/31

ただし、本ブログの手順は一部アレンジを加えています。
具体的には、以下の通りです。

  • VPCSの最新版をインストールする手順に変更
  • 最小限のパッケージのみをインストールする手順に変更

本ブログでご紹介した手順は、Fedora35、GNS3 2.2.29にて動作確認済みです。

GNS3のインストール

GNS3サーバとGNS3クライアントは導入必須です。
以下のコマンドでインストールします。

sudo dnf install gns3-gui gns3-server

RPMパッケージ版はGNS3公式サイトで直接配布されているものよりも多少バージョンは古いですが、全く問題なく動作します。

外部ツールのインストール

GNS3のインストールに必要なのは、GNS3本体のみです。

しかし、GNS3本体は各種機能を提供するために、様々な外部ツールと連携します。
それらの外部ツールを使う場合には、追加のインストールが必要になります。

全てのツールを一旦入れるか、必要なツールに絞って入れるかはユーザーの好み次第です。
今回、私はWireshark、VPCS、Dynamipsのみ導入することにしました。
仮想マシンを動作させるため、KVMも別途インストールしました。

IOU、Dockerについては、今回はインストールしませんでした。
これらのツールについては、ツールの概要とインストールしなかった理由を中心に紹介します。

Wireshark

(参考) Wiresharkとは

Wiresharkとは、パケットキャプチャの実施と、結果のGUI表示機能を持つアプリケーションです。
GNS3においては、ケーブルを右クリックして該当箇所のパケットキャプチャを取得/確認するためにWiresharkを使います。

一般に、物理的なネットワーク環境では以下の手順でパケットキャプチャを行います。

GNS3においてはそのような面倒な操作は一切不要です。
ケーブルを右クリックしてキャプチャを開始するのみです。

WiresharkとGNS3の組み合わせは非常に便利です。
Wiresharkはぜひインストールしましょう。

Wiresharkのインストール

以下のコマンドでインストールします。

sudo dnf install wireshark

VPCS

(参考) VPCSとは

VPCS (Virtual PC Simulator) は、仮想パソコンのことです。

ネットワークの検証をする際、ネットワーク機器に端末を接続してpingなどの疎通確認を行いたい場面はあると思います。
そんなときに、Linuxの代わりに使えるのがVPCSです。

VPCSは以下の特徴を持ちます。

WEB通信を試したい場合、サーバー役はLinuxを用意しても良いと思いますが、クライアント役をVPCSに任せることでメモリ容量を節約できます。
起動/停止も高速で、あると何かと便利です。
VPCSは、ぜひインストールしましょう。

VPCSは独特のCLIを持ちますが、ネットワーク機器のように?でヘルプを確認しながら使っていればすぐに使い方を理解できるでしょう。

VPCS依存パッケージのインストール

VPCSをインストールするために、gccとmakeをインストールしておきます。

sudo dnf install gcc make

VPCSのインストール

VPCSの公式版はSource Forgeにて配布されていますが、現在はメンテナンスされていないようです。
GNS3 ProjectがVPCSの開発を引き継いでメンテナンスしたものがGitHub上に存在するので、そちらをダウンロードします。
GitHub - GNS3/vpcs - Releases

2022年3月時点の最新版は0.8.2であるため、そちらをダウンロードします。
ブラウザ上でダウンロードリンクのURLを右クリック・コピーし、curlコマンドでtar.gzファイルをダウンロードします。
(※) git clone https://github.com/GNS3/vpcsでダウンロードしても良いですが、厳密にはmasterブランチとv0.8.2タグを持つリリース版には差がある可能性があるのでご注意ください

curl -LO https://github.com/GNS3/vpcs/archive/refs/tags/v0.8.2.tar.gz

tar.gzファイルを展開し、シェルスクリプトを実行することでC言語ソースコードをビルドします。
ビルドの結果、vpcsの実行ファイルが生成します。
このシェルスクリプトが行うのは、基本的にmakegccによるビルドのみです。
カレントディレクトリに*.oファイルとvpcsファイルを生成しますが、他には何もしません。

tar xzf v0.8.2.tar.gz
cd vpcs-0.8.2/src
./mk.sh

生成したvpcs実行ファイルを適切なパスに格納します。
今回は/usr/local/binに格納します(※)
(※) RPMインストールされたときの実行ファイルは、/usr/bin/配下に格納されます。make installpip installなど、他の手段でインストールされた場合は私の知る限り/usr/local/binに格納されます

また、vpcsのmanファイルも用意されているのでこちらも適切なパスに格納します。

sudo cp -i vpcs /usr/local/bin
sudo cp -i ../man/vpcs.1 /usr/local/share/man/man1/

動作確認します。

vpcs -v
# バージョンが表示されること

man vpcs
# manが表示されること

インストールが完了した後は、不要なファイルは削除して問題ありません。

cd ../..
rm -rf vpcs-0.8.2/ v0.8.2.tar.gz

(参考) VPCSのアンインストール

VPCSのインストール時に行った変更は、実行ファイルとmanファイルの配置のみです。
これらのファイルを削除すれば、VPCSをアンインストールしたことになります。

sudo rm /usr/local/share/man/man1/vpcs.1 /usr/local/bin/vpcs

Dynamips

(参考) Dynamipsとは

Dynamipsは、GNS3においては以下の機能を持ちます。

  • Cisco IOSエミュレーター
    • Cisco IOSイメージファイルを持っていれば、仮想Ciscoルータを再現できる
    • イメージファイルの入手が一番のハードル
  • ソフトウェアベースのハブ、L2スイッチが使える

今回は、後者の機能を目的としてDynamipsを導入します。

DynamipsがサポートするL2スイッチはメモリ消費が少なく、気軽に追加できる点が一番の長所です。
また、VLANやDot1Q Trunkingにも対応します。

Dynamipsのインストール

基本的な流れはVPCSの時と同じです。
まず、依存パッケージをインストールします。

sudo dnf install make gcc
sudo dnf install cmake elfutils-libelf-devel libpcap-devel

続いて、以下のコマンドを実行してインストールします。
curlコマンドに指定しているURLは、GitHub上のGNS3/DynamipsのReleaseページ上の "Source code (tar.gz)" のリンクからコピーしたものです。

curl -LO https://github.com/GNS3/dynamips/archive/refs/tags/v0.2.21.tar.gz
tar xzf v0.2.21.tar.gz
cd dynamips-0.2.21/
mkdir build
cd build
cmake ..
sudo make install

任意ですが、ここでinstall_manifest.txtをどこかのディレクトリにバックアップしておきます。
このファイルはDynamipsをインストールした時に配置したファイルパスを記録したもので、Dynamipsをアンインストールする時に必要となります。

とはいえ、install_manifest.txtが手元にない場合ももう一度インストール手順を実行することで再び生成できます。
そのため、バックアップを取ることは必須ではありません。

install_manifest.txtの中身は以下のとおりです。

/usr/local/share/doc/dynamips/ChangeLog
/usr/local/share/doc/dynamips/COPYING
/usr/local/share/doc/dynamips/MAINTAINERS
/usr/local/share/doc/dynamips/README.md
/usr/local/share/doc/dynamips/README.hypervisor
/usr/local/share/doc/dynamips/RELEASE-NOTES
/usr/local/share/doc/dynamips/TODO
/usr/local/share/man/man1/dynamips.1
/usr/local/share/man/man1/nvram_export.1
/usr/local/share/man/man7/hypervisor_mode.7
/usr/local/bin/nvram_export
/usr/local/bin/dynamips

作業用のファイルやディレクトリを削除します。

cd ../..
rm -rf v0.2.21.tar.gz dynamips-0.2.21/

(参考) Dynamipsのアンインストール

Dynamipsのアンインストール手順は、途中まではインストール手順と同じです。

curl -LO https://github.com/GNS3/dynamips/archive/refs/tags/v0.2.21.tar.gz
tar xzf v0.2.21.tar.gz
cd dynamips-0.2.21/
mkdir build
cd build
cmake ..

このタイミングで、今いるbuild/ディレクトリにバックアップ済みのinstall_manifest.txtを配置しておきます。
このファイルがない場合、一旦sudo make installを実行し、install_manifest.txtを生成しましょう。

そして、以下のコマンドを実行することでアンインストールできます。

sudo make uninstall

アンインストール完了後、作業用のファイルやディレクトリを削除します。

cd ../..
rm -rf v0.2.21.tar.gz dynamips-0.2.21/

(参考) KVMのインストール

Linux仮想マシンを動かすために、QEMU/KVMVirtualBoxなどの仮想化エンジンを別途インストールする必要があります。

Linuxの場合は、オープンソースかつ軽快に動作するQEMU/KVMが良いのではないかと思います。
KVMは商用サービスにも利用されることがあり、品質の高さが伺えます。
また、CPUの仮想化支援機能や準仮想化ドライバなどを効率的に利用することから、VMが高速に動作します。

各種CLI/GUIツールも充実していて、操作性も良いです。

KVMのセットアップ手順は過去の記事で紹介していますので、よろしければ参考にしてください。

KVMの初期設定、及びvirsh, virt-installによるVM作成

快適なGUI操作を望む場合は、Cockpitをお試しください。
CockpitはRed Hat社が開発を支援しているオープンソースソフトウェアです。
Cockpit GUI によるKVM操作

一通りセットアップが終わったら、KVM仮想マシンを建ててみましょう。
基本操作の説明は以下の記事にまとまっています。
KVMの基本操作集

GNS3とKVMの連携方法については、別の記事にて紹介します。

(参考) その他のツール

本セクションで紹介するツールについては、今回はインストールを見送りました。
以下のセクションにて、各ツールをインストールしなかった理由について補足します。

これらのツールをインストールしたい場合は、以下の記事を参考にしてください。
Computing for Geeks - How To Install GNS3 on Fedora 35/34/33/32/31

Step 1にて依存パッケージをインストールの上、後は各ツールごとのインストール手順にしたがってご対応ください。

IOU

IOU (IOS on Unix) は、IOSv (Cisco IOSの仮想アプライアンス) とほぼ同等の機能性を持ちます。
IOL (IOS on Linux) とも呼ばれます。
噂によれば、Cisco IOSvよりもバグが少なく、パフォーマンスも良いと聞いたことがあります。

しかし、IOUはCisco社員、またはCisco社パートナーしか入手できないと言われています。
私達が手に入れることはかないませんので、IOUの動作環境を持っていても仕方ありません。

したがって、今回はIOU周りのセットアップも見送りました。

Docker

DockerのRPMパッケージ自体は、gns3-server RPMパッケージの依存関係として自動的にインストールされました。
しかし、私が現状VMしか使わず、コンテナを使っていないのでDockerのセットアップを見送りました。
ネットワーク検証を行うためには、Linuxやネットワーク仮想アプライアンスVMを建てられれば十分であるためです。

今後コンテナの軽量さを活かして何かする機会があれば、Dockerを使い始めることがあるかもしれません。

(参考) 他のOSへのGNS3インストール手順

GNS3が公式でインストールマニュアルを提供しているのは、WindowsMacUbuntuの3種です。
他にもArch LinuxやManjaroでもGNS3をインストールした実績があるそうです。

Fedora以外のOSに対するGNS3のインストール手順については、GNS3の概要 - GNS3のインストール方法も参考にしてください。

まとめ

FedoraにGNS3をインストールする手順を紹介しました。

GNS3本体はRPMパッケージで簡単にインストールできます。
GNS3と連携している外部ツールについては、個別にインストールする必要があります。

少々面倒かもしれませんが、手順さえわかってしまえば簡単です。
元の記事で情報提供してくださったJosphat Mutaiさんに感謝します。