アップリンクの設定変更をコマンドで行う場合のコマンド集

Nutanix＋AHV環境において、AOS5.19以降は、Prismの画面からアップリンクNICの各種設定変更ができるようになりました。

しかし、例えばLACPに設定変更後うまくネゴシエーションができなくなったなど、様々なトラブルシューティングの際には、状態確認を含めコマンドで確認する必要が出てきます。

今回は、アップリンクまわりの設定をコマンドから行う場合の設定例をまとめてご紹介いたします。

まず、manage_ovsコマンドは、CVMから実行します。ネットワークに性上に接続が出来ない状態の場合は、サーバーホストのコンソールを開き、そこから「ssh nutanix@192.168.5.2」で、CVMにログインし、作業を行います。

仮想スイッチとアップリンクNICの設定状況

> manage_ovs show_uplinks

結果

Bridge: br0
  Bond: br0-up
    bond_mode: active-backup
    interfaces: eth3 eth2
    lacp: off
    lacp-fallback: false
    lacp_speed: slow
    lacp_status: off

Bridge: br1
  Bond: br1-up
    bond_mode: balance-tcp
    interfaces: eth1 eth0
    lacp: active
    lacp-fallback: True
    lacp_speed: fast
    lacp_status: configured

この環境では、2つの仮想スイッチがあり、active-backupのチーミングモードと、balance-tcp(LACP)のチーミングモードでそれぞれ設定されています。

各アップリンクNICの状況（リンクアップ・ダウンや速度）

> manage_ovs show_interfaces

結果

name  mode  link speed
eth0  1000 False  None
eth1  1000 False  None
eth2 10000  True 10000
eth3 10000  True 10000

ここでは、10GNICと1GNICで構成されており、10G NICだけが、10Gでリンクアップしていることがわかります。10Gポートが仮に1Gでリンクアップしている場合は、speedが、1000で表示されます。

仮想スイッチの作成

manage_ovs --bridge_name br1 create_single_bridge

ここでは、br1で指定していますが、実際には仮想スイッチの追加番号を入力します。

仮想スイッチの削除

manage_ovs --bridge_name br1  delete_single_bridge

アップリンクNICをactive-backupで構成する

manage_ovs --bridge_name br1 --interfaces eth0,eth1 --bond_mode active-backup  update_uplinks

アップリンクNICを変更する場合や、チーミングモードを変更する場合もこちらのコマンドを利用します。

アップリンクNICをLACPで構成する

manage_ovs --bridge_name br1 --interfaces eth0,eth1 --bond_mode balance-tcp --lacp_mode fast --lacp_fallback true update_uplinks

あわせて、AHVのホスト側から確認する方法もご紹介します。

アップリンクの設定確認

ovs-appctl bond/show br0-up 

LACPの確認（balance-tcpで設定された仮想スイッチのみ指定可能）

ovs-appctl lacp/show br0-up 

特にLACPで構成して、疎通ができない場合は、CVMで「manage_ovs show_uplinks」を実行し、「lacp_status」が「negotiated」になっているかを確認しましょう。

> manage_ovs show_uplinks
Bridge: br0
  Bond: br0-up
    bond_mode: balance-tcp
    interfaces: eth1 eth0
    lacp: active
    lacp-fallback: True
    lacp_speed: fast
    lacp_status: negotiated ★

LACP構成時は、Nutanix側で、fallbackを有効化しているので、スイッチ側がLACPモードになっていない場合、AHV側が標準ポートとして動作します。

あわせて以下も確認しましょう。

Bridges with single uplink on AHV hosts
https://portal.nutanix.com/kb/8015

How to Enable, Disable, and Verify LACP on AHV hosts
https://portal.nutanix.com/kb/3263

AHV host networking
https://portal.nutanix.com/kb/2090

AHVでアップリンクNICにLACPを利用する場合

AHV環境でアップリンクNICにLACPを利用したチーミングを行うケースがあります。

AHVは、もちろんLACPに対応しています。今回は、以前にも紹介しましたが改めてLACPを含めアップリンクのチーミング方法とLACPの設定方法についてお伝えします。

AHVのチーミング方法

AHVは、3つのアップリンクにおけるチーミング方法をサポートしています。

