os:xenserver:tips
差分
このページの2つのバージョン間の差分を表示します。
両方とも前のリビジョン前のリビジョン次のリビジョン | 前のリビジョン最新のリビジョン両方とも次のリビジョン | ||
os:xenserver:tips [2018/09/27 17:32] – [XCP-ng上でのGuest VMのauto power on] seirios | os:xenserver:tips [2023/10/25 02:23] – [XCP-ngで2TiB以上の大きさのDiskをVMに割り付ける] seirios | ||
---|---|---|---|
行 1: | 行 1: | ||
- | ====== XenServer Tips ====== | + | ====== XenServer/ |
+ | |||
+ | ===== NICを交換する ===== | ||
+ | 本項はXCPng 8.3でのNIC交換に関するメモである | ||
+ | |||
+ | * [[https:// | ||
+ | |||
+ | === まくら === | ||
+ | XCP-ngはXCP-ng 8.3時点でOSとして「非常に大きく改変されている」がCentOSを利用している。これはつまり、NICのChipが何であろうとNetwork Interfaceをeth?? | ||
+ | |||
+ | さて、Poolを組み、複数台の同一構成のマシンを所属させるとしても、kernelの認識順序によって、eth?? | ||
+ | 実際、手元の環境では、 | ||
+ | |||
+ | ^ | ||
+ | | Onboard igb | ||
+ | | Chelsio T520 Port 0 | eth1 | eth0 | 10GbE | | ||
+ | | Chelsio T520 Port 1 | eth2 | eth2 | 10GbE | | ||
+ | |||
+ | となってしまい、Host AとHost B間でNetwork I/ | ||
+ | |||
+ | というわけで、Host Bのeth0/ | ||
+ | |||
+ | また、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を実行する。 | ||
+ | * < | ||
+ | # for i in 1 2 3 4; do | ||
+ | > xe pif-list device=eth$i | egrep ' | ||
+ | > done | ||
+ | </ | ||
+ | - ここで、xe pif-scanを実行すると、eth1/ | ||
+ | |||
+ | === 変更 === | ||
+ | というわけで、以下に、ethの番号を設定する方法を記載しておく。 | ||
+ | - NICを交換したい/ | ||
+ | - NICを交換したい/ | ||
+ | * Management portをいじる場合、(Network越しではなく)直接Consoleからlocal shellを起動してloginする | ||
+ | - 必要な設定を投入する | ||
+ | * ''/ | ||
+ | * Distroやversionによって異なることを書いてある記事が多いので注意。XCP-ngの場合は、上記ファイル。 | ||
+ | * '' | ||
+ | * oldに登録されている情報を全て削除 | ||
+ | * これで、起動時に余計なNICデータは削除される | ||
+ | * 登録されているNICの情報(Mac Addressなど)を確認し、device名をeth?? | ||
+ | * 再起動 '' | ||
+ | - XCP-ngが起動する | ||
+ | - 以下の作業を実行する | ||
+ | - Console(xsconsole)からshellを実行 | ||
+ | - '' | ||
+ | - 不要なpifを '' | ||
+ | - '' | ||
+ | - '' | ||
+ | - あとは、XOAで認識させて、必要な設定を実行する | ||
+ | |||
+ | === 注意点 === | ||
+ | * 状況にもよるのだろうが、対象となるXCP-ng Serverがpoolに所属している場合、xeコマンドが正しく動作しないことがあった。その場合、poolから当該のserverを外す必要がある | ||
+ | * もしdevice名を変更したいNICがManagementのNICである場合、xe pif-forgetでもpifを削除できない。 | ||
+ | * この場合、別にNICにManagement Networkを割り当てて(xsconsoleから設定すれば良い)、Management Networkではないように設定する必要がある | ||
+ | ===== NetworkのMTUを変更する ===== | ||
+ | 一般に、通常のInternet通信ならMTUを1500以外に変更する意味はない。Flet' | ||
+ | |||
+ | しかし、LAN内で特にStorageのような通信量が多いNetworkで10G I/ | ||
+ | |||
+ | 特に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に接続する | ||
+ | - 以下のような操作を行う | ||
+ | * < | ||
+ | # xe network-param-set uuid=[Copyしたnetwork-uuid] MTU=9000 | ||
+ | </ | ||
+ | - 変更したPool内の各Serverの当該PIFを確定し、各serverにおいて以下を実行する | ||
+ | * < | ||
+ | # xe host-management-reconfigure pif-uuid=< | ||
+ | </ | ||
+ | * これを実行しないと、I/ | ||
+ | - これでNetwork、NICともにMTUが変更される。一応pingを打って(可能なら'' | ||
+ | ===== XCP-ngで2TiB以上の大きさのDiskをVMに割り付ける ===== | ||
+ | |||
+ | XCP-ng(おそらくはXenServerも)は、XCP-ng Console/ | ||
+ | |||
+ | しかし、様々な事情により、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を駆使して作業する。 | ||
+ | |||
+ | - '' | ||
+ | * ここで、SRのUUIDを取得する。取得したUUIDを以下 [SRuuid] と表記する | ||
+ | - '' | ||
+ | * ここで、VG名があることを確認する。取得したVG名を以下 [VGname] と表記する | ||
+ | - '' | ||
+ | * '' | ||
+ | - '' | ||
+ | * 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/ | ||
+ | - 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しないで済む可能性がある | ||
+ | * '' | ||
+ | * どのDiskが新しいDiskかを判断するのは実は結構難しい。 | ||
+ | * 個人的には、'' | ||
+ | * '' | ||
+ | * 今回は、'' | ||
+ | * '' | ||
+ | * 今回は、host-uuidが'' | ||
+ | * '' | ||
+ | * この時、追加したsdbはlvmで初期化されてしまうことに注意 | ||
+ | * 通常は問題にならないが、Partitionが分離されている場合、注意すること | ||
+ | |||
+ | これで、XCP-ng Center(XenCenter)の左側のペイン(Resource Pain)のXS-Sに、Local-Add-1が追加される | ||
+ | |||
+ | === (おまけ) 追加したLocal Storageを完全に切り離す方法 === | ||
+ | * '' | ||
+ | * SRのUUIDを'' | ||
+ | * '' | ||
+ | * PBDのUUIDを'' | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | これで、コマンドラインからlocal SRとLocal Diskを切り離せる。 | ||
+ | |||
+ | === 切り離されたLocal SRをReattachする方法 === | ||
+ | |||
+ | ここで、切り離さ亜れたDiskをLocal SRとして再度認識させる方法を以下に記載する | ||
+ | |||
+ | - pvdisplayを実行する | ||
+ | * 対象となる''/ | ||
+ | * ここでは、VG Nameが'' | ||
+ | * つまり、VG Name内に、SR-UUIDが記録されているということである。 | ||
+ | - '' | ||
+ | * この段階で Resource PainにDisk Iconに'' | ||
+ | - '' | ||
+ | * これで、SRと物理Diskの接続が明確になる | ||
+ | * PBDのUUIDが表示される。ここでは、'' | ||
+ | - '' | ||
+ | * これで、Resource PainのXS-Sの所に、'' | ||
+ | * currently-attachedが**false**であることに注意。 | ||
+ | - '' | ||
+ | * これで、Resource PainのXS-Sの所あった'' | ||
+ | * Resource Painから'' | ||
+ | * あとは、じっくり、正しいVMにDiskを接続していけばよい | ||
+ | - (おまけ) '' | ||
+ | * Storage Tabで表示される情報が出る。 | ||
+ | |||
+ | ===== XCP-ng 7.5から7.5.1へのUpdate ===== | ||
+ | - 以下のコマンドを実行 | ||
+ | * < | ||
+ | yum update -y | ||
+ | </ | ||
+ | - Pool Masterを再起動 | ||
+ | - Poolを構成するMaster以外のServerを再起動 | ||
===== XCP-ng 7.4から7.5へのUpgrade ===== | ===== XCP-ng 7.4から7.5へのUpgrade ===== | ||
行 25: | 行 222: | ||
- Pool masterを再起動 | - Pool masterを再起動 | ||
- 以下、Poolに所属している他のServerも同様に更新する | - 以下、Poolに所属している他のServerも同様に更新する | ||
- | |||
===== XCP-ng上でのGuest VMのauto power on ===== | ===== XCP-ng上でのGuest VMのauto power on ===== | ||
- xe pool-list で、pool の uuid をゲット '' | - xe pool-list で、pool の uuid をゲット '' | ||
- POOL上の auto startを有効化 '' | - POOL上の auto startを有効化 '' | ||
- 有効化したい VM でこれを実行 '' | - 有効化したい VM でこれを実行 '' | ||
- | ===== 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し、以下のコマンドを突っ込む | ||
- | - '' | ||
- | * ここで、出力されるUUIDをメモする。 | ||
- | - このタイミングで、もしXenServer側で認識されるNICをe1000に変えているならば、以下を実施 | ||
- | * (XenServer 6.2まで) chattr -i / | ||
- | * (XenServer 6.5から) chattr -i / | ||
- | - xe -s localhost -u root -pw < | ||
- | * これで patchが適用されるはず | ||
- | - xe patch-list -s localhost -u root -pw < | ||
- | * システムにpatchが適用されているか確認。なお、name-labelを省略すると、適用されている全HotFixが表示される | ||
- | - 必要に応じて、xe-toolstack-restartかサーバーの再起動を行う。特に、kernelの置き換えの場合には再起動必須。 | ||
- | * 再起動すべきかどうかは、after-apply-guidanceを見れば判断できる。 | ||
- | * restartXAPI → xe-toolstack-restart | ||
- | * restartHost → 再起動 | ||
- | |||
- | なお、各VMを移設してから実施すること。必要に応じて、Storage Migration/ | ||
- | |||
- | ===== FV時にVMに割り当てるNICをe1000にする ===== | ||
- | http:// | ||
- | |||
- | XenServer 6.2までの場合 | ||
- | < | ||
- | mv / | ||
- | vi / | ||
- | |||
- | ===== Start of qemu-dm.sh ===== | ||
- | #!/bin/bash | ||
- | oldstring=$@ | ||
- | newstring=${oldstring// | ||
- | exec / | ||
- | ===== End of qemu-dm.sh ===== | ||
- | |||
- | cp / | ||
- | |||
- | chmod 755 / | ||
- | chattr +i / | ||
- | </ | ||
- | |||
- | XenServer 6.5からの場合 | ||
- | < | ||
- | mv / | ||
- | vi / | ||
- | |||
- | ===== Start of qemu-dm.sh ===== | ||
- | #!/bin/bash | ||
- | oldstring=$@ | ||
- | newstring=${oldstring// | ||
- | exec / | ||
- | ===== End of qemu-dm.sh ===== | ||
- | |||
- | cp / | ||
- | |||
- | chmod 755 / | ||
- | chattr +i / | ||
- | </ | ||
- | |||
- | なお、qemu-dm.shは、環境変数に格納されている文字列の文字列置換を行っているので、bash以外で正しく動作する保証が無い | ||
- | |||
- | この方法でFV時のNICをe1000として認識させる場合、XenServerのupdate(HotFix)を適用するときに問題が出る場合がある。 | ||
- | これは、chattrを利用してqemu-dmを保護しているからである。従って、HotFix適用の際には、適用前に以下を実施する | ||
- | < | ||
- | *** XenServer 6.2まで *** | ||
- | chattr -i / | ||
- | |||
- | *** XenServer 6.5から *** | ||
- | chattr -i / | ||
- | </ | ||
- | この保護を入れる理由は、単純にUpdateされてしまい、qemu-dmが置き換えられてしまうと、NICがrtl8139に認識されるようになってしまうからである。つまり、あえてUpdateを失敗させて、やり直しできるようにするのが目的である。 | ||
===== MetaData Backup ===== | ===== MetaData Backup ===== |
os/xenserver/tips.txt · 最終更新: 2023/10/25 03:06 by seirios