os:xenserver:tips
no way to compare when less than two revisions
差分
このページの2つのバージョン間の差分を表示します。
前のリビジョン次のリビジョン | |||
— | os:xenserver:tips [2019/01/04 02:08] – [XenServer 6.2 以降への Hotfixの適用] seirios | ||
---|---|---|---|
行 1: | 行 1: | ||
+ | ====== XenServer Tips ====== | ||
+ | ===== 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 ===== | ||
+ | |||
+ | * [[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 でこれを実行 '' | ||
+ | <del> | ||
+ | ===== 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 ===== | ||
+ | - xsconsole | ||
+ | - Backup, Restore and Update | ||
+ | - Backup Virtual Machine Metadata | ||
+ | の順でメニューを選べばあとはみたまま。 | ||
+ | |||
+ | ===== Console画面を出す ===== | ||
+ | < | ||
+ | [root@XenServ01 ~] xsconsole | ||
+ | </ | ||
+ | |||
+ | ===== xeでVMのNICをいじる ===== | ||
+ | xeコマンドでVMのNICをいじる為のメモ。 | ||
+ | |||
+ | AMDのブルドーザーコアマシンを使っていて、流石に古くなったので別のIntel XeonマシンにVMを移設した。 | ||
+ | 細かいところは今度まとめるので、テキストでメモ書き | ||
+ | |||
+ | < | ||
+ | xe vif-list ←とにかくvifのlistを取得する | ||
+ | xe vif-param-list uuid=.... ←必要なvifを探す。見つけたら、network-uuid(3)をメモする | ||
+ | xe vm-list name-label=" | ||
+ | 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する | ||
+ | </ | ||
+ | これで、既存のVMに割り当てているNICを置き換える事が出来る。 | ||
+ | |||
+ | ということは、こんな事をすればVMをxeコマンドだけで作れるってことかもしれない | ||
+ | < | ||
+ | 事前に、割り当てたいNetworkのUUID(D)を取得する | ||
+ | xe vm-install new-name-label=" | ||
+ | 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: | ||
+ | xe vm-param-set uuid=(A) PV-args=" | ||
+ | xe vm-param-set uuid=(A) other-config: | ||
+ | ←必要なパラメータをセットする | ||
+ | xe vm-start uuid=(A) ←VMを起動する | ||
+ | xe console uuid=(A) ←VMのConsoleに繋ぐ | ||
+ | </ | ||
+ | あとはpif関連とかパラメータとかを理解すればいいのか。 | ||
+ | |||
+ | ===== MTUを9000にする ===== | ||
+ | * XenServ01のeth1のMTUを9000にする場合 | ||
+ | < | ||
+ | [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: | ||
+ | [root@XenServ01 ~]# | ||
+ | </ | ||
+ | * これで再起動すれば eth1のMTUが9000になる | ||
+ | * MTUを9000にしたものの、Switching HUBがMTU 9000に対応していないということはままあることですが、その時には、以下をどうぞ | ||
+ | < | ||
+ | [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 ~]# | ||
+ | </ | ||
+ | * これでパラメータが消えます。ので、再起動してください。 | ||
+ | * 当然、NFSやiSCSIもMTUを1500にしておくほうがいいですよ。 | ||
+ | * なお、Xenに限らず、iSCSIやNFSを利用するなら、Networkを独立させて、かつJumbo Packetを通せるSwitchにしておくほうが性能が出ます。 | ||
+ | |||
+ | ===== Open vSwitchのメモ ===== | ||
+ | - XenServer(XCP)内のOpen vSwitchの状況を確認する | ||
+ | * '' | ||
+ | * '' | ||
+ | 詳しいことは、これから調査... |
os/xenserver/tips.txt · 最終更新: 2023/10/25 03:10 by 127.0.0.1