私は現在LinodeのXenサーバーの1つにあるlinodeを持っています。 KVM linodeにアップグレードする資格があることがわかりました。
私が懸念していることの1つは、Linodeのアップグレードガイドでは、ブロックデバイスが/dev/xvda
命名スキームから/dev/sda
命名スキームに変更されると述べていることです。
私の/etc/fstab
は:
proc /proc proc defaults 0 0
/dev/xvda / ext3 noatime,errors=remount-ro 0 1
/dev/xvdb none swap sw 0 0
ですから、アップグレードと合わせて何らかの方法で変更する必要があると思います。
シャットダウンしてアップグレードする前に、/dev/xvda
および/dev/xvdb
エントリを/dev/sda
および/dev/sdb
に編集する必要がありますか?
デバイスを宣言するUUID=
スタイルに切り替える必要がありますか? (私が考えた今、デバイスのUUIDは同じままでしょうか?)
私はLinodeでサポートチケットを開きました、そして彼らが言ったのは「アップグレードする前にあなたの設定プロファイルでDistro Helperをオンにしてください、そしてそれはそれを処理するはずです」でした。どちらがそうならない可能性を残しているので、私は積極的に既知の良いことをしたいと思います。
関連して、管理UIの構成プロファイルの「ルートデバイス」オプション(/dev/xvdN
オプションを提供するドロップダウン)は、/dev/xvda
を/dev/sda
などに正しくマップすると思います。アップグレードするとき?
全体として、この問題(および私が知らない他の問題)がどのように解決されるかを確認するために、Xen-> KVMへの移行を行った人々からの意見を聞きたいと思います。
ハードウェアを大幅に変更した後(この場合は仮想ハードウェア、XenからKVM)、デバイス名またはIDがどうなるかを予測する方法はありません。 Linodeは、何が変わるのか、アップグレードした場合にどのように進めるべきかを知っている唯一のエンティティです。
そうは言っても、これをしないでください。あなたは自分自身に停止を強いています。それが壊れた場合、彼らがあなたの問題を解決するまで、あなたは彼らと一緒にサポートチケットになります。運が良ければ、時間のロスだけで、データのロスはありません。 「既知の良いこと」は、Linodeサーバーのデータと構成をバックアップし、新しいKVMインスタンスを立ち上げ、データとサービスを新しいホストに移行することです。これができない場合は、構成管理ソフトウェアを使用して1時間、あなたは火遊びをしています。さらに、あなたは専門家向けサイトの専門家なので、構成管理が存在しない状態でサーバーを実行しているのは一体何ですか?