転載・引用について

ユーザ用ツール

サイト用ツール


os:xenserver:tips

差分

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

この比較画面へのリンク

両方とも前のリビジョン前のリビジョン
次のリビジョン
前のリビジョン
os:xenserver:tips [2019/01/04 02:07] – [XCP-ng 7.4から7.5へのUpgrade] seiriosos:xenserver:tips [2023/10/25 03:06] (現在) – [注意点] seirios
行 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/XenConsole/XOA からは2TiB以上のVirtual DiskをVMに割り当てることができない。この場合の2TiBは「割り当てられた全てのVirtual Diskの容量の合計」であって、個々のVirtual Diskの容量ではないことに注意が必要である。 
 + 
 +しかし、様々な事情により、4TiBのVirtual Diskを持つTimeMachine Backup用のVMを作成したい状況になってしまったので、対応策を以下に記載する。 
 + 
 +==== 準備 ==== 
 +今回は、Boot用に10GiB、データ用に4TiBのVirtual Diskを持つVMを作成するものとする。 
 + 
 +  - XCP-ng Console等から新規VMを作成する。 
 +  - 普通通りにVMを作成すれば良いが、自動起動をOffにすることと、起動用の10GiBのDiskのみをVMにattachしておく。 
 +  - 作成が終了すれば、VMは起動されないので、準備完了 
 + 
 +==== 4TiBのDiskをAttachする ==== 
 +この作業はXCP-ng Consoleからはできないので、XCP-ngにloginし、CLIを駆使して作業する。 
 + 
 +  - ''xe sr-list name-label=NameOfNAS'' 
 +    * ここで、SRのUUIDを取得する。取得したUUIDを以下 [SRuuid] と表記する 
 +  - ''vgs | awk '{print $1}' | grep [SRuuid]'' 
 +    * ここで、VG名があることを確認する。取得したVG名を以下 [VGname] と表記する 
 +  - ''lvcreate -L4T -n"LV-"$(uuidgen) [VGname] --config global{metadata_read_only=0}'' 
 +    * ''-L4T'' は容量が4Tということなので、自分の必要な容量を指定すること 
 +  - ''xe sr-scan uuid=[SRuuid]'' 
 +    * XCP-ng側で新たに作成したLVを認識させる 
 + 
 +これで、XCP-ng ConsoleのSRから新たに作成したVirtual Diskが見えるようになっているはずなので、XCP-ng consoleから確認し、準備で作成したVMにattachする 
  
 ===== XCP-ngでlocaldiskの処理をする ===== ===== XCP-ngでlocaldiskの処理をする =====
行 108: 行 227:
   - POOL上の auto startを有効化 ''xe pool-param-set uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx other-config:auto_poweron=true''   - POOL上の auto startを有効化 ''xe pool-param-set uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx other-config:auto_poweron=true''
   - 有効化したい VM でこれを実行 ''xe vm-param-set uuid=UUID other-config:auto_poweron=true''   - 有効化したい VM でこれを実行 ''xe vm-param-set uuid=UUID other-config:auto_poweron=true''