チーミングモード	使用事例
active-backup	デフォルト構成では、単一のアクティブなアダプターを介してすべてのトラフィックが送信されます。
balance-slb	マルチキャストトラフィックに関する注意事項があります。ホスト帯域幅の使用率が単一の 10 GbE アダプターを超えて増加します。各 VM NIC を一度に 1 つのアダプターに配置します。
LACP and balance-tcp	LACPとリンクアグリゲーションが必要です。アダプター間で VM NIC の TCP および UDP セッションのバランスをとることにより、ホストと VM の帯域幅使用率が単一の 10 GbE アダプターを超えて増加します。物理ネットワーク スイッチでLACP ネゴシエーションを必要とします。

AHVのデフォルトは、「active-backup」構成であり、こちらがメーカー推奨の構成となります。複数NICでアップリンクを構成した場合、アクティブとして利用するNICがⅠ本になるため、4本アップリンク構成などの場合はNICが無駄になってしまいますので、Nutanixの構成の推奨としては、2本のNICでチーミング構成を作成し、「active-backup」構成を利用することです。こちらの構成が推奨な理由は、Nutanixは、10Gのネットワーク帯域をフルで利用しない仕組みであることと、LAGにおけるスイッチとの相性およびスイッチの設定ミスによる通信不能状態を引き起こすことをなくすというメリットがあるためです。
当然ながらActive-Backup構成であれば、接続するスイッチ側は、LAGなど設定の必要なく、通常のAccessもしくはTrunkポートで設定すればOKです。

▼Acrive-Backupのアップリンク利用イメージ

balance-slbは、複数のアップリンクNICに対して、仮想マシン毎に特定の物理NICを利用するという構成です。こちらもスイッチ側には、LAGなどのポートを束ねる設定は必要ありません。仮想マシンに搭載された仮想NIC毎に利用する物理NICが割り当てられるため、仮想マシントラフィックによっては、物理NICのトラフィック量が不均等になる可能性はあります。

▼balance-slbのアップリンク利用イメージ

最後にLACP and balance-tcpですが、こちらはLACPを利用した構成です。スイッチ側でLAGの設定をする際のバランシングモードは「balance-tcp」を設定する必要があります。
物理NICが分散されて利用するため、負荷分散ができかつチーミングされた物理NICの性能を最大限利用することができます。

▼LACPを利用した場合のアップリンク利用イメージ

ここまで、アップリンクモードについて確認してみました。
重要なことは、LAG構成は、LACPのみサポートされており、静的LAGは非サポートであることに注意してください。

＜LACPの設定方法＞

では、LACPを利用する場合について考えてみましょう。

現在、Nutanixでは、Prism上でアップリンクNICのチーミングモードを変更することができ、Prismでのオペレーションが強く推奨されています。GUIで簡単に変更できることは大変便利です。しかし、Prismを利用して設定を変更するということは、Nutanixクラスターサービスが起動していることが前提です。
ノード追加を行う場合も、追加ノードのチーミングモードを設定できる項目がExpand Clusterの画面に追加されています。

▼Expand Cluster時に拡張ノードに対してチーミングの個別設定が可能

Nutanixの初期設定は、Active-Backupですのでこの状態でクラスターを起動させるために、Nutanixに接続される物理スイッチは、LACPモードではなく、通常のポートで設定する必要があります。一方、Prismからチーミングモードを変更すると1ノードずつチーミングモードがLACPに変更されます。（従来はここでノードの再起動が発生していましたが、AOS6.7においては、再起動は、発生しなくなっています）

しかし、1ノードのチーミングモードがLACPに変わると物理スイッチ側は、まだ通常のポートモードであることから、チーミングモードが変更されたノードは、疎通ができなくなってしまいます。

これを防ぐために、スイッチ側は、LACPの設定を行いつつもfallbackモードを有効化しておくことが必要となります。このfallbackモードは、物理スイッチでLACPを設定されたポートで、LACPのネゴシエーションができなかった場合、標準ポートとしてネゴシエーションするという機能です。この機能を利用することで、予め物理スイッチはLACPに設定しつつも、Nutanix側は、Active-Backupで起動時は、fallback機能が働き、通常ポートとして稼動し、PrismからLACPモードに変更すると、Nutanix側でLACPが有効化されるため、物理スイッチもLACPモードが有効化されるため、疎通が出来なくなるという事故をなくすことができます。

