他の誰かのXENホスティングからKVMに仮想マシンを転送した経験

私のタスクは、外部ホスティングからクライアントサーバーにサイトを転送することでした。 その特徴は、仮想サーバーが適切に構成されており、実際にオペレーティングシステム、データベース、およびすべての環境パッケージを再インストールして構成することを望まなかったことです。



このサイトは、XENハイパーバイザーを備えた仮想マシン上の有名プロバイダーのクラウドでスピンしていました。 サポートが仮想マシンのイメージを満たし、提供することを望んでいましたが、奇跡は起こりませんでした。おそらく通常どおり、失敗は冷たくて丁寧でした。 その結果、おおよその転送スキームが生まれました。ディスクイメージを作成し、それをサーバーに転送し、仮想マシンを自分で作成し、結果のイメージをソースとして示します。



経験豊富な専門家は、計画を実施する過程で私が直面しなければならなかったことをすでに推測しています。 残りについては、生じた困難を解決するための詳細と方法を示します。



1.サーバーに接続します



このディスク自体にディスクイメージを作成するのはかなり面倒なので、使用しているファイルシステムとは異なるファイルシステムを接続する必要がありました。 最初に思いついたのは、sshfsを使用して、仮想マシン上のファイルシステムにサーバーのホームフォルダーをマウントすることでした。 Debianディストリビューションのコマンドは次のとおりです。



 #apt-get sshfsをインストール
 #mkdir / mnt / vasya
 #sshfs vasya@pupkin.ru:/ home / vasya / mnt / vasya
パスワード:2014 Cheburashka




2. FSを読み取り専用に転送します



ファイルシステムの整合性が失われないようにするには、ファイルシステムを読み取り専用保護モードにする必要がありました。 これを行うために、LinuxにはFSを再マウントする機能があります: mount -o ro,remount /



コマンドは自然に機能しませんでした。カーネルは、 mount: / is busy



エラーでコマンドの実行をブロックしました。 いくつかのグーグルの後、多くのファイルがデーモンによって開かれたという理由がありました。 サーバーでntp、apache2、mysql、rsyslogdを停止する必要がありました(何か見落としていたかもしれませんが、htopまたはtopコマンドで実行中のプロセスのリストを表示できます)。



 #invoke-rc.d ntp stop
 #invoke-rc.d apache2 stop
 #invoke-rc.d mysql stop
 #invoke-rc.d rsyslogd stop
 #mount -o ro、再マウント/
 #タッチ/テスト
 touch: `/ test 'にタッチできません:読み取り専用ファイルシステム




3.イメージの作成と転送



ddプログラムを使用してイメージを作成しました。 また、データパイプラインを使用し、gzip圧縮プログラムを介して、リモートサーバーにマウントされているフォルダーにあるファイルに送信しました。



 #dd if = / dev / xvda bs = 64K |  gzip -c> /mnt/vasya/xvda.raw.gz




1時間半後、サーバー上に必要な画像を含むファイル/home/vasya/xvda.raw.gzがありました。 圧縮率は悪くありませんでした:8.5 / 12。



4.イメージを新しい仮想マシンに接続する



ローカルハードウェアでは、Proxmox VE 3.1を使用します。 次の構成で仮想マシンを作成しました。



バルーン:256
ブートディスク:virtio0
コア:2
 ide2:nfs-da:iso / debian-7.2.0-amd64-netinst.iso、メディア= cdrom、サイズ= 222M
メモリ:768
名前:パプキン
 net0:virtio = 26:95:81:17:D9:14、bridge = vmbr0
 ostype:l26
ソケット:1
 virtio0:nfs-da:143 / vm-143-disk-1.raw、フォーマット= raw




もちろん、仮想マシンのイメージファイルを解凍し、必要なアクセス権で適切な場所に配置します(/ mnt / nfsはProxmox VEストレージとして構成されたセクション、143は新しい仮想マシンの識別子です)。



 #zcat /home/vasya/xvda.raw.gz> /mnt/nfs/images/143/vm-143-disk-1.raw
 #chown nobody:nogroup /mnt/nfs/images/143/vm-143-disk-1.raw




私は経験不足で、勝利を楽しみにしていましたが、そこにはありませんでした。Grubブートローダーが私のコンソールに落ちました。 さらに、手動で起動しようとすると失敗する運命にありました。結果のイメージにはinitrd環境初期化子がなく、カーネルは高度に特殊化されており、virtioデバイス(ネットワークおよびハードドライブ)のドライバーが含まれていませんでした。 経験豊富なスペシャリストが私を補足し、XEN環境でのLinuxブートの構成方法を説明できます。気にしませんでした。すでに新しい計画を立てていました。



5.ブートローダーの修正



動作中の仮想マシンがあり、それに新しいディスクを追加し、そのイメージをファイルシステムから削除し、壊れたイメージのシンボリックリンクに置き換えました。 以前はもちろん、仮想143をオフにして、2つのプロセスが誤って同時にイメージを開かないようにしました。



 #rm /mnt/nfs/images/200/vm-200-disk-2.raw
 #ln -s /mnt/nfs/images/143/vm-143-disk-1.raw /mnt/nfs/images/200/vm-200-disk-2.raw




仮想マシン200をダウンロードし、破損したイメージのFSをマウントし、そこにLinuxカーネル、動作中のブートローダー、およびデバイスドライバーをコピーしました。



 #mkdir / mnt / vdb1
 #mount / dev / vdb1 / mnt / vdb1
 #cp /boot/vmlinuz-3.2.0-4-amd64 /mnt/vdb1/boot/vmlinuz-3.2.0-4-amd64 
 #cp /boot/initrd.img-3.2.0-4-amd64 /mnt/vdb1/boot/initrd.img-3.2.0-4-amd64
 #cp /boot/System.map-3.2.0-4-amd64 /mnt/vdb1/boot/System.map-3.2.0-4-amd64
 #cp -r /lib/modules/3.2.0-4-amd64 / mnt / vdb1 / lib / modules




200をオフにし、143をオンにして、Grubの手動ブートコマンドを入力しました。



 grub> root(hd0、msdos1)
 grub> linux /boot/vmlinuz-3.2.0-4-amd64 root = / dev / vda1
 grub> initrd /boot/initrd.img-3.2.0-4-amd64
 grub>ブート




システムが起動し、mysqlとapache2を正常に起動しました。 もちろん、 /etc/network/interfaces



を修正して、システムがローカルネットワークに移動し、ルーターおよびインターネットと通信できるようにしなければなりませんでした。



完全に動作するマシンでは、これ以上問題はありませんでした。ブートローダーを完全に真っ直ぐにしてdebian-wayに従うために、grubインストールを起動し、リポジトリからLinuxカーネルをインストールしました。



 #grub-install / dev / vda
 #apt-get update
 #apt-get install linux-image-2.6.32-5-486
 #再起動




おわりに



すべての操作の結果、元の仮想マシンとほぼ同じ仮想マシンを手に入れましたが、KVMハイパーバイザーを備えたProxmox VE環境で動作し、特別なブートローダーは不要です。 イメージは、VMware ESXクラスターで開始するためにクライアントに転送される予定です。



All Articles