差分

このページの2つのバージョン間の差分を表示します。

--- os:xenserver:tips [2019/09/24 14:06] – [XenServer Tips] seirios
+++ os:xenserver:tips [2023/10/25 03:10] (現在) – 外部編集 127.0.0.1
@@ 行 1: / 行 1: @@
-====== XenServer Tips ======
+====== XenServer/XCP-ng Tips ======
+===== NICを交換する =====
+本項はXCPng 8.3でのNIC交換に関するメモである
+  * [[https://support.citrix.com/article/CTX135809/how-to-change-order-of-nics-in-xenserver]]
+=== まくら ===
+XCP-ngはXCP-ng 8.3時点でOSとして「非常に大きく改変されている」がCentOSを利用している。これはつまり、NICのChipが何であろうとNetwork Interfaceをeth?? として管理しているということである。
+さて、Poolを組み、複数台の同一構成のマシンを所属させるとしても、kernelの認識順序によって、eth??に割り当てられるportが同じになるとは限らない。
+実際、手元の環境では、
+^         NIC         ^ Host A ^ Host B ^ 備考 ^
+| Onboard igb         |   eth0 |   eth1 |  GbE  |
+| Chelsio T520 Port 0 |   eth1 |   eth0 | 10GbE |
+| Chelsio T520 Port 1 |   eth2 |   eth2 | 10GbE |
+となってしまい、Host AとHost B間でNetwork I/Fが違う状況になってしまった。これでは、Poolを組んだ時に、igbにManagementを割り当てようとして困ることになるし、実際、PoolのNetworkを作る際に困ったことになった。
+というわけで、Host Bのeth0/eth1を入れ替えたいということになる。
+また、NICが壊れてしまった場合、NICを交換することになる。
+以下の構成である場合を例にする。
+  ; eth0 : Onboard NIC (Intel GbE 1port)
+  ; eth1 : Chelsio T520 port 1 (Chelsio 10GbE) 利用中
+  ; eth2 : Chelsio T520 port 2 (Chelsio 10GbE) 利用中
+ここで、Chelsio T520が壊れたので、交換しようとすると、以下の手順を取ることになる。
+  - XCP-ngをshutdownする
+  - NICを交換する
+  - 起動する
+    * ここで、XOAでNetworkを確認すると、eth1-eth2が見えて、新しいNICは見えない。
+  - PIFをforgetする
+    * 以下のscriptを実行する。
+    * <code>
+# for i in 1 2 3 4; do
+> xe pif-list device=eth$i | egrep '^uuid' | sed 's/.*: //' | xargs -i xe pif-forget uuid={}
+> done
+</code>
+  - ここで、xe pif-scanを実行すると、eth1/eth2に新しいNICのポートを割り当てて欲しいのだが、そうならずeth3/eth4が生えてしまう。
+=== 変更 ===
+というわけで、以下に、ethの番号を設定する方法を記載しておく。
+  - NICを交換したい/番号を付け替えたいServerをpoolから外す(XOAなどでどうぞ)
+  - NICを交換したい/番号を付け替えたいServerのConsoleにloginする
+    * Management portをいじる場合、(Network越しではなく)直接Consoleからlocal shellを起動してloginする
+  - 必要な設定を投入する
+    * ''/etc/sysconfig/network-scripts/interface-rename-data'' に移動する
+      * Distroやversionによって異なることを書いてある記事が多いので注意。XCP-ngの場合は、上記ファイル。
+    * ''dynamic-rules.jsonを'' Editorで開く
+    * oldに登録されている情報を全て削除
+      * これで、起動時に余計なNICデータは削除される
+      * 登録されているNICの情報(Mac Addressなど)を確認し、device名をeth??に変更する
+      * 再起動 ''reboot'' する
+  - XCP-ngが起動する
+  - 以下の作業を実行する
+    - Console(xsconsole)からshellを実行
+    - ''xe pif-list'' を実行
+    - 不要なpifを ''xe pif-forget uuid=xxx'' を実行して削除
+    - ''xe pif-scan host=xxx'' を実行して、PIFを登録する
+    - ''xsconsole'' から ''Network and Management Interface'' メニューで、管理I/Fを設定する
+  - あとは、XOAで認識させて、必要な設定を実行する
+=== 注意点 ===
+  * 状況にもよるのだろうが、対象となるXCP-ng Serverがpoolに所属している場合、xeコマンドが正しく動作しないことがあった。その場合、poolから当該のserverを外す必要がある
+    * おそらく、Poolに所属している場合、同一Pool内の他のマシンの情報を取得しようとして固まるのだと思われる
+  * もしdevice名を変更したいNICがManagementのNICである場合、xe pif-forgetでもpifを削除できない。
+    * この場合、別にNICにManagement Networkを割り当てて(xsconsoleから設定すれば良い)、Management Networkではないように設定する必要がある
+===== NetworkのMTUを変更する =====
+一般に、通常のInternet通信ならMTUを1500以外に変更する意味はない。Flet'sでPPPoEを利用する際に若干小さくする(1480Bytes程度)にすることは無駄ではないが、せいぜいその程度。
+しかし、LAN内で特にStorageのような通信量が多いNetworkで10G I/Fを使用している場合においては、MTUが1500ではNetwork的に遅くなるし、CPU負荷も（若干だが）上がってしまう。
+特にXCP-ngのStorage Network(iSCSIとかNFSを利用しているNetwork)においては、MTUの差は大きく効くことになる。
+しかし、XOA 単体では、NetworkのMTUを変更できないので、以下に変更の手順を。(なお、前提としてXCP-ng 8.2以降、XOAによる制御環境とする)
+  - XOAで対象のPoolに接続し、Network Tabを開く
+  - MTU変更の対象となるNetworkを確定し、右側にあるUUIDをCopyする
+  - Consoleから(XOAからでも良い)対象のPOol MasterのConsoleに接続する
+  - 以下のような操作を行う
+    * <code>
+# xe network-param-set uuid=[Copyしたnetwork-uuid] MTU=9000
+</code>
+  - 変更したPool内の各Serverの当該PIFを確定し、各serverにおいて以下を実行する
+    * <code>
+# xe host-management-reconfigure pif-uuid=<PIF_UUID>
+</code>
+    * これを実行しないと、I/FのMTUは旧来のままとして表示される
+  - これでNetwork、NICともにMTUが変更される。一応pingを打って（可能なら''ping -s 9000 [dest]''で9000Byteのpingを飛ばし、tcpdumpでpacketが分割されていないことを確認する)
 ===== XCP-ngで2TiB以上の大きさのDiskをVMに割り付ける =====
-XCP-ng(おそらくはXenServerも)は、XCP-ng Consoleからは2TiB以上のVirtual DiskをVMに割り当てることができない。この場合の2TiBは「割り当てられた全てのVirtual Diskの容量の合計」であって、個々のVirtual Diskの容量ではないことに注意が必要である。
+XCP-ng(おそらくはXenServerも)は、XCP-ng Console/XenConsole/XOA からは2TiB以上のVirtual DiskをVMに割り当てることができない。この場合の2TiBは「割り当てられた全てのVirtual Diskの容量の合計」であって、個々のVirtual Diskの容量ではないことに注意が必要である。
 しかし、様々な事情により、4TiBのVirtual Diskを持つTimeMachine Backup用のVMを作成したい状況になってしまったので、対応策を以下に記載する。