-===== XenServer 6.2 以降への Hotfixの適用 ===== 
-XenServer 6.2からは、XenCenterでのPatch適用は出来なくなった。 
-XenCenterからHotFixを適用するには、Citrixからライセンスを買う必要がある。 
-しかし、さすがに個人でそんなことをするのは馬鹿げているので、手動でpatchを適用する。 
- 
-Patch適用の方法は、HotFixのページに記載されているが、ここに一応手順を記載しておく 
- 
-  - とにかく HotFix をDownloadする 
-  - とにかく XenServer PoolのPool MasterにHotFixを転送する 
-    * なお、HotFixを転送する前には、Archiveを展開し、XS62Exxx.xsupdateファイルを転送しておくこと 
-  - pool masterにloginし、以下のコマンドを突っ込む 
-    - ''xe patch-upload -s localhost -u root -pw <password> file-name=<path_to_update_file>/XSxxExxx.xsupdate'' 
-      * ここで、出力されるUUIDをメモする。 
-    - このタイミングで、もしXenServer側で認識されるNICをe1000に変えているならば、以下を実施 
-      * (XenServer 6.2まで) chattr -i /usr/lib/xen/bin/qemu-dm 
-      * (XenServer 6.5から) chattr -i /usr/lib64/xen/bin/qemu-dm 
-    - xe -s localhost -u root -pw <password> patch-pool-apply uuid=[上記UUID] 
-      * これで patchが適用されるはず 
-    - xe patch-list -s localhost -u root -pw <password> name-label=XSxxExxx 
-      * システムにpatchが適用されているか確認。なお、name-labelを省略すると、適用されている全HotFixが表示される 
-    - 必要に応じて、xe-toolstack-restartかサーバーの再起動を行う。特に、kernelの置き換えの場合には再起動必須。 
-      * 再起動すべきかどうかは、after-apply-guidanceを見れば判断できる。 
-        * restartXAPI → xe-toolstack-restart 
-        * restartHost → 再起動 
- 
-なお、各VMを移設してから実施すること。必要に応じて、Storage Migration/Pool間Migrationを活用すること 
- 
-===== FV時にVMに割り当てるNICをe1000にする ===== 
-http://www.netservers.net.uk/articles/open-source-howtos/citrix_e1000_gigabit 
- 
-XenServer 6.2までの場合 
-<code> 
-mv /usr/lib/xen/bin/qemu-dm /usr/lib/xen/bin/qemu-dm.orig 
-vi /usr/lib/xen/bin/qemu-dm.sh 
- 
-===== Start of qemu-dm.sh ===== 
-#!/bin/bash 
-oldstring=$@ 
-newstring=${oldstring//rtl8139/e1000} 
-exec /usr/lib/xen/bin/qemu-dm.orig $newstring 
-===== End of qemu-dm.sh ===== 
- 
-cp /usr/lib/xen/bin/qemu-dm.sh /usr/lib/xen/bin/qemu-dm 
- 
-chmod 755 /usr/lib/xen/bin/qemu-dm 
-chattr +i /usr/lib/xen/bin/qemu-dm 
-</code> 
- 
-XenServer 6.5からの場合 
-<code> 
-mv /usr/lib64/xen/bin/qemu-dm /usr/lib64/xen/bin/qemu-dm.orig 
-vi /usr/lib64/xen/bin/qemu-dm.sh 
- 
-===== Start of qemu-dm.sh ===== 
-#!/bin/bash 
-oldstring=$@ 
-newstring=${oldstring//rtl8139/e1000} 
-exec /usr/lib64/xen/bin/qemu-dm.orig $newstring 
-===== End of qemu-dm.sh ===== 
- 
-cp /usr/lib64/xen/bin/qemu-dm.sh /usr/lib64/xen/bin/qemu-dm 
- 
-chmod 755 /usr/lib64/xen/bin/qemu-dm 
-chattr +i /usr/lib64/xen/bin/qemu-dm 
-</code> 
- 
-なお、qemu-dm.shは、環境変数に格納されている文字列の文字列置換を行っているので、bash以外で正しく動作する保証が無い 
- 
-この方法でFV時のNICをe1000として認識させる場合、XenServerのupdate(HotFix)を適用するときに問題が出る場合がある。 
-これは、chattrを利用してqemu-dmを保護しているからである。従って、HotFix適用の際には、適用前に以下を実施する 
-<code> 
-*** XenServer 6.2まで *** 
-chattr -i /usr/lib/xen/bin/qemu-dm 
- 
-*** XenServer 6.5から *** 
-chattr -i /usr/lib64/xen/bin/qemu-dm 
-</code> 
  
-この保護を入れる理由は、単純にUpdateされてしまい、qemu-dmが置き換えられてしまうと、NICがrtl8139に認識されるようになってしまうからである。つまり、あえてUpdateを失敗させて、やり直しできるようにするのが目的である。 
  
 ===== MetaData Backup ===== ===== MetaData Backup =====
os/xenserver/tips.1546535254.txt.gz · 最終更新: 2019/01/04 02:07 by seirios

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki