転載・引用について

ユーザ用ツール

サイト用ツール


os:xenserver:tips

差分

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


前のリビジョン
os:xenserver:tips [2023/10/25 03:10] (現在) – 外部編集 127.0.0.1
行 1: 行 1:
 +====== 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環境において(おそらくXenServerでもそのまま適用できるはず)、あるXenServer hostにlocal storageを追加する必要に迫られることがある。
 +この時に、以下の状況が発生して酷い目にあうことがあるので、復旧方法のメモを。
 +
 +  - XenServerでPoolを組んでいる
 +    * ここでは、Pool masterをXS-M/その他のサーバーとしてXS-Sの2台でPoolを構成していると仮定する
 +  - Pool masterではないPool構成ServerにLocal Diskを追加して、それを認識させる
 +    * XS-Sに2TのDiskを接続し、Local SRとしてVMを設定する。接続されたDiskが仮に、sdbとして認識されたとする
 +    * Diskとしてどう認識されたのか、はdmesgなどを利用して確認すること。いくつかの手段は後述する
 +  - 新たに接続したDiskをLocal SR(name-label=Local-Add-1)として認識させる
 +  - VMなどを設置して稼働させる
 +  - なんらかの理由でXS-Sから追加したLocal-Add-1が消えた
 +    * 今回は、XCP-ngのUpdate時にうまく更新ができず、一度Poolから外してPoolに再度接続したら事象が発生した
 +
 +このような局面で、通常通りにLocal SRを構築してしまうと、Local-Add-1に記録されたVMのDisk Imageがなくなってしまい、痛い思いをすることになる。
 +
 +というわけで、ここでは、
 +  - Local SRの作り方
 +  - 切り離されたLocal SRをReAttachする方法
 +を記述する
 +
 +=== Local SRの作り方 ===
 +  * HDDをXS-Sに接続する
 +    * 近年では、Hot Plugができる筐体とMotherBoardが普及しているので、rebootしないで済む可能性がある
 +  * ''dmesg'' コマンドや''cat /proc/partitions'' などから、新たに接続されたDeviceのdevice nameを確認する
 +    * どのDiskが新しいDiskかを判断するのは実は結構難しい。
 +    * 個人的には、''dmesg''を利用してDevice nameを確認し、''/proc/partition''の当該の#blocksを見て容量から正誤判断することが多い
 +  * ''ls -l /dev/disk/by-id''の出力を確認し、Symbolic Linkの出力を見ながら、DiskのLabelを確認する。
 +    * 今回は、''wwn-0xzzzzzzzzzzzzzzzz -> ../../sdb''から、DiskのLabelが''wwn-0xzzzzzzzzzzzzzzzz''であるとする
 +  * ''xe host-list''を実行し、XS-Sのhost-UUIDを取得する
 +    * 今回は、host-uuidが''yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy''であるとする。
 +  * ''xe sr-create name-label="Local-Add-1" type=lvm device-config:device=/dev/disk/by-id/wwn-0xzzzzzzzzzzzzzzzz host-uuid=yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy'' を実行する
 +    * この時、追加したsdbはlvmで初期化されてしまうことに注意
 +    * 通常は問題にならないが、Partitionが分離されている場合、注意すること
 +
 +これで、XCP-ng Center(XenCenter)の左側のペイン(Resource Pain)のXS-Sに、Local-Add-1が追加される
 +
 +=== (おまけ) 追加したLocal Storageを完全に切り離す方法 ===
 +  * ''xe sr-list name-label="Local-Add-1"'' を実行し、SRのUUIDを取得する
 +    * SRのUUIDを''xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx''とする
 +  * ''xe pbd-list sr-uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx''を実行し、PBDのUUIDを取得する
 +    * PBDのUUIDを''wwwwwwww-wwww-wwww-wwww-wwwwwwwwwwww''とする
 +  * ''xe pbd-unplug uuid=wwwwwwww-wwww-wwww-wwww-wwwwwwwwwwww'' を実行し、PBDを切り離す
 +  * ''xe sr-forget uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'' を実行し、SRを削除する
 +  * ''xe pbd-destroy uuid=wwwwwwww-wwww-wwww-wwww-wwwwwwwwwwww'' を実行し、PBDを削除する
 +
 +これで、コマンドラインからlocal SRとLocal Diskを切り離せる。
 +
 +=== 切り離されたLocal SRをReattachする方法 ===
 +
 +ここで、切り離さ亜れたDiskをLocal SRとして再度認識させる方法を以下に記載する
 +
 +  - pvdisplayを実行する
 +    * 対象となる''/dev/sdb''のVG Nameを確認する。このVG Nameが存在しない場合、本件のScope外となるので色々調べてください。
 +    * ここでは、VG Nameが''VG_XenStorage-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx''であるとする。
 +    * つまり、VG Name内に、SR-UUIDが記録されているということである。
 +  - ''xe sr-introduce uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx name-label="Local-Add-1" type=lvm''を実行して、SRを作成する
 +    * この段階で Resource PainにDisk Iconに''×''が付いた状態ではあるが、SRが認識される
 +  - ''xe pbd-create host-uuid=yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy sr-uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx device-config:device=/dev/disk/by-id/wwn-0xzzzzzzzzzzzzzzzz'' を実行し、PBDを作成する
 +    * これで、SRと物理Diskの接続が明確になる
 +    * PBDのUUIDが表示される。ここでは、''vvvvvvvv-vvvv-vvvv-vvvv-vvvvvvvvvvvv''とする
 +  - ''xe pbd-list uuid=vvvvvvvv-vvvv-vvvv-vvvv-vvvvvvvvvvvv''を実行し、PBDの状況を確認する
 +    * これで、Resource PainのXS-Sの所に、''Local-Add-1''が''×''付きのまま移動する
 +    * currently-attachedが**false**であることに注意。
 +  - ''xe pbd-plug uuid=vvvvvvvv-vvvv-vvvv-vvvv-vvvvvvvvvvvv''を実行し、PBDを接続する
 +    * これで、Resource PainのXS-Sの所あった''×''が消える
 +    * Resource Painから''Local-Add-1''を選択し、Storage Tabを確認すると、DiskのListが表示される
 +    * あとは、じっくり、正しいVMにDiskを接続していけばよい
 +  - (おまけ) ''xe vdi-list sr-uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx''とすると、SR内に存在するVDI(Virtual Disk Image)が表示される。
 +    * Storage Tabで表示される情報が出る。
 +
 +===== XCP-ng 7.5から7.5.1へのUpdate =====
 +  - 以下のコマンドを実行
 +    * <code>
 +yum update -y
 +</code>
 +  - Pool Masterを再起動
 +  - Poolを構成するMaster以外のServerを再起動
 +
 +===== XCP-ng 7.4から7.5へのUpgrade =====
 +
 +  * [[https://xcp-ng.org/2018/08/10/xcp-ng-7-5-upgrade/]] を参照
 +    * 記事執筆時点で、7.6がRelease Candidateになっており、7.5系は7.5.1になっていることに注意。
 +    * 手順はおそらく変わらないだろうから、記載しておく。
 +
 +  - まず、対象poolのpool masterにsshなどでloginする
 +  - xsconsoleコマンドを実行する
 +    - ''Backup, Restore and Update'' を選択する
 +    - ''Backup Virtual Machine Metadata'' を選択する
 +    - Root passwordを入力する
 +    - Backupファイルを設置するSRを選択する。今回は ''local storage''
 +    - 数分待つ
 +    - QUITする
 +  - 別の手段としてCommandlineから ''xe pool-dump-database filename=[Filename].xml'' を実行
 +  - 以下のコマンドを実行
 +    * <code>
 +wget https://updates.xcp-ng.org/7/xcp-ng-7.5.repo -O /etc/yum.repos.d/xcp-ng.repo
 +yum clean metadata
 +yum install xcp-ng-deps
 +yum update
 +</code>
 +  - Pool masterを再起動
 +  - 以下、Poolに所属している他のServerも同様に更新する
 +===== XCP-ng上でのGuest VMのauto power on =====
 +  - xe pool-list で、pool の uuid をゲット ''xe pool-list''
 +  - 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''
 +
 +
 +===== MetaData Backup =====
 +  - xsconsole
 +  - Backup, Restore and Update
 +  - Backup Virtual Machine Metadata
 +の順でメニューを選べばあとはみたまま。
 +
 +===== Console画面を出す =====
 +<code>
 +[root@XenServ01 ~] xsconsole
 +</code>
 +
 +===== xeでVMのNICをいじる =====
 +xeコマンドでVMのNICをいじる為のメモ。
 +
 +AMDのブルドーザーコアマシンを使っていて、流石に古くなったので別のIntel XeonマシンにVMを移設した。
 +細かいところは今度まとめるので、テキストでメモ書き
 +
 +<code>
 +xe vif-list ←とにかくvifのlistを取得する
 +xe vif-param-list uuid=.... ←必要なvifを探す。見つけたら、network-uuid(3)をメモする
 +xe vm-list name-label="foo bar" ←とにかく、VMのUUIDを取得する(1)
 +xe vif-list vm-uuid=(1) ←VMに紐づいているvifのリストを取る
 +  VIFのUUID(2)が列記される
 +xe vif-destroy uuid=(2) ←VMにattachされているVIFがなくなる
 +xe vif-create vm-uuid=(1) network-uuid=(3) mac=random device=0
 + ←device 0番に適当に作成(random)したmac addressを
 +  つけ、新たなvifとしてVMにattachする
 +</code>
 +これで、既存のVMに割り当てているNICを置き換える事が出来る。
 +
 +ということは、こんな事をすればVMをxeコマンドだけで作れるってことかもしれない
 +<code>
 +事前に、割り当てたいNetworkのUUID(D)を取得する
 +xe vm-install new-name-label="VM のラベル名" template="テンプレートのUUID名" ←VMのUUID(A)が出力される
 +xe vm-param-set uuid=(A) VCPUs-at-startup=1 ←起動時のCPUは1つ
 +xe vm-param-set uuid=(A) VCPUs-max=1 ←CPUの最大値は1つ
 +xe vm-param-set uuid=(A) memory-dynamic-max=1073741824 ←Memoryは1G
 +xe vm-param-set uuid=(A) memory-dynamic-min=1073741824 ←Memoryは1G
 +xe vm-param-set uuid=(A) memory-static-max=1073741824 ←Memoryは1G
 +xe vm-param-set uuid=(A) memory-static-min=134217728 ←Memoryは最小でも100M
 +xe sr-list ←SRのリストを取得。VMを作りたいSRのUUID(B)をメモる
 +xe vdi-create sr-uuid=(B) virtual-size=17179869184 type=system name-label=(VDI のラベル名) sharable=false
 + ←Diskの容量は16G、System Diskとしてラベルをつける
 +  VDIのUUID(C)が出力される
 +xe vbd-create bootable=true device=xvda mode=RW type=Disk unpluggable=false vdi-uuid=(C) vm-uuid=(A)    
 + ←VBDを作成し、VMと結びつける
 +xe vif-create vm-uuid=(A) network-uuid=(D) mac=random device=0
 + ←VMにNetworkを割り当てる
 +xe vm-param-set uuid=(A) other-config:install-repository=http://mirror.centos.org/centos/6/os/x86_64
 +xe vm-param-set uuid=(A) PV-args="ksdevice=eth0"
 +xe vm-param-set uuid=(A) other-config:disable_pv_vnc=1
 + ←必要なパラメータをセットする
 +xe vm-start uuid=(A) ←VMを起動する
 +xe console uuid=(A) ←VMのConsoleに繋ぐ
 +</code>
 +あとはpif関連とかパラメータとかを理解すればいいのか。
 +
 +===== MTUを9000にする =====
 +    * XenServ01のeth1のMTUを9000にする場合
 +<code>
 +[root@XenServ01 ~]# xe pif-list host-name-label=XenServ01 device=eth1
 +uuid ( RO)                  : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 +                device ( RO): eth1
 +    currently-attached ( RO): true
 +                  VLAN ( RO): -1
 +          network-uuid ( RO): hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh
 +
 +[root@XenServ01 ~]# xe pif-param-set uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx other-config:mtu=9000
 +[root@XenServ01 ~]# 
 +</code>
 +    * これで再起動すれば eth1のMTUが9000になる
 +  * MTUを9000にしたものの、Switching HUBがMTU 9000に対応していないということはままあることですが、その時には、以下をどうぞ
 +<code>
 +[root@XenServ01 ~]# xe pif-list host-name-label=XenServ01 device=eth1
 +uuid ( RO)                  : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
 +                device ( RO): eth1
 +    currently-attached ( RO): true
 +                  VLAN ( RO): -1
 +          network-uuid ( RO): hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh
 +
 +[root@XenServ01 ~]# xe pif-param-get uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx param-name=other-config
 +: ; mtu: 9000;
 +[root@XenServ01 ~]# xe pif-param-clear uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx param-name=other-config
 +[root@XenServ01 ~]# xe pif-param-get uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx param-name=other-config
 +
 +[root@XenServ01 ~]# 
 +</code>
 +  * これでパラメータが消えます。ので、再起動してください。
 +    * 当然、NFSやiSCSIもMTUを1500にしておくほうがいいですよ。
 +  * なお、Xenに限らず、iSCSIやNFSを利用するなら、Networkを独立させて、かつJumbo Packetを通せるSwitchにしておくほうが性能が出ます。
 +
 +===== Open vSwitchのメモ =====
 +  - XenServer(XCP)内のOpen vSwitchの状況を確認する
 +    * ''brctl show''
 +    * ''ovs-vsctl show''
 +詳しいことは、これから調査...
os/xenserver/tips.txt · 最終更新: 2023/10/25 03:10 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki