vSphereのクローンでハマった。 [Linux]
会社でVMware vSphereを仮想環境に使っているのだが、既存の仮想マシンをクローンした時にハマったところを書いておく。
まずCentOS7をクローンしたのだけれど、そのままブートしない。ブートの途中でDracutのプロンプトが出てきてしまい、そこからどうにも進まない感じだ。エラー表示を見てみると、rootディレクトリやswap領域が読み込めていない。dracutのプロンプトもなにか要領を得ない。dracutのコマンドの使い方はあるのだが、いまいちプロンプトの用法がよくわからない。
更にネットワークもnmtuiで用意されたIPアドレスやデフォルトゲートウェイを指定してもSSHが繋がらない。これは今まで散々外部のファイアウォールに苦しめられてきたので、それが元で通らないのだと思っていた。IPはあっている、その他の設定も間違っていない。PINGは通らない。nslookupはきちんとホスト名とIPがあっている。vSphereのWebコンソールから外側を見ようとしても、プロキシを設定しても繋がらない。当然yum関係でソフトウェアの取り寄せもできない。結論を言ってしまうと、クローンしてくれた人がIPがバッティングしないようにNICの接続を止めていてくれていただけだった。なのでvSphereの管理者権限でつながるようになりそう。
ネットワークはまだ良いとして、まともにブートしないのが気持ち悪い。CentOS7はRHEL7にコンバートしてRHEL8にアップグレードするため、事前にSCSIの設定を準仮想化にしてもらっていた。たぶん、ブートしないのはそこなんじゃないかなと思ってはいた。とはいえ、vSphereの管理者は夏休みで動かしてもらえないので、そこはある程度のところまで自分で解決しないといけなかった。
SCSIの設定を元に戻せない状態で、なんとかしようともがいた。
状況的にこれに酷似していたのだが、やはり全く同じではない。しかしvSphereでブートしないというところと、エラーメッセージがほとんど同じだということだ。
https://blog.kamata-net.com/archives/12392.html
そこではインストールディスクのレスキューモードを使っていたが、面倒なのでgrubで選択できるrescue modeにて同じようなことができないか試してみた。そもそもDVDのISOとかでブートするとchrootとか使わないといけないようだから、ディレクトリ操作がややこしくて手に余る。
レスキューモードにするとすんなり立ち上がった。まぁそうだよな。操作性が悪いのでSSHをつなげようとしたけれど、先の制限によってできなかった。SSHがつなげられないと、Webのコマンドのコピペで済むところが、vSphereのコンソールで全部手打ちしないといけない。正直やってられない。
grub2-installなどで再構築してカーネルイメージを指定したり、
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/system_administrators_guide/sec-reinstalling_grub_2
dracutでカーネルイメージを再構築したりしてみたのだが
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/kernel_administration_guide/sec-verifying_the_initial_ram_file_system_image
どうにもうまく行かない。状況は変わらない。そこでSCSIの準仮想化を思い出して、「VMware 準仮想化」とかでググってみました。
https://anything-it.info/vmware-pvscsi-adapter-install/
これはWindowsのものだけれども、準仮想化をするとドライバが必要だよということを言っていて、それに関してはLinuxも変わらないことだと思いました。そもそもドライバがないから読み込めない、と。しかし、そこまで行くまでにHDD読んでんじゃないかよとツッコミを入れたくもなるのだが、それはレスキューモードと同じ理屈で読み込めているのだろうと無理に納得してみる。
そういやVMware ToolsのインストールってWindowsでしかやったことないなと思って改めて調べてみました。vSphereの管理画面でインストールってリンクがあるけど、そこだけじゃISOぶち込むところまでしかやってくれないのね。Windowsではそれでブートしてくれたりするんだったような気がするけど、Linuxではそこそこ作業をしないといけないっぽい。
https://docs.vmware.com/jp/VMware-Tools/12.2.0/com.vmware.vsphere.vmwaretools.doc/GUID-08BB9465-D40A-4E16-9E15-8C016CC8166F.html
あぁCDをマウントするとか面倒くさいな。そこいらの作業はLinuxデスクトップでもしなくなったので、改めてやらされるとワンステップあってしんどさ倍増である。
やったのはこれだけであった（効果のあったものは多分これだけ）。
ググってみると
みたいな表示が結構あるけれど、これはDVDのISOとかでブートした時に必要なのかな？ 普通にローカルでブートできているなら必要のない作業だと思うんだけど、わりとこの作業を書いているところがある。grubの選択肢にrescue modeってあるやん？ みんな使わんの？
ともあれ、VMware Toolsのドライバが入れられたカーネルが立ち上がり無事に危機を脱したのでした。ネットワークがつながっていて、yumが使えればopen-vm-toolを入れてそれで終わりだったのかもしれないけど、今回はネットもつながらないサーバでなんとかしました。というか、今どきネットワークがまともにないと、コマンドを入れ込むのにもコピペできないし、リポジトリからソフトも取れないし、PCで情報をかき集めるしかないんだよね。ちょっとしんどかった。
まずCentOS7をクローンしたのだけれど、そのままブートしない。ブートの途中でDracutのプロンプトが出てきてしまい、そこからどうにも進まない感じだ。エラー表示を見てみると、rootディレクトリやswap領域が読み込めていない。dracutのプロンプトもなにか要領を得ない。dracutのコマンドの使い方はあるのだが、いまいちプロンプトの用法がよくわからない。
更にネットワークもnmtuiで用意されたIPアドレスやデフォルトゲートウェイを指定してもSSHが繋がらない。これは今まで散々外部のファイアウォールに苦しめられてきたので、それが元で通らないのだと思っていた。IPはあっている、その他の設定も間違っていない。PINGは通らない。nslookupはきちんとホスト名とIPがあっている。vSphereのWebコンソールから外側を見ようとしても、プロキシを設定しても繋がらない。当然yum関係でソフトウェアの取り寄せもできない。結論を言ってしまうと、クローンしてくれた人がIPがバッティングしないようにNICの接続を止めていてくれていただけだった。なのでvSphereの管理者権限でつながるようになりそう。
ネットワークはまだ良いとして、まともにブートしないのが気持ち悪い。CentOS7はRHEL7にコンバートしてRHEL8にアップグレードするため、事前にSCSIの設定を準仮想化にしてもらっていた。たぶん、ブートしないのはそこなんじゃないかなと思ってはいた。とはいえ、vSphereの管理者は夏休みで動かしてもらえないので、そこはある程度のところまで自分で解決しないといけなかった。
SCSIの設定を元に戻せない状態で、なんとかしようともがいた。
状況的にこれに酷似していたのだが、やはり全く同じではない。しかしvSphereでブートしないというところと、エラーメッセージがほとんど同じだということだ。
https://blog.kamata-net.com/archives/12392.html
そこではインストールディスクのレスキューモードを使っていたが、面倒なのでgrubで選択できるrescue modeにて同じようなことができないか試してみた。そもそもDVDのISOとかでブートするとchrootとか使わないといけないようだから、ディレクトリ操作がややこしくて手に余る。
レスキューモードにするとすんなり立ち上がった。まぁそうだよな。操作性が悪いのでSSHをつなげようとしたけれど、先の制限によってできなかった。SSHがつなげられないと、Webのコマンドのコピペで済むところが、vSphereのコンソールで全部手打ちしないといけない。正直やってられない。
grub2-installなどで再構築してカーネルイメージを指定したり、
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/system_administrators_guide/sec-reinstalling_grub_2
dracutでカーネルイメージを再構築したりしてみたのだが
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/kernel_administration_guide/sec-verifying_the_initial_ram_file_system_image
どうにもうまく行かない。状況は変わらない。そこでSCSIの準仮想化を思い出して、「VMware 準仮想化」とかでググってみました。
https://anything-it.info/vmware-pvscsi-adapter-install/
これはWindowsのものだけれども、準仮想化をするとドライバが必要だよということを言っていて、それに関してはLinuxも変わらないことだと思いました。そもそもドライバがないから読み込めない、と。しかし、そこまで行くまでにHDD読んでんじゃないかよとツッコミを入れたくもなるのだが、それはレスキューモードと同じ理屈で読み込めているのだろうと無理に納得してみる。
そういやVMware ToolsのインストールってWindowsでしかやったことないなと思って改めて調べてみました。vSphereの管理画面でインストールってリンクがあるけど、そこだけじゃISOぶち込むところまでしかやってくれないのね。Windowsではそれでブートしてくれたりするんだったような気がするけど、Linuxではそこそこ作業をしないといけないっぽい。
https://docs.vmware.com/jp/VMware-Tools/12.2.0/com.vmware.vsphere.vmwaretools.doc/GUID-08BB9465-D40A-4E16-9E15-8C016CC8166F.html
あぁCDをマウントするとか面倒くさいな。そこいらの作業はLinuxデスクトップでもしなくなったので、改めてやらされるとワンステップあってしんどさ倍増である。
やったのはこれだけであった（効果のあったものは多分これだけ）。
grub2-mkconfig -o /boot/grub2/grub.cfg dracut -f /boot/initramfs-使うカーネルの番号.el7.x86_64.img 使うカーネルの番号
ググってみると
mount --bind /proc /mnt/sysimage/proc mount --bind /dev /mnt/sysimage/dev mount --bind /sys /mnt/sysimage/sys chroot /mnt/sysimage/
みたいな表示が結構あるけれど、これはDVDのISOとかでブートした時に必要なのかな？ 普通にローカルでブートできているなら必要のない作業だと思うんだけど、わりとこの作業を書いているところがある。grubの選択肢にrescue modeってあるやん？ みんな使わんの？
ともあれ、VMware Toolsのドライバが入れられたカーネルが立ち上がり無事に危機を脱したのでした。ネットワークがつながっていて、yumが使えればopen-vm-toolを入れてそれで終わりだったのかもしれないけど、今回はネットもつながらないサーバでなんとかしました。というか、今どきネットワークがまともにないと、コマンドを入れ込むのにもコピペできないし、リポジトリからソフトも取れないし、PCで情報をかき集めるしかないんだよね。ちょっとしんどかった。
コメント 0