os:xenserver:tips
差分
このページの2つのバージョン間の差分を表示します。
両方とも前のリビジョン前のリビジョン次のリビジョン | 前のリビジョン | ||
os:xenserver:tips [2018/09/27 16:10] – seirios | os:xenserver:tips [2023/10/25 03:06] (現在) – [注意点] seirios | ||
---|---|---|---|
行 1: | 行 1: | ||
- | ====== XenServer Tips ====== | + | ====== XenServer/ |
- | ===== XCP-ng上でのGuest VMのauto power on ===== | + | ===== NICを交換する |
- | - xe pool-list | + | 本項はXCPng 8.3でのNIC交換に関するメモである |
- | - POOL上の auto startを有効化 '' | + | |
- | - 有効化したい VM でこれを実行 '' | + | |
- | ===== XenServer 6.2 以降への Hotfixの適用 ===== | + | * [[https:// |
- | XenServer 6.2からは、XenCenterでのPatch適用は出来なくなった。 | + | |
- | XenCenterからHotFixを適用するには、Citrixからライセンスを買う必要がある。 | + | |
- | しかし、さすがに個人でそんなことをするのは馬鹿げているので、手動でpatchを適用する。 | + | |
- | Patch適用の方法は、HotFixのページに記載されているが、ここに一応手順を記載しておく | + | === まくら === |
+ | XCP-ngはXCP-ng 8.3時点でOSとして「非常に大きく改変されている」がCentOSを利用している。これはつまり、NICのChipが何であろうとNetwork Interfaceをeth?? として管理しているということである。 | ||
- | - とにかく HotFix をDownloadする | + | さて、Poolを組み、複数台の同一構成のマシンを所属させるとしても、kernelの認識順序によって、eth?? |
- | - とにかく XenServer | + | 実際、手元の環境では、 |
- | * なお、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/ | + | ^ |
+ | | Onboard igb | ||
+ | | Chelsio T520 Port 0 | eth1 | eth0 | 10GbE | | ||
+ | | Chelsio T520 Port 1 | eth2 | eth2 | 10GbE | | ||
- | ===== FV時にVMに割り当てるNICをe1000にする ===== | + | となってしまい、Host AとHost B間でNetwork I/ |
- | http:// | + | |
- | XenServer 6.2までの場合 | + | というわけで、Host Bのeth0/eth1を入れ替えたいということになる。 |
- | < | + | |
- | mv /usr/ | + | |
- | vi / | + | |
- | ===== Start of qemu-dm.sh ===== | + | また、NICが壊れてしまった場合、NICを交換することになる。 |
- | # | + | 以下の構成である場合を例にする。 |
- | oldstring=$@ | + | |
- | newstring=${oldstring// | + | |
- | exec / | + | |
- | ===== End of qemu-dm.sh ===== | + | |
- | cp / | + | ; eth0 : Onboard NIC (Intel GbE 1port) |
+ | ; eth1 : Chelsio T520 port 1 (Chelsio 10GbE) 利用中 | ||
+ | ; eth2 : Chelsio T520 port 2 (Chelsio 10GbE) 利用中 | ||
- | chmod 755 / | + | ここで、Chelsio T520が壊れたので、交換しようとすると、以下の手順を取ることになる。 |
- | chattr +i /usr/lib/xen/ | + | |
+ | | ||
+ | - 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/ | ||
- | XenServer 6.5からの場合 | + | === 変更 === |
- | < | + | というわけで、以下に、ethの番号を設定する方法を記載しておく。 |
- | mv /usr/lib64/xen/ | + | - NICを交換したい/ |
- | vi / | + | - 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を '' | ||
+ | - '' | ||
+ | - '' | ||
+ | | ||
- | ===== Start of qemu-dm.sh ===== | + | === 注意点 |
- | #!/bin/bash | + | * 状況にもよるのだろうが、対象となるXCP-ng Serverがpoolに所属している場合、xeコマンドが正しく動作しないことがあった。その場合、poolから当該のserverを外す必要がある |
- | oldstring=$@ | + | * おそらく、Poolに所属している場合、同一Pool内の他のマシンの情報を取得しようとして固まるのだと思われる |
- | newstring=${oldstring// | + | * もしdevice名を変更したいNICがManagementのNICである場合、xe pif-forgetでもpifを削除できない。 |
- | exec / | + | * この場合、別にNICにManagement Networkを割り当てて(xsconsoleから設定すれば良い)、Management Networkではないように設定する必要がある |
- | ===== End of qemu-dm.sh | + | ===== NetworkのMTUを変更する |
+ | 一般に、通常のInternet通信ならMTUを1500以外に変更する意味はない。Flet' | ||
- | cp /usr/ | + | しかし、LAN内で特にStorageのような通信量が多いNetworkで10G I/Fを使用している場合においては、MTUが1500ではNetwork的に遅くなるし、CPU負荷も(若干だが)上がってしまう。 |
- | chmod 755 / | + | 特にXCP-ngのStorage Network(iSCSIとかNFSを利用しているNetwork)においては、MTUの差は大きく効くことになる。 |
- | chattr +i /usr/ | + | |
+ | しかし、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 | ||
+ | </code> | ||
+ | - 変更したPool内の各Serverの当該PIFを確定し、各serverにおいて以下を実行する | ||
+ | * < | ||
+ | # xe host-management-reconfigure pif-uuid=< | ||
</ | </ | ||
+ | * これを実行しないと、I/ | ||
+ | - これでNetwork、NICともにMTUが変更される。一応pingを打って(可能なら'' | ||
+ | ===== XCP-ngで2TiB以上の大きさのDiskをVMに割り付ける ===== | ||
- | なお、qemu-dm.shは、環境変数に格納されている文字列の文字列置換を行っているので、bash以外で正しく動作する保証が無い | + | XCP-ng(おそらくはXenServerも)は、XCP-ng Console/ |
- | この方法でFV時のNICをe1000として認識させる場合、XenServerのupdate(HotFix)を適用するときに問題が出る場合がある。 | + | しかし、様々な事情により、4TiBのVirtual Diskを持つTimeMachine Backup用のVMを作成したい状況になってしまったので、対応策を以下に記載する。 |
- | これは、chattrを利用してqemu-dmを保護しているからである。従って、HotFix適用の際には、適用前に以下を実施する | + | |
- | < | + | |
- | *** XenServer 6.2まで *** | + | |
- | chattr -i / | + | |
- | *** XenServer | + | ==== 準備 ==== |
- | chattr | + | 今回は、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を駆使して作業する。 | ||
+ | |||
+ | - '' | ||
+ | | ||
+ | - '' | ||
+ | | ||
+ | - '' | ||
+ | | ||
+ | - '' | ||
+ | * 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かを判断するのは実は結構難しい。 | ||
+ | * 個人的には、'' | ||
+ | * '' | ||
+ | * 今回は、'' | ||
+ | | ||
+ | | ||
+ | | ||
+ | * この時、追加した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 | ||
</ | </ | ||
+ | - Pool Masterを再起動 | ||
+ | - Poolを構成するMaster以外のServerを再起動 | ||
+ | |||
+ | ===== XCP-ng 7.4から7.5へのUpgrade ===== | ||
+ | |||
+ | * [[https:// | ||
+ | * 記事執筆時点で、7.6がRelease Candidateになっており、7.5系は7.5.1になっていることに注意。 | ||
+ | * 手順はおそらく変わらないだろうから、記載しておく。 | ||
+ | |||
+ | - まず、対象poolのpool masterにsshなどでloginする | ||
+ | - xsconsoleコマンドを実行する | ||
+ | - '' | ||
+ | - '' | ||
+ | - Root passwordを入力する | ||
+ | - Backupファイルを設置するSRを選択する。今回は '' | ||
+ | - 数分待つ | ||
+ | - QUITする | ||
+ | - 別の手段としてCommandlineから '' | ||
+ | - 以下のコマンドを実行 | ||
+ | * < | ||
+ | wget https:// | ||
+ | yum clean metadata | ||
+ | yum install xcp-ng-deps | ||
+ | yum update | ||
+ | </ | ||
+ | - Pool masterを再起動 | ||
+ | - 以下、Poolに所属している他のServerも同様に更新する | ||
+ | ===== XCP-ng上でのGuest VMのauto power on ===== | ||
+ | - xe pool-list で、pool の uuid をゲット '' | ||
+ | - POOL上の auto startを有効化 '' | ||
+ | - 有効化したい VM でこれを実行 '' | ||
- | この保護を入れる理由は、単純にUpdateされてしまい、qemu-dmが置き換えられてしまうと、NICがrtl8139に認識されるようになってしまうからである。つまり、あえてUpdateを失敗させて、やり直しできるようにするのが目的である。 | ||
===== MetaData Backup ===== | ===== MetaData Backup ===== |
os/xenserver/tips.txt · 最終更新: 2023/10/25 03:06 by seirios