ちなみに、旧DomUのサービスは、MediaWikiなので、ApacheとMySQL、それとMediaWiki自身の設定と内容を復活させることになるが、ここではその詳細は触れない。
普通に考えれば、
- ディスクイメージを
losetup
で/dev/loop1
などのループバックデバイスに割付け、 kpartx
を使い、ディスクイメージ内のパーティションを/dev/mapper/loop1p1
などに割付け、- それぞれを
mount
で/mnt/old
にマウント
だが、最近のLinuxは、これではうまく行かない。それはLVM(Logical Volume Management)を採用しているからだ。パーティションが直接ext3などでフォーマットしてあれば上の手順でOKなのだが、LVMで構成されている場合には、論理ボリュームを認識させる必要がある。これは、
vgscan
を使って、/dev
以下のブロックデバイス(この中には、当然/dev/mapper
以下のデバイスも含まれる)を探索し、認識させることができる。さらに、Dom0もDomUもLVMで構成されていると、デフォルトボリュームグループ名であるVolGroup00が旧DomUのディスクイメージと、Dom0の物理ディスクとの間で衝突してしまうため、旧DomUのボリュームグループがDom0側で認識できない。正確には、不整合(inconsistent)が発生した、と言うようなメッセージが表示される。これを回避するためには、ボリュームグループ名を
vgrename
で名前を変更すればいいのだが、一旦論理グループ名を認識させないことには、名前を変更することもできない。で、解決編。Xenを使っているのが前提であるので、一旦、サルベージ用のDomUを作成する。これは、LVMを使用しないものを作る。具体的には、インストールの際に、デフォルトでは、VolGroup00にLogVol00、LogVol01が作られ、それぞれ
/
(ルート)とスワップ(swap)に割り当てられているが、これをVolGroup00ごと削除し、新たに二つパーティションを作って、それぞれ/
とスワップに割り当て直す。正常に起動するサルベージ用DomUが作成できたら、この設定ファイルを以下のように編集し、旧DomUのディスクイメージを、
/dev/xvdb
に割り当てる。name = "rescue"サルベージ用DomUを起動し、
memory = "64"
disk = [ 'file:/var/xen/rescue.img,xvda,w','file:/var/xen/DomU-old.img,xvdb,w' ]
<<以下略>>
vgscan
を実行すれば、VolGroup00が認識される。[root@rescue ~]# vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
[root@rescue ~]#
ここでこのままサルベージ作業に入ってもいいのだが、折角だから、新DomUにマウントできるよう
vgrename
コマンドを使ってボリュームグループ名を変更する。[root@rescue ~]# vgchange -an VolGroup00そうして、新DomUの設定ファイルをサルベージ用DomUの設定ファイルと同様に編集し、新DomUを起動すれば、新DomUから旧DomUのディスクが認識される。これを
0 logical volume(s) in volume group "VolGroup00" now active
[root@rescue ~]# vgrename VolGroup00 VolGroup00-old
Volume group "VolGroup00" successfully renamed to "VolGroup00-old"
[root@rescue ~]#
mount
コマンドでマウントすれば、無事旧DomUと設定と内容をサルベージできる、というわけだ。物理ハードディスクからサルベージするときにもこれと同じ手法が使える。サルベージ元ディスクと、サルベージ先システムのボリュームグループ名は普通、同一になるので、普通にはマウントできない。このとき、Xenを使ってサルベージ元ディスクのボリュームグループ名を変更して、マウントすることが可能になる。
0 件のコメント:
コメントを投稿