Nutanix CE 2.1(AOS 6.8.1)を稼動させる自宅環境を整備する（その2）

前回までにスペックアップとして、まずCPUとメモリーを準備しました。

メモリーは、curcial(micron)製のDDR4-3200 32GB × 4枚（128GB）

CPUは、Core i7 8700 × 1 

となります。

メモリーは、新品で購入しました。今回1枚単位で購入しまたが、2枚セットのもであれば、為替状況にも寄りますが、2万円ちょっとで64GB分を購入できます。

（参考）
Crucial デスクトップ用増設メモリ 64GB(32GBx2枚) DDR4 3200MT/s(PC4-25600) CL22 UDIMM 288pin CT2K32G4DFD832A

CPUは、ヤフオクで購入しました。

早速、メモリーを搭載し、CPUを交換してみましょう。

CPUにグリスを塗り、再びヒートシンクを取り付け、動作を確認します。

電源を入れ、BIOS画面に入ります。BIOSが起動する時点で、CPUやメモリーは動作しているので、あとは正しい値が表示されるかを確認します。

ばっちり、Core i7 8700と、メモリーも128GBで見えていました。

メーカー記載の値は、動作確認済みの値なだけであり、実際には、Core i7も動作しますし、メモリーも64GBを超えて認識できますね。

ということで、CPUとメモリーの拡張はこれで終わりました。

次回は、SSDやHDDの取り付けを行います。

Nutanix CE 2.1(AOS 6.8.1)を稼動させる自宅環境を整備する（その1）

