免責事項
これは Cisco Systems Japan Advent Calendar 2025 の一環で参加しているブログになります。
本サイトおよび対応するコメントにおいて表明される意見は、投稿者本人の個人的意見であり、シスコの意見ではありません。本サイトの内容は、情報の提供のみを目的として掲載されており、シスコや他の関係者による推奨や表明を目的としたものではありません。各利用者は、本Webサイトへの掲載により、投稿、リンクその他の方法でアップロードした全ての情報の内容に対して全責任を負い、本Web サイトの利用に関するあらゆる責任からシスコを免責することに同意したものとします。
目的
ESXiのライセンススキームの変更により、ネットワークエンジニアにおいても、従来比較的簡単に入手できたESXiのライセンスが入手できなくなり困っている方も多いのではないでしょうか。
本記事では、そんなネットワークエンジニアに向けて、私が過去にProxmoxを利用してCiscoのソフトウェアアプライアンスの機能検証を行ってきた経験をまとめてみたいと思います。
すでにご存じの内容も多いかもしれませんが、何か一つでも参考になる点があれば幸いです。
前提条件
Ciscoが提供しているソフトウェアアプライアンスでは、必ずサポートするハイパーバイザーの情報が記載されています。残念ながら2025年12月現在、Proxmoxを公式にサポートしているCiscoのソフトウェアアプライアンスは存在していません。
しかし、ProxmoxはLinuxの標準的なハイパーバイザーエンジンであるKVMを利用しており、KVMをサポートしているソフトウェアアプライアンスであれば、動作する可能性は非常に高いです。また、各Linuxディストリビューションをはじめ、KVM上でソフトウェアを動作させる作り込みを行っているケースは数多くあり、Linuxディストリビューションベースで動作しているソフトウェアアプライアンスも、Proxmoxで動作する可能性が非常に高いといえます。
厳密な性能検証には使えないかもしれませんが、SEが小規模環境での機能検証やデモを行うには十分といえるのではないでしょうか。
Proxmox インストール
以下のサイトからProxmox Virtual Environmentの.isoファイルをダウンロードして、UCSをはじめ各種サーバ等にインストールしてください。バージョンは特にこだわりがなければ最新バージョンで問題ありません（apt updateすると自動的にバージョンアップされます）。
Proxmoxのインストール手順については数多くのブログ記事がありますが、例えば以下が参考になります。
Raspberry Pi Imager
.isoファイルをUSBに書き込む方法については、各種OSで様々な手法がありますが、最近個人的にオススメしているのはRaspberry Pi Imagerです。Windows/macOS/Linuxをサポートしており、表向きはRaspberry Piのイメージライターですが、カスタムイメージの機能で各種サードパーティーの.isoファイルをUSBにコピーすることができます。
メディアのeraseと書き込みの両方行える点もgood
従来macOSではbalenaEtcher を長らく利用してきましたが、管理者パスワード入力画面がOS標準のインターフェースではないため情報が抜き取られているような懸念が個人的に拭えなかったこと、macOS 26 Tahoe で発生しているElectronベースアプリケーションのGPU負荷上昇問題に2025年11月時点で対処していないことを考えると、ツールを変更するタイミングなのかもしれません。（参考：shamelectron）
Raspberry Pi Imagerの詳しい使い方については以下が参考になります。
Proxmox No-subscription レポジトリの登録
インストール直後はライセンスがないためリポジトリへのアクセスができませんが、Node -> Updates -> Repositoryから、No-subscriptionを追加し、pve-enterpriseとceph-squidを無効化することで、パッケージアップデートおよび各種パッケージ追加(apt)が可能になります。以下も参考になります。
ファイルシステムの選択
Proxmoxのインストール時に迷う点があるとすれば、ファイルシステムの選択です。
下記のWikiを調べていくと多くのファイルシステムがサポートされていることがわかります。私が過去に触っていた中での結論は以下になります。
- ハードウェアRAIDあり、シングルディスク: EXT4（内部でlvm-thinが自動的に構築される）
- 複数ディスクがあってソフトウェアRAIDを構成したい: ZFS
- 外部バックアップ環境が用意できる場合: NFS
EXT4(LVM-thin)とZFSを選択する理由は、スナップショットが取得でき、使った分のみファイルストレージ容量を消費する（シンプロビジョニング）点です。本番環境を前提にすると、シンプロビジョニングには賛否があると理解していますが、多くのSEの検証環境の場合はスペックに余裕があるとは限らないため、シンプロビジョニングを選択せざるを得ないと思います。
NFSのネットワークストレージがあると、バックアップ環境が構築しやすく、また何らかの理由でProxmoxを再度インストールしなければならない場合に、容易に復旧が可能になります。
NFSを利用する上での留意点として、NFSストレージにネットワーク的にアクセスできなくなると、Proxmoxは応答待ちの状態になり、何もできなくなります。Proxmox上のNFSを「無効化」かつ「Linux上でアンマウント」することで回避できますが、基本的にはNFSサーバを停止しない前提が望ましいです。（このあたりはRedditなどでかなり議論されていますが、回避策はないというのが私の認識です。Samba/CIFSなら回避できるかもしれません）
ネットワークの設定
設定したホスト名が/etc/hostsと一致している必要があります。インストール後にホスト名やドメイン名を変更した場合は必ず設定を変更しましょう。（そうしないと、Web GUI :8006 にたどり着けません）
$ cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
192.168.64.38 pve1.example.com pve1
SDN機能
ProxmoxにはSDN機能として内部でBGP/EVPN/VXLANなどをサポートしていますが、本記事の対象者はネットワークエンジニアであり、ネットワークエンジニアであればそれらはネットワーク製品側で実装したいでしょう。
そのため、ESXi時代と同様にVLANのみを使う形になると想定し、今回は省略します。
物理NIC
できることであれば管理用ネットワーク（flashnet等）とVMネットワークを分けた方がよいです。
デフォルトのインストール状態では、管理用ネットワークがLinux Bridgeで作成されているはずです。この状態でもVLANなどを考えなければ問題ありませんが、もう少しこだわりたいのであれば、後述のOpen vSwitchにしたいところなのですが、Linux設定の知識がないと、誤ったネットワーク設定を戻すのに苦労すると思われます。
Trunk Port
Catalyst 9800-CLクラウドワイヤレスコントローラやCatalyst 8000V EdgeでVLANトランクやサブインターフェースの設定を将来的に行う可能性がある場合、Open vSwitchにすると仮想マシンのインターフェースにVLAN Trunkの設定が可能になることを確認しています。
まず、Open vSwitchをインストールします。
apt install openvswitch-switch
Open vSwitchをインストール後、Open vSwitchによるBridgeを設定していきます。
設定のポイント
Create OVS Bridgeから作成します。
重要なパラメータ: IPv4 CIDR, Bridge Port
Bridge Portは要するにアップリンクのことです。
アップリンクのポートがTrunk Portになっており、かつNative VLANを変更している場合は、アップリンク側のVLAN Tagを当該VLANに変更します。
これだけでVLAN対応は完了です。
ただし、この設定でミスをするとProxmoxへのネットワーク接続ができなくなるので要注意です。管理用ネットワークには一切触らず、VMのトラフィックを別ポートから出すようにしておくと事故を防げます。
追加ネットワーク設定
以下のような手動設定を行うことで、以下が可能になります。
- dot1x透過（dot1xを仮想スイッチでバイパスさせて、上位のスイッチでdot1xを動作させる）
- BPDU透過（VMのCDP/LLDPが上位スイッチで確認できるようになる）
nanoやvimで設定した後、以下のコマンドで適用します。
sudo systemctl restart networking.service
以下が設定ファイルのサンプルです。
hshimomu@pve1:~$ cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!
auto lo
iface lo inet loopback
iface eno1 inet manual
#1GbE#1
auto eno3
iface eno3 inet manual
ovs_type OVSPort
ovs_bridge vmbr0
ovs_options vlan_mode=native-untagged tag=2064
pre-up ethtool -G <interface> tx 4096 rx 4096
#10GbE#1
iface eno4 inet manual
#10GbE#2
iface eno2 inet manual
#1GbE#1
auto vmbr0_2064
iface vmbr0_2064 inet static
address 192.168.64.38/24
gateway 192.168.64.1
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=2064
iface vmbr0_2064 inet6 static
address 2400:4050:ff24:404:1c11:8ff:fe83:b9d8/64
gateway 2400:4050:FF24:404::1
privext 0
auto vmbr0
iface vmbr0 inet manual
ovs_type OVSBridge
ovs_ports eno3 vmbr0_2064
#up ovs-ofctl add-flow vmbr0 "table=0, dl_dst=01:80:c2:00:00:03, actions=flood"
up ovs-vsctl set bridge vmbr0 other-config:forward-bpdu=true
source /etc/network/interfaces.d/*
2026/6/4 追記
Open vSwitch 公式 docs では、NORMAL action は reserved Ethernet multicast を通常 drop するが、Bridge の other_config:forward-bpdu=true がある場合は drop しない、と書かれています。EAPOL で利用される 01:80:c2:00:00:03 はこの reserved 系なので、 forward-bpdu=true + NORMAL で流れるのが仕様であり、up ovs-ofctl add-flow vmbr0 "table=0, dl_dst=01:80:c2:00:00:03, actions=flood"は不要です。
出典: ovs-actions.7, ovs-vswitchd.conf.db(5)
Proxy
ProxmoxをProxy環境で動作させる場合、ソフトウェアアップデートなどでProxy設定を行う必要があります。ProxmoxはDebianベースなので、Debian/UbuntuでのProxy設定が適用可能です。
以下はシステム全体でProxy設定を行う例です。
プロキシサーバ: proxy.esl.example.com
ポート番号:80
プロキシ除外ドメイン: example.com と 10.1.1.0/24
hshimomu@pve:~$ cat /etc/default/proxy.sh
export http_proxy=http://proxy.esl.example.com:80/
export https_proxy=http://proxy.esl.example.com:80/
export ftp_proxy=http://proxy.esl.example.com:80/
export no_proxy=".example.com,10.1.1.0/24"
export HTTP_PROXY=http://proxy.esl.example.com:80/
export HTTPS_PROXY=http://proxy.esl.example.com:80/
export FTP_PROXY=http://proxy.esl.example.com:80/
これでaptは動作しますが、gitやpipは別途設定が必要になります。
NTP
デフォルト状態では、pool.ntp.orgで時刻同期を行いますが、Proxy環境では個別にNTP設定が必要になります。nano等で以下の設定ファイルを変更して、任意のNTPサーバを指定します。
hshimomu@pve:~$ nano /etc/chrony/chrony.conf
# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usable directives.
# Use Debian vendor zone.
server [YOUR NTP SERVER 1]
server [YOUR NTP SERVER 2]
server [YOUR NTP SERVER 3]
Proxmoxへの仮想アプライアンスのインストール
ここからが本題です。Proxmoxへの各種Ciscoソフトウェアアプライアンスのインストール方法について、私なりのベストプラクティスをご紹介します。
全般的にCPUやメモリはESXi同様に設定すれば問題ありません。Cisco系の場合、BIOSはデフォルトのSeaBIOS/i440fxで問題が出たケースは今までありません。Windows 11やWindows Serverの場合は、q35/OVMF(UEFI)に自動的に設定されます。
Catalyst 9800-CL Cloud Wireless Controller
Cisco公式でハイパーバイザーとしてKVMがサポートされていますが、Proxmoxは公式サポートディストリビューションには含まれていません。公式にqcow2のイメージが公開されていますが、検証目的で数台インストールするのであれば、.isoによるインストールが手っ取り早いです。
Local Storage -> ISO Imageから、C9800-CLのISOファイルをアップロードします。
Create VMからVMを設定していきます。
先ほどアップロードした.isoを指定します
VMのマシン設定を行います。デフォルト状態で過去問題が起こったことはありません。
ディスクをアサインします。容量やストレージの場所(localやzfsなど)は各自に合わせてください。
CPUコアの割当を実施します。 デフォルトのx86-64-v2-AESでほとんどの場合は問題ありません。新しいハードを持っている場合は、v2-AESとv3などにしてもよいでしょう。
メモリの割当をします。1GB=1024メガバイトで、計算してください。例えば4GBの場合は4096、16GBの場合は16384です。
NICの設定です。vlan tagを指定したい場合はいれてください。後から変更もできます。
最終確認です
C9800は3つNICが必用なので追加します。
例えばこれはvlan 2064でNICを追加するイメージです。
最終的にはNICが3つ並びます。最後にserial portをいれておくと、proxmox からコンソールシリアルに接続することも可能になります。
無事にブートしました。
VMにシリアルポートを追加しておくと、Proxmoxからコンソールポートにアクセス出来ます。詳しくは下記を参照してください。
Trunk portの設定
Local Modeの検証でTrunk Portの設定が必要な場合、設定ファイルをCLIで書き換えることでTrunk設定が可能になります（Open vSwitchによるvmbrで動作確認済み）。
/etc/pve/qemu-server/以下に各仮想マシンの設定ファイルがあり、VM番号.confが該当の設定になります。今回の場合は、GigabitEthernet2 (net1)に、Native VLAN 2064、Trunkが2064, 2066を透過する設定を行っています。Trunk設定は残念ながらWeb GUIでは設定できませんが、設定が成功しているとWeb GUIから確認できます。
root@pve1:~# cat /etc/pve/qemu-server/102.conf
affinity: 16-19
boot: order=scsi0;ide2;net0
cores: 4
cpu: x86-64-v3
machine: q35
memory: 8192
meta: creation-qemu=9.0.0,ctime=1720173807
name: c9800cl
net0: virtio=BC:24:11:97:B7:2C,bridge=vmbr0,tag=2100
net1: virtio=BC:24:11:DD:59:12,bridge=vmbr0,tag=2064,trunks=2064;2066
net2: virtio=BC:24:11:7C:46:52,bridge=vmbr0,tag=3000
numa: 0
ostype: other
scsi0: zfs:vm-102-disk-0,discard=on,iothread=1,size=16G,ssd=1
scsihw: virtio-scsi-single
serial0: socket
smbios1: uuid=eae24d53-eeca-4fe0-8aff-f9330858cf18
sockets: 1
startup: order=1,up=30
vmgenid: 7d0aa64e-1b59-4188-8abf-3df24bc3b3d2
net1にtrunksが設定されていることが確認できます。
Catalyst 8000V Edge
Catalyst 9800と同様に、Cisco公式でハイパーバイザーとしてKVMがサポートされていますが、Proxmoxは公式サポートディストリビューションには含まれていません。公式にqcow2のイメージが公開されていますが、検証目的で数台インストールするのであれば、.isoによるインストールが手っ取り早いです。
Cisco Identity Services Engine（ISE）
Cisco公式でハイパーバイザーとしてKVMがサポートされていますが、Proxmoxは公式サポートディストリビューションには含まれていません。
Cisco公式ではインストールイメージとして.isoのみが提供されているので、.isoを使うのが無難です。
Cisco ISEのバージョンによっては、仮想マシンがKVMでない旨のエラーメッセージが表示されてインストールが進まないことがありますが、
VM -> Option -> SMBIOS setting (type1) -> ProductにKVMと記入することで回避できます。
Cisco SD-WAN
Cisco公式でハイパーバイザーとしてKVMがサポートされていますが、Proxmoxは公式サポートディストリビューションには含まれていません。
Cisco公式ではインストールイメージとしてqcow2が提供されています。通常通りVMを作成し、CPU、メモリ等を割り当てた後、一度ディスクを削除し、下記の要領でrawに変換した後、VMにインポートするとスムーズです。
qemu-img convert -O raw FILENAME.qcow2 FILENAME.raw
sudo qm importdisk [VMID] FILENAME.raw [ストレージ名 例:local]
vManage (SD-WAN Manager) は起動ディスクとは別に、データ用の空ディスクを用意する必要があるので、忘れずに設定してください。
Cisco Modeling Labs (CML)
Cisco公式でハイパーバイザーとしてKVMがサポートされていますが、Proxmoxは公式サポートディストリビューションには含まれていません。
Cisco公式ではインストールイメージとして.isoのみが提供されているので、.isoを使うのが無難です。
過去に何名かの方がチャレンジしており、以下の情報を参照してください。
Cisco Spaces Connector
Cisco公式ではハイパーバイザーとしてKVMがサポートされていません。
CiscoではOVAイメージが提供されているので、qemu-img convertで変換し、qm diskimportします。
それで過去動いていたのですが、今回のblog用に再度動作確認をしていたところ、いくつか落とし穴があったので、記載します。
まずOSインストール無しでVMを作成し、作成されたディスクと detachして、removeします。
使用する Cisco Spaces connector のディスクイメージですが、最新の2025年7月版ではqemuにインポートした時点で25GBとなり、sudo qm resize 100 scsi0 120G で拡張しても限られた時間で試している限りブートに至りませんでした。
より今回は1つ前の2025年1月版のディスクイメージを使用してインストールします。（インストール後バージョンアップが可能）
例: cisco-spaces-connector3-p84-jan2025.ova
hshimomu@pve1:~/test/jan$ qemu-img convert -O raw cisco-spaces-connector-disk1.vmdk cisco-spaces-connector-disk1.raw
hshimomu@pve1:~/test/jan$ sudo qm importdisk 100 cisco-spaces-connector-disk1.raw zfs
importing disk 'cisco-spaces-connector-disk1.raw' to VM 100 ...
transferred 0.0 B of 117.2 GiB (0.00%)
transferred 1.2 GiB of 117.2 GiB (1.01%)
~中略~
transferred 116.8 GiB of 117.2 GiB (99.68%)
transferred 117.2 GiB of 117.2 GiB (100.00%)
transferred 117.2 GiB of 117.2 GiB (100.00%)
unused0: successfully imported disk 'zfs:vm-100-disk-0'
インポートされたディスクをeditからアタッチしてきます
scsci0として設定します
ディスクインポートしたときはboot order の調整が必要です
VM type を OVNFにします
セキュアブートの関係でEFIを追加します。この時key enrollのチェックボックスを外してください。
最終形です。もとのovaファイルをみているとNICのしてはE1000だったので合わせました。
ブートできました
Cisco Catalyst Center（仮想版）
Cisco公式ではハイパーバイザーとしてKVMがサポートされていません。また、最近のバージョンではサポート外のハイパーバイザーでは動作しない旨がWeb GUIに表示されますが、動作は可能です。
CiscoではOVAイメージが提供されているので、qemu-img convertで変換し、qm importします。ただし、ESXiのPCI-Eの番号と、KVM系のPCI-Eの番号体系が一致していないため、ESXiを前提に作られた初期設定インストーラがそのままでは動作しないため、イメージの書き換えが必要です。詳細は以下のブログを参照してください。
Windows Server
virtioと呼ばれるKVM仮想マシンに最適化したパフォーマンスを出すためのドライバを追加しないと、インストール時にディスクが見えません。以下などを参考にしてください。
まとめ
本記事では、ESXiのライセンス変更により仮想化基盤の選択肢として注目されるProxmoxについて、ネットワークエンジニア向けにインストール方法やCiscoソフトウェアアプライアンスの動作検証ノウハウをまとめました。
ProxmoxはKVMベースであり、公式サポート外でも多くのCisco仮想アプライアンスが動作します。ファイルシステムやネットワーク設計、Proxy・NTP設定など、実運用に役立つポイントも解説しました。特にVLANやTrunk、仮想ディスクのインポートなど、ESXiからの移行時に悩みやすい部分も具体的に記載しています。
今後も仮想化基盤の選択肢は多様化していくと思いますが、Proxmoxはコスト面・柔軟性・コミュニティの活発さから、検証・小規模運用に非常に有用です。この記事が、ネットワークエンジニアの皆様の検証・導入の一助となれば幸いです。