しかし、物理スイッチのメーカーにおいては、fallbackモードが実装されていない場合があります。この場合は、予めNutanixクラスターにLACPモードを有効化した上で、物理スイッチもLACPモードにしておけば、問題なくネゴシエーションができるかと思います。では、NutanixのノードをクラスタースタートせずにLACPモードにする方法としては、CVMから以下のコマンドを入力することでチーミングモードを変更します。

この手順は、クラスターメンバーに入る前のノードでもサ行が可能です。既にクラスターメンバーには行っているノードにおいて設定変更する場合は、クラスターサービスを「cluster stop」コマンドをCVMで実行し、予めクラスターサービスを停止しておきます。

まず、ノードの物理NICを確認します。

nutanix@NTNX-23SM6C-CVM:10.38.51.173:~$ manage_ovs show_uplinks
Bridge: br0
  Bond: br0-up
    bond_mode: active-backup
    interfaces: eth5 eth4 eth3 eth2 eth1 eth0
    lacp: off
    lacp-fallback: false
    lacp_speed: slow
    lacp_status: off

ここでは、eth0からeth5全てが1つの仮想スイッチのアップリンクNICとして構成されており、現行はLACPモードではないことがわかります。

では、LACPモードを有効化します。

nutanix@NTNX-23SM6C-CVM:10.38.51.173:~$ manage_ovs --bridge_name br0 --interfaces eth0,eth1,eth2,eth3,eth4,eth5  --bond_mode balance-tcp --lacp_mode fast --lacp_fallback true  update_uplinks
2023-12-16 05:09:49,505Z WARNING manage_ovs:1361 Failed to fetch gflags. Acropolis service might be down: HTTPConnectionPool(host='127.0.0.1', port=2030): Max retries exceeded with url: /h/gflags?show=hypervisor_username (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f5e411bc350>: Failed to establish a new connection: [Errno 111] Connection refused',)).
2023-12-16 05:10:02,734Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:02,856Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:03,265Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:03,267Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:03,280Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:03,661Z INFO cpdb.py:141 Failed to send RPC request. Retrying.
2023-12-16 05:10:13,008Z INFO manage_ovs:700 Node: 10.38.51.173 failed to connect to IDF while validating virtual switch configuration. Continuing further may result in inconsistency with the existing virtual switch configuration and require manual remediation once IDF is available.
Do you want to proceed? (Y/[N]):

クラスターサービスが上がっていないので色々コンソールに出力されますが、気にせず、Y/Nの質問が来るまで待った上で、Yを入力設定を完了します。

設定が完了したら、再度アップリンクのステータスを確認します。

nutanix@NTNX-17SM6C100126-C-CVM:10.38.51.173:~$ manage_ovs show_uplinks
2023-12-16 05:19:26,915Z WARNING manage_ovs:1361 Failed to fetch gflags. Acropolis service might be down: HTTPConnectionPool(host='127.0.0.1', port=2030): Max retries exceeded with url: /h/gflags?show=hypervisor_username (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f687cc8b350>: Failed to establish a new connection: [Errno 111] Connection refused',)).
Bridge: br0
  Bond: br0-up
    bond_mode: balance-tcp
    interfaces: eth5 eth4 eth3 eth2 eth1 eth0
    lacp: active
    lacp-fallback: true
    lacp_speed: fast
    lacp_status: configured ★

ここで確認すべき情報は、「lacp_status」です。

こちらの例では、LACP設定は完了していますが、スイッチとLACPでネゴシエーションで来てない状態になります。この項目が「negotiated」であれば、スイッチとのLACPネゴシエーションが確立されています。

なお、AOS6.7「el8.nutanix.20230302.207」のAHVバージョンにおいては、従来AHVがら設定をしていた「ovs-vsctl」や「ovs-appctl」コマンドが利用できなくなっているようです。

AHV上で、ovsコマンドの一覧を確認した際の結果

[nutanix@NX-AHV3 bin]$ ls -alg | grep ovs
-??????????  ? ?            ?            ? ovs-appctl
-rwxr-xr-x.  1 root    234440 May  1  2023 ovsdb-client
-rwxr-xr-x.  1 root    185560 May  1  2023 ovsdb-tool
-rwxr-xr-x.  1 root      8064 Feb 24  2023 ovs-docker
-rwxr-xr-x.  1 root     47168 May  1  2023 ovs-dpctl
-rwxr-xr-x.  1 root     61740 May  1  2023 ovs-dpctl-top
-rwxr-xr-x.  1 root    453544 May  1  2023 ovs-ofctl
-rwxr-xr-x.  1 root      2862 May  1  2023 ovs-parse-backtrace
-rwxr-xr-x.  1 root      3418 May  1  2023 ovs-pcap
-rwxr-xr-x.  1 root     15121 May  1  2023 ovs-pki
-rwxr-xr-x.  1 root     17347 May  1  2023 ovs-tcpdump
-rwxr-xr-x.  1 root      2195 May  1  2023 ovs-tcpundump
-rwxr-xr-x.  1 root     12104 May  1  2023 ovs-vlan-test
-??????????  ? ?            ?            ? ovs-vsctl

今後は、CVMから「manage_ovs」を利用することが前提となっている流れでは無いかと思います。

AHVにおける仮想スイッチ（ブリッジ）の作成方法

AHV環境におけるAOS 5.19からPrism UIをとおして仮想スイッチの作成やアップリンクNICの設定変更、アップリンクNICのチーミングモードの変更が行えるようになりました。

AOS5.19は、STSのため次のLTSバージョンが出ればより多くの方のこの機能を利用していただくことができますが、新しいLTSが出るにはすこし時間がかかります。

現時点のLTSであるAOS 5.15においてAHV環境では、アップリンクの変更やブリッジの作成は、コマンドベースで行う必要があります。

今回は、新たなブリッジを作成する方法そして次に、アップリンクのNICチーミング方法の設定についてご紹介をしていきます。

仮想スイッチ（ブリッジの作成）は、AHV上で行います。なお、追加の仮想スイッチを作る場合は本番業務には影響はありませんが、アップリンクNICの操作間違いなどにより1ノードが疎通できなくなるとHAが発動する事象が出ることも考えられますので、アップリンクNICを含め操作する場合は、事前に仮想マシンを停止しクラスターサービスを止めておくことをおすすめします。

まずは、仮想スイッチを作成します。

manage_ovs --bridge_name br1 create_single_bridge

仮想スイッチ（ブリッジ）が出来たことを確認するため「manage_ovs show_bridges」を実行します。

$manage_ovs show_bridge
Bridges:
br0
br1 ★

続いて新たに作成したbr1のアップリンクモードを設定します。
bond-modeは以下から選択可能です。

bondモード	使用事例	上位スイッチ
active-backup	デフォルトの構成であり、推奨構成。 単一のアクティブなNICが全てのトラフィックを処理します。	通常ポート設定
balance-slb	各仮想NIC毎にアップリンクのNICが割り付けられます。 マルチキャストトラフィックの一部で問題が発生するため、推奨されていません。 接続する物理スイッチ側は、LAGの設定をしないで下さい。	通常ポート設定
balance-tcp	仮想マシンが通信するポート番号によって利用するアップリンクNICを割り付けます。 本機能は、接続する物理スイッチでLACPの設定を行って下さい。静的LAGモードは非サポートです。	LACP（動的）

現行ホストに存在しているNICを「manage_ovs show_interfaces」で確認します。

$ manage_ovs show_interfaces
name  mode  link speed
eth0  1000 True  1000
eth1  1000 True  1000
eth2  1000 False  None
eth3  1000 False  None
eth4 10000 False  None
eth5 10000 False  None
eth6 10000  True 10000
eth7 10000  True 10000

ここでは、eth4とeth5のNICを割り付けます。eth4とeth5は、まだリンクアップしていない状態でアップリンクの設定をするため「--require_link=false」を付与します。

なお、既存で用意されているデフォルトの仮想スイッチ（br0）においてアップリンクモードを変える場合も以下のコマンドを利用します。

manage_ovs --bridge_name br1 --interfaces eth4,eth5 --require_link=false --bond_mode=active-backup update_uplinks

では、アップリンクNICと仮想スイッチ（br1）の状態を以下のコマンドで確認していみます。

$manage_ovs show_uplinks
Bridge: br0
  Bond: br0-up
    bond_mode: active-backup
    interfaces: eth7 eth6 
    lacp: off
    lacp-fallback: false
    lacp_speed: slow
Bridge: br1
  Bond: br1-up
    bond_mode: active-backup
    interfaces: eth4 eth5 ★
    lacp: off
    lacp-fallback: true
    lacp_speed: off

これで作業は完了です。続いて、VLANの作成を行います。
AOS5.19より前の環境においては、複数の仮想スイッチを作成した場合、VLAN作成は必ず「acli」で作成を行って下さい。これは、PrismのVLAN作成画面ではどの仮想スイッチに対してVLANを作成するかの指定が出来ないためです。
ここでは、VLAN20のネットワークを新しく作成したbr1側に作成したいと思います。

acli net.create vlan20-seconde-net vlan=20 vswitch_name=br1

重要な点は、vswitch_nameを定義することです。

以上で、作業は完了です。PrismのNetwork Visualizationの画面で見ると新しい仮想スイッチ（ブリッジ）が作成されNICがアップリンクに割り当たっていることが分ります。

作業における注意点は以下の通りです。

• アップリンクNICを変更することでノード間疎通が出来なくなるとトラブルが発生することが予見されます。あらかじめホストをメンテナンスモードにするかクラスターサービスの停止を行った上で作業を行って下さい。
• manage_ovsは、操作を行ったCVMのホストにのみ反映されます。クラスター内の全てのノードに対して作業を一括で行うためには、「hostssh "manage_ovs ～」と、hostsshで各ホストに実行を行って下さい。
• manage_ovsは、クラスターメンバーに属していないノードでも作業が可能です。クラスターに新規で追加を行うノードに対してmanage_ovsでアップリンク設定を変更した上で、ノード拡張を行うことが可能です。
• AOS5.1までで利用していた、ovs-vsctlコマンドによる仮想スイッチ作成は、AOS5.5以降サポートされていません。

本項目では、manage_ovsコマンド出の作業方法をお伝えしました。acliで、「net.create_cluster_vswitch」を利用すると、各ノードをローリングでメンテナンスモードのしながらアップリンクNICの設定を変更できます。（当然ながらクラスターサービスが起動している状態で実施）

この「net.create_cluster_vswitch」は、AOS 5.19からは「net.create_virtual_switch」コマンドに変更されており、Prism側の仮想スイッチ作成オペレーションと紐付いた操作が可能となっております。

AOS5.0時代に比べるとAHVにおける仮想スイッチの操作はだいぶ楽になっていますが、ovs-vsctlコマンドでの操作が廃止になったり、acliでの仮想スイッチ操作がコマンドが変更になったりとかなり時代に応じて変更されています。

AOS5.19以降はPrismからの操作が最も楽な方法かと思いますが、次のLTSバージョンがリリースされるまでは、現行のLTSであるAOS 5.15の利用においては今回ご紹介したコマンドベースでの作業となります。（次のLTSが待ち遠しい物です）

AOS 5.19アップデート（その1）AHV環境における仮想スイッチの作成方法

AHV環境において１つハードルが高いことは、仮想スイッチを複数利用する構成です。
結論から言えば構成は可能なのですが、従来AHVにおける仮想スイッチの作成は、CVM上から「manage_ovs」コマンドを実行し、環境を確認しながら、AHV上で「ovs-vsctl」コマンドで設定を行うという、あまりユーザーフレンドリーとは言えない状況でした。

そもそもNutanixおいては、シンプルな構成を目指していることと、NutanixのCVM間の通信がデーターローカリティーの概念により10Gネットワークをフルで利用することがないため、10GのネットワークにVLAN分離でサービス系とCVMのネットワークを混在して利用してもなんら問題がないため、そこまで大きな問題として顕在化することはありませんでした。

とはいえ、セキュリティの観点からアップリンクNICを意図的に分けたいなどの構成や設計の方針で仮想スイッチを分けなければいけないことがあるかと思います。

そんな仮想スイッチ作成作業ですが、AOS 5.19よりPrismの操作だけで、仮想スイッチに追加・削除ができるようになりました。

今日は、この仮想スイッチの追加機能について紹介いたします。

＜ブリッジと仮想スイッチについて＞

そもそもAOS5.18までは、AHVにおける仮想スイッチは、ブリッジという表現をしていました。しかし、AOS5.19でブリッジという表現は表上からは消えて「vs(Virtual Switch)」という表現に改められています。もちろんbr0という形で内部的にはブリッジとして動作しているので、表面上の表現だけが変更になりました。

▼AOS 5.15.4のNetwork Visualizationでのホストのネットワーク画面

▼AOS 5.19のNetwork Visualizationでのホストのネットワーク画面

＜仮想スイッチの作成方法＞

では、実際に2個目の仮想スイッチを作成していきましょう。
今回は、10Gのネットワークで利用しているbr0には割り当てられておらず、どこの仮想スイッチにも割り当てられていない、1GのNIC「eth3」と「eth4」のNICを「service-sw」という新たに作る仮想スイッチに割り当てたいと思います。

まずは、ギアアイコン→「Network Configuration」→「Virtual Switch」に移動します。
Foundation直後は、vs0として1つの仮想スイッチが見える状態になっています。

ここから、右上の「+ Create VS」をクリックします。

次に、仮想スイッチに必要なパラメーターを入れるウィザードが出てきます。
仮想スイッチ名、説明、MTUサイズ（1280~9216）を入力します。
Configuration Methodは、詳細な設定ができるよう「Standard」を選択します。
Quickは、各ホストをメンテナンスモードにせずホストを再起動します。ホスト自体はrollingでの再起動となりますが、時間短縮のためメンテナンスモードにせずホスト再起動を掛けるため、仮想マシンワークロードが稼動していると予期せぬ仮想マシンのパワーオフが実施されますので、仮想マシンがCVM以外に存在しない状況の場合のみ選択できます。

ここでは、「service-sw」と名称を設定します。

次に、アップリンクモードやアップリンクNICの設定ができる画面が表示されます。

BondTypeには、「Active-Backup」「Active-Backup with MAC pinning」「Active-Active」「No Uplink Bond」が選択できます。
No Uplink Bondは、チーミング指定なしということになります。通常のサーバー運用ではまず選択しないオプションになるかと思います。

Select Hostsは、設定反映するホストを指定します。こちらの機能はおそらくノード拡張後にボンドモードが既存クラスターと異なっている場合に利用する機能のようで、完全に新規の仮想スイッチを選択する場合、「All Hosts」を選択しないと、ウィザードの次の画面に行こうとすると「When creating/editing a virtual switch, all hosts must be selected (except storage-only node).」と表示されます。

続いて、新しく作る仮想スイッチに割り当てる物理NICを選択します。
ここでは、eth3と4を割り当てます。
このNIC選択は、ホスト毎に選択できますので、複数ホストある場合は、1ホストずつ別のNICを割り当てることも可能です。

ここまでパラメーターを入れたら、「Create」で仮想スイッチを作成します。

今回はQuickを選択していませんでしたが、稼動している仮想マシンが少なかったのもあり、3台のホストを再起動しても時間は20分かからないぐらいでした。

全てのホストの再起動が終わると、タスクが完了します。

完了後は、いつも通り「Network Configuration」→「+ Create Network」からVLANを作成します。

VLANの作成画面で、仮想スイッチの選択画面が出てきていることが分ります。
ここで、先程作成した仮想スイッチを選択し、VLANを作成します。

作成が完了したVLANは、そのままPrismのVirtual Machinesの画面から、仮想マシンに割り当て可能です。

Network Visualizationで確認してみましょう。

ホストを選択すると、先程作成した仮想スイッチとアップリンクNICが割り当てられていることが分ります。

Virtual Switch出先ほど作成したスイッチ「service-sw」をチェックを入れるとアップリンクNICの色が既存の仮想スイッチであるvs0とは別の色で表示されます。

＜仮想スイッチの削除方法＞

仮想スイッチの削除も、Virtual Switchの一覧から削除可能です。（既存で存在するvs0は削除できません）

以上で、仮想スイッチの作成方法は終わりです。

しかし、今までのあのコマンドと長いパラメーターを利用せず仮想スイッチを作成できるようになったのは、個人的には感動的な機能です。（というかもっと早く実装してほしかったというのが正直なところですが）

AHV利用時のハードルがまた一つ消えたことは、よりAHVが身近なハイパーバイザーに進化してきているという現れだと思います。