2024年8月20日にNutanix CE 2.1 (AOS 6.8.1ベース）がリリースされました。
CE2.0 (AOS 6.5.2)ベースの物から、アップデートでAOS6.8.1にアップグレードすることは可能なのですが、AHVが、「2022系(el7)」から6.8.1で利用される「2023系(el8)」にアップグレードが、CEの場合は、出来ないようです。

では、改めて仮想化環境が見なおされている昨今、自宅で利用できるNutanix CE環境をお手軽に作ることができないかを考えてみました。

自宅にサーバーを置くということを考えるとハードルが高いので、以下の条件を元に考えていきたいと思います。

＜選定の条件＞

• 静音・省スペースであること
• コスト面から最新のCPUではなく、古いものでもよい
• メモリーは、64GB以上搭載できる
• IPMIを搭載したサーバーモデルであること
  （長時間運用に耐えられる機器）

省スペースなサーバーとなると、国産メーカーのサーバーに絞られてしまいます。今回は市場の流通量が多い、「NEC Express 5800/T110j-S」（NP8100-2797YP1）を選定してみました。

モデルとしては新しくありませんが、パフォーマンスの検証などをするのではなければある程度は動作するだろうというレベルと、やはり手頃な価格です。

私は、新品のモデルを2万円で入手しましたが、オークションサイトなどではもっと安く手に入るとおもいます。

ただ、この（NP8100-2797YP1）は、本当の最小限スペックのため、このベースモデルでは、Nutanixを稼動させることはできません。

NP8100-2797YP1のベーススペック

CPU	Pentium Gold 5420 (3.8GHz)
RAM	8GB
HDD	1TB × 2 (SATA 3.5インチ)
NIC	1G NIC×2 (intel)
IPMI	1ポート

スペック情報は、こちらから参照出来ます

これでは、話になりませんので、パーツ交換を前提にする必要があります。

NECから更改されているアーキテクチャー図が公開されていますので、確認するとCPUは、Celeron/Pentium/Core i3/Xeon (Coffeelake-s)と記載されています。

i3の次がいきなりXeonで、CoffelakeとなるとE-2100/E-2200シリーズとなるため、パーツの流通も少なく、1個あたりオークションサイトでも2万円近くするためあまり現実的ではないようにも思います。

なにより、メモリーが64GBまでのサポートというのは、ちょっと納得いきません。

もう少し情報はないものかと思い、内部を見ているとこのサーバーは、NEC御用達、GIGABYTE製のメインボードであることが、実機を見るとわかります。

ということで、GIGABYTEの製品情報をこちらから確認してみます。同じモデルはありませんでしたが、MX32-BS0という兄弟モデルの情報がありました。おそらくNECのモデルはこのメインボードのカスタマイズモデルのように思われます。（BS0は、M.2スロットがありますが、NECのMX32-PH1は、M.2スロットがPCI 16xのスロットになっています）

こちらの図を見てもベース情報はあまり変わりありません。

しかし、Coffe Lake-Sであれば、Core i7 8700の利用ができることや、Core i7 8700からは、メモリーサポートも128GBまでサポートされているはず。

intelのホームページより

ということで、今回は試しに、Core i7 8700とメモリー128GBを搭載して動作するかを確認してみます。

次回は実際に、パーツを交換してみたいと思います。

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

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

WindowsのNTPサーバをCVMから参照させる方法

Nutanixは、分散アーキテクチャーを採用しているため、 NTPによる時刻同期は、非常に重要です。NTPサーバーは、必ず用意をする必要があります。

NutanixのコンポーネントであるCVMやAHVは、いずれもLinuxベースのOSで動作していることもあり、Nutanixクラスターが指定するNTPサーバーは、Windows OS以外のものを指定することが推奨されています。

（参考）Recommendations for Time Synchronization
https://portal.nutanix.com/page/documents/details?targetId=Web-Console-Guide-Prism-v6_8:wc-ntp-server-time-sync-recommendations-c.html

Synchronizing a Nutanix cluster with a Windows time source is known to cause issues over a period of time, so Nutanix recommends that you not synchronize a cluster’s time with Windows NTP sources. Use reliable non-Windows time sources instead. In an Active Directory domain, the best practice (a design that both works around and improves upon having to include domain controllers in the list of NTP sources) is to bypass the domain controllers and to synchronize the Nutanix hosts and CVMs directly with the NTP sources with which the domain controllers synchronize their time. Specify a common list of at least five reliable non-Windows NTP sources for both the domain controllers and the Nutanix cluster.

ADがNTPとして動作している場合、ADに設定されている上位のNTPサーバーを、設定することを推奨とされていますが、ネットワークセキュリティの観点から、自由にNTPサーバーを指定することが難しいケースや、わざわざLinuxやBSDでNTPサーバーを立てるのも手間がかかります。

今回は、Windows ベースのNTPで、可能な限りCVMで時刻同期ができる環境を作る情報をご紹介します。ただし、どうしてもNTPサーバを用意できない場合の参考情報であり、実際の本番環境で利用する場合は、Windows以外のNTPサーバー環境をご用意いただくことを強く推奨します。

WindowsのNTPサーバーになるマシンで、NTPサーバー側で以下のレジストリを設定します。

場所：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

値：
NTPServer = "上位のNTPServer,0x8"
Type = "NTP"

場所：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

値：
LocalClockDispersion = dowrd:0
AnnounceFlags = dword:5
MinPollInterval = dowrd:6
MaxPollInterval = dowrd:a

場所：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer

値：
Enabled = dword:1

この設定の後、Windows Timeサービスを再起動します。

イベントログを確認し、WindowsのNTPが上位のNTPを正常に参照できているかを確認します。

あとは、Prism側にNTPサーバーの登録を行います。

登録したのち、実際に反映されるまで15分程度かかります。

その後、CVMで「sudo chronyc -n sources -v」で、NTPサーバー登録が正常に行われて降り、同期対象になっているかを確認します。

nutanix@NTNX-aca83545-A-CVM:~$ sudo chronyc -n sources -v
  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 192.168.54.1                  3   6   377    21   +378us[ -982us] +/-  113ms
^+ 192.168.54.2                  3   6   377    22   -641us[-2002us] +/-  122ms

時刻同期が行われているNTPを「sudo chronyc -n」で確認します。

nutanix@NTNX-aca83545-A-CVM:~$  sudo chronyc -n
racking|grep Ref
erence
Reference ID    : C0A83601 (192.168.54.1)

同期ステータスを「sudo chronyc tracking」確認します。

nutanix@NTNX-aca83545-A-CVM:~$  sudo chronyc tracking
Reference ID    : C0A83601 (192.168.54.1)
Stratum         : 4
Ref time (UTC)  : Sat Jul 27 05:16:22 2024
System time     : 0.000760825 seconds slow of NTP time
Last offset     : -0.001093699 seconds
RMS offset      : 0.000706507 seconds
Frequency       : 4.807 ppm slow
Residual freq   : -0.459 ppm
Skew            : 4.433 ppm
Root delay      : 0.071808040 seconds
Root dispersion : 0.061855555 seconds
Update interval : 65.2 seconds
Leap status     : Normal

なお、AOS6.8から、RockyLinuxベースになったこともあり、ntpも、chronydに変更されています。従来の「ntpq」コマンドは利用できなくなっていることも注意してください。

WindowsのNTPであっても、同期が可能な限り取れる方法をご紹介しましたが、よりクリティカルが環境での利用は、推奨される非Windows環境のNTPサーバーを指定することをお勧めします。

（参考）Chronyd: Troubleshooting Guide
https://portal.nutanix.com/kb/16363

（参考）
https://qiita.com/fukuchan-senpai/items/1fa755ffaffe6a25a2f2

AHVにおけるNICの追加または交換時の作業

Nutanixを導入後、一時してからNICの交換や追加といった作業は、通常想定される作業となるかと思います。AHV環境において、NICを追加又は交換をした場合、その後AHVを起動しても新しいNICが見えない状態になります。NICの交換や追加を行った場合は、以下のコマンドを実行します。

AHVで実行

/usr/local/bin/nic_add_or_replace

上記コマンドが実行できない場合は、

rm /etc/udev/rules.d/70-persistent-net.rules

を実行ごAHVを再起動します。

こちらのコマンドで、NICの再認識を来ないます。

但し注意が必要です。このコマンドを利用するとeth0,eth1などの順序が以前と異なる事があります。また、1G NICだけしか構成していない環境に10G NICを追加後上記コマンドを実行すると、1G NICがアップリンクから外されるなど、単純にNICの認識だけでにとどまらないケースがあります。

CVM側で、アップリンクの状態を確認しておきましょう。

AHVから実行

$ssh nutanix@192.168.5.2
CVMのnutanixユーザーのパスワードを入力

$ manage_ovs  show_uplinks
#↓結果
Bridge: br0
  Bond: br0-up
    bond_mode: active-backup
    interfaces: eth3 eth2 ★ここを確認する
    lacp: off
    lacp-fallback: false
    lacp_speed: slow

NIC故障など、急に対応が必要になることもあるかと思いますので、この手順は頭の片隅に入れておくと便利かと思います。

PrismCentralのUltimateライセンス トライアルモードの有効化

Prism Centralは、展開すると自動的にPrism Ultimateのトライアルモードが有効になり、90日間Ultimate機能を利用することが可能でした。

このトライアル機能自体は、継続して提供されているのですが、Prism Central 2024.1よりこのトライアルモードがデフォルトでは無効化されています。

今回は、このトライアルモードを有効化する方法をご紹介します。
（展開サイズは、Small以上であることが条件です）

まずは、Prism CentralのAdmin Centerから、「Inteligent Operations」を開き「Allocate & Enable」をクリックします。

これは、X-Fitで利用されるリソースが従来は込みで展開されていましたが、2024.1からは、別離ソースとして追加をする必要があるようです。

確認のメッセージが出ますので、OKをクリックします。

Prism Centralのリソースが追加されたことを確認します。なお、このリソース追加の処理を行うと、Prism Centralとの疎通ができなくなる（Prismの画面が表示されなくなる）のですが、しばらく待っているとPrism画面が再度表示されます。

▼リソースが追加されたことがわかります。

Prismに再度ログインし、再びAdmin Centerを開きます。

「Licesing」→「Applied Licesenses」を開きます。

Prismのチェックを入れ、「Action」から「View Product Features」を開きます。

ライセンスのエディション画面が表示されますので、ここから「Enable Ultimate Trial」のトグルを有効化します。

また、Prismとのアクセスが一旦できなくなりますが、しばらく待っているとPrism画面が復活します。

これで、Ultimate のトライアルが利用できます。トライアルの利用期間は、90日となります。

AOS6.8/Prism Central 2024.1以降のPC登録解除時の注意点

AOS6.8に対応したPrism Centralは、2024.1以降のバージョンとなります。

これらのバージョンの組み合わせにおいて、Prism Elementから1度Prism Central登録を行った後、登録を解除すると以前に登録したPrism Centralであっても、別で展開したPrism Centralであっても登録ができなくなる仕様となっているようです。

（参考）In pc.2024.1, Prism Element is blacklisted and cannot be registered to either the same PC or a different PC
https://portal.nutanix.com/kb/15679

これは、Prism Centralとの登録を解除するクラスターは、今後破棄予定のクラスターという認識だからのようです。（そんな極端な認識にいきなり変わっても困るのですが...）

CVMのncliコマンドから、以下のようにPrism Centralの解除コマンドを実行すると以下のようなメッセージが追加されてます。

<ncli>  multicluster remove-from-multicluster cluster-id=aac92028-1b14-4688-a891-c1e4acf842ec username=admin password=PrismCentlraのパスワード external-ip-address-or-svm-ips=192.168.XX.XXX

▼Unregist前に確認されるメッセージ

Unregistering the PE from PC is not a supported workflow. Are you sure you want to proceed(YES/NO) ?(Refer to KB-15679 for details): 

ここで「Y」を入力するとPrism Centralの登録が解除されます。

ちなみに、先程まで登録されていたPrism Centralに再度Nutanixクラスターを登録してみたところ、以下のようなブラックリスト入りされているというエラーメッセージがタスクに表示され登録する事ができません。

別でPrism Centralを再展開しましたが、同じメッセージが表示され、やはりPrism Centralに登録する事は、できませんでした。

今まで、Prism Centralのバージョンアップをせずに再展開して、Nutanixクラスターを再登録などして運用されていた場合、AOS6.8以降での運用時には、注意が必要です。

Nutanix CEにおけるinode問題の対応

2024年7月現在、Nutanix CEのインストーラーに含まれているAOSは、6.5.2となります。

このバージョンでは、inodeの枯渇によるクラスターサービスの稼動に影響を与える恐れがあります。

この事象、稼動させてすぐは起きず、しばらく経って（私の環境では、稼動させて1年程度経った後に事象が発生）から起きるため、すぐに事象が発生しませんが、しばらく経ってから起きる可能性があるため、注意が必要です。

3ノード以上でクラスターを作っている場合、1ノード障害に耐えることが出来ますが、検証用で1ノードクラスターを作成している場合、クラスターサービスが起動できなくなる事象が出る可能性もあります。

本事象は、NCCの「inode_usage_check」にて検出されますので、このチェック項目がWarningもしくはFailとして検出された場合は、速やかに対応が必要となります。

（参考）NCC Health Check: inode_usage_check
https://portal.nutanix.com/kb/1532

本事象は、AOS6.5.3以上にアップグレードすれば解決しますので、この事象を回避するため、これからCEを展開する方は、展開後に速やかにアップグレードをしていただくことをお勧めします。

既存でNutanix CEを利用していて、1ノードクラスターで構成している場合、アップグレードする前にこの事象が出てしまうと、AOS自体のアップグレードができない可能性もあります。

この事象が発生した場合、「/var/spool/postfix/maildrop」がinodeを消費している可能性があります。

まず、「/home/nutanix」の使用量が100%近くになっている可能性がありますので以下のコマンドで、空き容量も確認しておきます。

allssh 'df -i /'

さて、この事象を取り急ぎ対処するためには、以下のコマンドを実行します。

allssh 'sudo postsuper -d ALL maildrop'

これで、「/home/nutanix」ディレクトリの空き容量も増えるかと思いますし、クラスターサービスも「cluster start」で正常起動するはずです。

いずれにしてもAOSアップグレードを定期的に行っておけば特に心配する問題でもありませんので、定期的なアップグレードを行う事が大切かと思います。

また、Nutanixのアップグレードは、非常に簡単に行えるための機能が用意されていますので、難しいコマンドを利用することなくアップグレードが可能ですから、積極的なアップグレードを勧めします。

Prism上に残ったタスクのステータスを中断に変更する方法

Prismで様々なタスクを実行していると、まれにですがタスクが進まず残ってしまうことがあります。

 ▼タスクが進まず残ってしまったところ

この残ってしまったタスクは、大半が裏で動作しているタスクが、Prismに対してステータスが渡されていない状態になっていることが考えられます。タスク自体が裏で実行中の物であれば、そのまま待てば良いですが、タスク自体が異常終了するなどしている場合、ステータスだけがの進行中のまま残ってしまいますので、こういった場合は、表示上のステータスを変更を行い、タスクとしては中断した状態のステータスにすることで、タスク表示に残り続ける状態を改善します。

※この方法は、本番環境でむやみに使う物ではありませんので、本番環境でのタスク表示が残った場合は、必要に応じてサポートに問い合わせを行ってください。

タスクステータスを変更する方法

まず、SSHで、CVMにログインを行います。

次に以下のコマンドを実行します。

ecli task.list include_completed=false

すると、以下のようなタスクの結果が表示されます。
（横スクロールで確認してください）

Task UUID                             Parent Task UUID                      Component     Sequence-id  Type                                                       Status
6971450b-a9b5-4b13-6083-a747aeda976f  a66b9851-2318-4a56-6023-8f5781583ea6  cluster_sync  14           Password sync on 192.168.38.174                            kRunning
a66b9851-2318-4a56-6023-8f5781583ea6                                        cluster_sync  10           Password sync: Password changed for admin or nutanix user  kRunning

ここでは、親タスクと子タスクがあります。

この場合、いきなり親タスクを中断できませんので、先に子タスクを中断します。

ergon_update_task --task_uuid='6971450b-a9b5-4b13-6083-a747aeda976f' --task_status=aborted

すると、以下のような確認が来ますので、「y」を入力し、タスクを中断します。

WARNING: Using this command can cause database corruption and complete system failure, if used improperly.
Are you sure you want to continue? (y/n)
y

これで、タスクは「abort」つまり、中断扱いになります。

どうしてもタスクの表示が変わらず表示に残り続けるなどがある場合、このコマンドでタスクステータスを中断に変更することで、終了タスクとして表の表示に残り続けることが無くなるようになると思います。

Prism Centralのトライアル機能を無効化する方法

Prism Centralは、デフォルトで180日間のトライアル機能があります。
Prism Ultimate機能を利用すると、クラスターのリソースの無駄を洗い出したり、リソースの枯渇状況を今までの利用から推測する機能など様々な機能が提供されます。

トライアル期間が有効な間は、以下のようにPrism Central上部に緑のバーが表示されますが、90日のトライアル期間がが終了すると、ライセンス切れのバーがずっと表示されたままになります。

トライアル期間が終了後、Prism Centrralの無償版の機能で継続利用することが可能なのですが、画面上Ultimateトライアル機能を無効化するトルグボタンが、Prism Central 2022.6以降表示されなくなっています。

トライアルのUltimate機能を無効化するためには、以下のコマンドをPrism CentralにSSHでログインし、実行します。

curl --location --request POST 'http://localhost:9080/PrismGateway/services/rest/v1/license/Starter?enable=false' --header 'X-Nutanix-Preauth-User: admin' --header 'Content-type: application/json' --header 'Accept: application/json'

#続いてnccで再度ライセンスチェックを行います
ncc health_checks system_checks check_license_compliance

実行完了後、Prism Centralの画面をログアウトし、再度ログインします。

これで、Prism Ultimateのトライアル機能が無効化されます。

コマンドの内容を見る限り、APIを直接コールしているので、おそらく以前はこのAPIをPOSTするトグルボタンがあったのが、それがなくなった（というか間違って消した？）のでは無いかと思います。

元々GUIで出来た機能なので、これは新しいPrism Centralで戻してほしいところではありますが...。

（参考）Disable Prism Ultimate Trial License in Prism Central
https://portal.nutanix.com/kb/11101

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」を利用することが前提となっている流れでは無いかと思います。

仮想マシンにのNICにVLANトランクを設定する方法

ネットワーク関連の仮想アプライアンスなど、複数のネットワークを持たせた仮想マシンを構成することがあるかと思います。AHVの場合、「AHV-20230302.207」バージョンの場合、1つの仮想マシンに対して、仮想NICの搭載は15個が最大とされています。

なお、15を超えるNICを仮想マシンに追加することは、Prismの画面上可能なのですが、仮想マシンのパワーオンに時間がかかります（NICの数に応じて30秒を超える）。

コンパチビリティを考えてもNICの数は15個以内に収めておきたいところですが、Firewall的な動作をする仮想マシンなどNICを15個以上必要とする場合があるかと思います。

このような場合、仮想マシンの仮想NICに対して、TAGVLANをそのまま仮想NICに流す、トランクモードの設定を行うことが出来ます。

今回は、AHV環境において仮想マシンにVLAN Trunkを渡すNICの作成方法をご紹介します。

まずは、Prism画面から普通通り仮想マシンを作成します。この際、NICは搭載せずNICなしの仮想マシンとして作成してください。

次に、acliで、仮想NICの割当を行います。

acli vm.nic_create [仮想マシン名] vlan_mode=kTrunked trunked_networks=[通信させたいVLAN-IDをカンマ区切りで記入] network=[UNTAGで割り当てるNIC]

仮想マシンに対して、UNTAGのネットワーク（いわゆるNativeVLAN）を割り当てたくない場合であっても、「network」の定義は必須となります。
（UNTAG側で通信をさせたくない場合は利用しないVLANを作成し、そのVLANを割り当ててください）

では、仮想マシン側ではどのように設定をするかもご紹介します。

まずは、Windows Serverの場合です。

サーバーマネージャーのNICチーミング機能を有効化します。

まずは、チームから「チームの新規作成」をクリックします。

チーミング設定を行います。とはいえ、NICは１本しかありませんの、１本のNICを選択します。１本のNICですからバランシングもできません。仮想マシンの場合は、チーミングモードを「スイッチに依存しない」、負荷分散モードを「アドレスのハッシュ」を選択します。（それ以外のオプションを選択した場合、チーミングNICは作成できません）

プライマリ チームインターフェースは、このNICに対して割り当てるVLANをNativeVLAN以外にする場合は、こちらのオプションで「特定のVLAN」で、指定したいVLAN-IDを入力します。

作成が完了すると、アダプターとインターフェースの部分に、作成したNICが表示されます。

ここからさらに違うVLAN用にNICを作成する必要がありますが、「アダプターとインターフェース」の「タスク」メニューから「新しいチームに追加」がクリックできません。
わかりにくいのですが、「チームインターフェース」を選択し、再度「タスク」をクリックすることで、「新しいチームを追加する」がクリックできるようになります。

▼チームインターフェースを選択

こちらのインターフェースの追加をクリックすることで、別のVLANを割り当てたNICを作成することができます。

ネットワーク接続の画面から見ると、物理のNIC（こちらは、IPアドレスなどの設定をしないでください）と、チーミングされた２つのNICが見えています。IPアドレスの付与や各種設定は、このチーミングされたNICに設定を行います。

LinuxOSの場合もご紹介します。

Rocky Linux 9.3での設定方法を見てみましょう。（他のRHEL互換OSである、Alma Linuxなども同様の設定となります）

最初に、「ip addr」で、既存NICの情報を確認します。

[root@rocky93master admin]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 50:6b:8d:86:5c:7d brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 10.168.1.70/24 brd 10.168.1.255 scope global dynamic noprefixroute ens3

       valid_lft 28434sec preferred_lft 28434sec
    inet6 fe80::526b:8dff:fe86:5c7d/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

この場合、VLAN用にNICを作成する元NICが、「ens3」であることがわかります。このNICをもとにVLAN401のNICを作成してみます。

シェル画面で「nmtui」を実行し、「接続の編集」をクリックします。

新規NICを作成するので、「追加」を選択します。

作成したNICは「VLAN」を選択します。

プロファイル名はわかりやすい名称にします。デバイス名も管理しやすいデバイス名にしておきます。
親は、VLAN通信をする元NICになります。先ほど事前に調査したNIC「ens3」を入力します。VLAN idには、通信させたいVLAN IDを入力します。IPv4設定等は、状況に応じてIPアドレス付与を行います。

作成されたVLAN NICができたことを確認し、「戻る」を選択します。

nmtuiを終了します。

シェル画面から、「ip addr」コマンドで再度、NICの状態を確認します。

[root@rocky93master admin]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 50:6b:8d:86:5c:7d brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 10.168.1.70/24 brd 10.168.1.255 scope global dynamic noprefixroute ens3
       valid_lft 27267sec preferred_lft 27267sec
    inet6 fe80::526b:8dff:fe86:5c7d/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
5: ens401@ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 50:6b:8d:86:5c:7d brd ff:ff:ff:ff:ff:ff
    inet 10.14.254.75/16 brd 10.14.255.255 scope global dynamic noprefixroute ens401
       valid_lft 5878sec preferred_lft 5878sec
    inet6 fe80::442a:a590:abec:e8a0/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

追加したNICである、「ens401」が追加され、この場合、DHCPを使ってIPアドレスが取得できていることがわかります。

その他仮想アプライアンスの場合は、そのアプライアンスの指示に従いVLANインターフェースの作成が可能かと思いますので、利用したい製品でのVLANインターフェース作成方法をご参照ください。

Nutanix Filesのコマンド操作一覧

日本においてもNutanix Filesを実際に利用するケースが増えてきております。Nutanix Filesは、従来のWindows Serverを使ったファイルサーバーでは実現の難しい、大規模なスケールアウト型のファイルサーバーを構築することが可能です。一方Nutanix Filesは、一部の設定をコマンドでしか設定できない設定があります。本日は、コマンドでしか設定できない内容を中心に紹介します。ご紹介する作業は、一部のコマンドを除いてFSVMにSSHでログインし、設定をおこなうことを前提としています。また、今回のコマンドは、Files 4.4.1をベースに記載しています。

タイムゾーン設定

FilesのタイムゾーンはデフォルトUTCになっています。この場合、SSR等の一部の機能がUTCをベースにして稼動してしまうため、稼動している地域のタイムゾーンで稼動するように設定が必要です。（この作業は、導入後最初に行う事をお勧めします）

afs fs.set_timezone "Asia/Tokyo"

FilesのSSR開始時間を指定する

SSRの開始時間は、UTCタイムゾーンを基準に動作します。そのため、GUI画面で指定したSSRの時間は、日本の場合9時間ずれて実行されます。SSRの時間基準を日本時間に合わせるためには、オフセットを9時間ずらす必要があります。

afs snapshot.set_ssr_hourly_offset 9

Filesの起動及びシャットダウン方法

Filesは、FSVMををシェルに入ってシャットダウンすることは、正しいシャットダウン方法として認められていません。Filesクラスターをシャットダウン後FSVMをシャットダウンする必要があります。起動時も個別でFSVMを起動してもFilesクラスターは起動しません。それらの手順を一元化して行うコマンドがあります。こちらの手順は、CVMから行います。

起動方法

afs infra.start *

シャットダウン方法

afs infra.stop *

ここでは、登録されているFilesクラスターを全て起動するため「*」を入れていますが、1つのNutanixクラスターに複数のFilesクラスターがあり、その1つを起動及びシャットダウンするためには、「*」部分にFilesクラスター名称を入れることで、任意のFilesクラスターの起動及びシャットダウンが可能です。

サブマウント

Nutanix Filesは、作成された共有フォルダ毎にその共有フォルダーを処理するFSVMが決定されます。そのため、1つの共有フォルダの配下に大量のフォルダを作成した運用の場合、1つのFSVMのみに負荷がよってしまいNutanix Filesの本来のメリットである分散処理ができなくなってしまいます。しかし、従来からの共有フォルダ運用を行っていた場合、いきなり運用方法を変更することも難しいかと思います。
そのような場合、既に作成した共有フォルダに、別の共有フォルダをサブフォルダとして割り当てることができます。この場合、DFSの機能のような形で実際に共有フォルダの配下にあるサブマウントされた共有フォルダは、別の共有フォルダにアクセスするため別のFSVMに負荷が分散するため、共有フォルダの構造をなるべく変えずにFSVMの負荷分散を行うことが出来ます。

afs share.edit child-share-name submount_path=submount-path

child-share-nameは、Filesで作成した共有フォルダ（サブフォルダに当てたいフォルダ）を入力します。

submount_pathは、実際にサブフォルダに割り当てたいフォルダパス（/親共有フォルダ/サブフォルダ名）という形の記載をします。

この際に注意をしてほしいことは、割り当てたいサブフォルダ名のフォルダを予めWindowsのエクスプローラ等で作成しておく必要があります。そのフォルダがオーバーライドされたサブマウントしたい共有フォルダにオーバーライドされます。

サブフォルダのマウント状態は、以下のコマンドで一覧表示させることができます。

afs share.list_all_submounted_shares

実行結果例

afs share.list_all_submounted_shares
+--------------+--------------+-----------------------+
| Parent Share | Child Share  | Submount Path         |
+--------------+--------------+-----------------------+
| 親フォルダ   | サブフォルダ | /親フォルダ/サブサブ/ |
+--------------+--------------+-----------------------+

WORMフォルダの作成

ファイルを誤って削除したり変更できないようにする共有フォルダを作成できます。既に作成された共有フォルダには、後から設定できません。フォルダ作成時に設定を行う必要があります。

afs share.add 共有フォルダ名 worm_enabled=true worm_retention_period=time in seconds worm_cooloff_interval=time in seconds worm_type=ShareLevel

パラメーター	説明
legal_hold	すべてのユーザーによる期限切れファイルの削除を禁止します。
description	共有の説明を入力します。
hard_quota_size_gb	ハード クォータ サイズを GB 単位で入力します。
protocol	NFS または SMB として指定します。
share_type	共有タイプを default(標準共有）または、distributed(分散共有）を指定します。
size_gb	共有のサイズを GB 単位で入力します。
timeout	タイムアウトを秒単位で入力します。
worm_cooloff_interval	WORM のクールオフ間隔を秒単位で指定します。Cooloff_interval のデフォルト値は 600 秒 (10 分) です。
worm_enabled	true（有効）またはfalse（無効）を指定します。
worm_type	ShareLevelを指定します
worm_retention_period	保持期間の値を秒単位で指定します。保持期間のデフォルト値は 31449600 秒 (52 週間) です。

シンボリックの有効化

Files上で作成されたシンボリックを利用できる用にする機能です。この機能を利用する為には、予めWindowsクライアントで
「fsutil behavior set SymlinkEvaluation  R2R:1  R2L:1」
コマンドを実行し、シンボリックリンクが利用できる状態にしておく必要があります。

afs smb.set_conf "enable smb symlinks" "False" section=global

通常GUIで設定できる項目もコマンド設定できますが、今回はコマンドでしか設定できない項目をご紹介しました。

 

AHVにおけるメモリーオーバーコミットの利用方法（その1）

AHV環境においては、長らく仮想マシンのメモリー割り当ては、ハードウェアからの予約となり、他の仮想マシンとのメモリーの空き容量を相互に使うメモリーオーバーコミット機能が利用できませんでした。AHV 20201105.30007 以降を備えたハイパーバイザーとAOS 6.0.2以降であれば、メモリーオーバーコミットが利用可能となります。

今回は、このメモリーオーバーコミットの紹介をします。

そもそもメモリーオーバーコミットとは、なにかをおさらいしておきましょう。

メモリーオーバーコミットは、仮想マシンに割り当てられたメモリーのうち、仮想マシンのOSレイヤー以上で利用されていないメモリーを、Balloonドライバーで回収し、ハイパーバイザーに戻すことで、本来のホストの持つ物理メモリーサイズを超えて、仮想マシンにメモリーを割り与えることです。即ち、空いている容量を他の仮想マシンに転用するだけであって、物理的に利用できるメモリー容量が増えるわけでは、ありません。また、メモリーは、1台のホスト内でメモリーのやりくりを行うので、ホストを超えてのメモリーのオーバーコミットはできません。

単純にわかりやすく考えると、月極駐車場で、100台の駐車スペースを法人契約していた場合、平日の10時から16時までは、平均80台の車が営業車として利用されており駐車スペースが空いているため、10時から16時までの間に別の利用者に貸し出すような考え方です。（オーバーブッキングビジネスの考え方）

要は、枠としては、既に押えられているが、実質使われていない空いているキャパシティーを、さらに利用するような考え方となります。

では、メモリーオーバーコミットの利用方法を具体的にご紹介します。

メモリーオーバーコミットは、仮想マシン単位で設定します。

Prism Centralで仮想マシンを作成する際、もしくは作成済みの仮想マシンに対して、Enable Memory Overcommitメニューで、メモリーオーバーコミット機能を有効化します。

Prism Centralでの有効/無効以外に、acliを利用して、メモリーオーバーコミットの有効/無効の設定が可能です。

acli vm.update 仮想マシン名 memory_overcommit=true/false

環境としては、以上で設定は終わりです。仮想マシンには、VirtIO Driverの最新版（Ver 1.2.1）を利用して、バルーンドライバーのインストールが必須となります。

Windowsの場合は、Nutanixが提供する、VirtIO Driverからインストールを行います。

Linuxの場合は、カーネルにバルーンドライバーが入っているかを確認します。

lsmod | grep baloon

で、以下のように結果が表示されれば、バルーンドライバー（カーネルモジュール）が入っています。

virtio_balloon         24576  0

もし入っていない場合は、カーネルモジュールの設定変更する必要があります。

Ballon Driverは、カーネルビルド時に利用する"make menuconfig"の「Device Drivers -> Virtio Drivers」の中にあります。

メモリーオーバーコミットの仕様も確認しておきましょう。

• AOS6.0.2以降/AHV 20201105.30007以降でサポート
• 最新のVirtIO Driverを仮想マシンインストールします
• メモリーオーバーコミットの有効/無効は、仮想マシン単位で、仮想マシンがパワーオフの状態で設定します。
• PrismCentral 2022.4以降であれば、GUIで仮想マシン単位でメモリーオーバーコミットの設定が可能です。
• ホストを超えたメモリーオーバーコミットはできませんん。
• GPUパススルーやvGPUを設定した仮想マシン、vNMUA設定をした仮想マシンは、メモリーオーバーコミットできません。
• メモリーオーバーコミットを有効にした仮想マシンは、仮想マシンのメモリーホットアドは、できません。
• ライブマイグレーションを行う場合、通常に比べ移動の速度が遅くなる可能性があります。
• 物理メモリーの枯渇に備え、スワップファイルが内部的にNutanixManagementShareストレージコンテナ内に作成されます。
• デフォルトで、各仮想マシンは、割り当て容量の25%が物理メモリーに割り当てが保証（予約）されます。残りの75%は、他の仮想マシンのメモリーオーバーコミット領域として利用されることがあります。（すなわち、4倍までオーバーコミット可能）

仮想マシン側も準備ができれば、あとは、動きを見てみましょう。

メモリーオーバーコミットは、ホストを超えてメモリーをオーバーコミットすることができませんので、今回は、わかりやすいように1台のNutanixホストで試してみたいと思います。

物理搭載メモリー192GBから、CVMが消費するメモリー32GBとハイパーバイザーが利用するメモリーが4GB程度ありますから、実際には、160GB程度しか仮想マシンは利用できないと思います。

この環境で、メモリーを160GB割り当てた仮想マシンを作成します。

この場合、160GBのメモリーをこの仮想マシン専用に確保することができないため、仮想マシンを起動することができません。

しかし、メモリーオーバーコミット機能をONにすると仮想マシンを起動することができます。実際に利用されているメモリー容量は、この場合、160GBのメモリー割り当てに対して、20.67%しか利用していないことがわかります。メモリーオーバーコミットが有効化された仮想マシンは、割り当てられたメモリーサイズの75%がメモリーのオーバーコミットとして他の仮想マシンで起動する際に利用される領域となります。

しかし、CVMは、オーバーコミットができないはずですが、なぜかハイパーバイザーの容量を考えても物理メモリーとして利用できる範囲を超えていると思われます。

では、物理メモリーを超えた容量を割り当てた場合はどうなるのでしょうか？最初に256GBで割り当てたところ、仮想マシンは起動しませんでした。200GBでも起動しませんでしたが、199GBにすると仮想マシンは起動します。はっきりした仕様がわかりませんが、おそらく物理メモリー容量に、8GB未満までであれば仮想マシンに物理容量を超えるメモリーサイズが利用できる可能性があります。

ここからさらに、28GBのメモリーを割り当てた仮想マシンを起動すると、きちんと起動します。最大4倍までがオーバーコミットできるので、トータルで物理メモリー容量を超えた形で仮想マシンを起動することができます。

次回は、より詳細にメモリーオーバーコミットの動きを見ていきたいと思います。