構成は次のとおりです。
Ubuntu上のKVMおよびlibvirtを備えたSupermicroハイパーバイザーサーバー。
ゲストは、LVM2を備えたUbuntuです。
チャレンジ:
ゲストOSをオフ/再起動せずにシステムディスクのサイズを増やします。
前の記事へのコメントでhabrahabr.ru/post/252973/#comment_8330673 farcallerは次のように書いています。
システムはその場でサイズ変更することもできます。 このため、libvirtには次のコマンドがあります。
virsh qemu-monitor-command resized-virtual-machine --hmp "block_resize $ DRIVENAME $ NEWSIZE"
HAプロジェクトの場合、これは非常に重要なポイントであり、サービスの継続的な運用が必要です。
virshを使用してディスクのサイズを変更することにしました。
以下は、この成功した実験の結果です。
簡単に言うと、次のようなものでした。
ハイパーバイザー上:
- virshリスト
- virsh qemu-monitor-command vm-db --hmp "info block"
- virsh qemu-monitor-command vm-db --hmp "block_resize drive-virtio-disk0 1000G"
ゲストで:
- df -h
- 別れ/ dev / vda
- 印刷する
- リサイズパート2
- 1000GB
- リサイズパート5
- 1000GB
- q
- pvresize / dev / vda5
- lvscan
- lvextend / dev / vm-db-vg / root -l + 100%無料
- resize2fs / dev / vm-db-vg / root
- df -h
利益!
ハイパーバイザーログ
ルート@ hyp-0:/ローカル#ls ca-1-disk-1.qcow2 vm-db-disk-1.qcow2 root @ hyp-0:/ local#qemu-img info ./vm-db-disk-1.qcow2 イメージ:./vm-db-disk-1.qcow2 ファイル形式:qcow2 仮想サイズ:800G(858993459200バイト) ディスクサイズ:717G cluster_size:65536 特定の情報をフォーマットする: 互換性:1.1 遅延参照:false root @ hyp-0:/ local#virsh list ID名の状態 -------------------------------------------------- - 2 vm-ag-0実行中 3 vm-db実行中 12 vm-ca-1実行中 root @ hyp-0:/ local#virsh qemu-monitor-command vm-db --hmp "info block" drive-virtio-disk0:/local/vm-db-disk-1.qcow2(qcow2) drive-ide0-1-0:[挿入されていません] リムーバブルデバイス:ロックされていない、トレイが閉じている root @ hyp-0:/ local#virsh qemu-monitor-command vm-db --hmp "block_resize drive-virtio-disk0 1000G" root @ hyp-0:/ local#qemu-img info /local/vm-db-disk-1.qcow2 イメージ:/local/vm-db-disk-1.qcow2 ファイル形式:qcow2 仮想サイズ:1.0T(1073741824000バイト) ディスクサイズ:717G cluster_size:65536 特定の情報をフォーマットする: 互換性:1.1 遅延参照:false ルート@ hyp-0:/ローカル#
これがゲストログの表示です
ルート@ vm-db:/var/lib/postgresql/9.1/main# df -h 使用されるファイルシステムサイズAvail Use%Mounted on / dev / mapper / vm-db-vg-root 730G 671G 22G 97%/ なし4.0K 0 4.0K 0%/ sys / fs / cgro udev 29G 4.0K 29G 1%/ dev tmpfs 5.8G 360K 5.8G 1%/実行 なし5.0M 0 5.0M 0%/実行/ロック なし29G 0 29G 0%/実行/ shm なし100M 0 100M 0%/実行/ユーザー / dev / vda1 236M 95M 129M 43%/ブート root @ vm-db:/ sys / block / vda / device#parted / dev / vda GNU Parted 2.3 / dev / vdaを使用する GNU Partedへようこそ! コマンドのリストを表示するには、「help」と入力します。 (別れた)印刷 モデル:Virtio Block Device(virtblk) ディスク/ dev / vda:1074GB セクターサイズ(論理/物理):512B / 512B パーティションテーブル:msdos 番号開始終了サイズタイプファイルシステムフラグ 1 1049kB 256MB 255MBプライマリext2ブート 2 257MB 859GB 859GB拡張 5 257MB 859GB 859GB論理lvm (分割)resizepart 2 終わり? [859GB]? 1000GB (別れた)印刷 モデル:Virtio Block Device(virtblk) ディスク/ dev / vda:1074GB セクターサイズ(論理/物理):512B / 512B パーティションテーブル:msdos 番号開始終了サイズタイプファイルシステムフラグ 1 1049kB 256MB 255MBプライマリext2ブート 2 257MB 1000GB 1000GB拡張 5 257MB 859GB 859GB論理lvm (分割)resizepart 5 終わり? [859GB]? 1000GB (別れた)q ルート@ vm-db:/ sys / block / vda / device#lvscan ファイル記述子7(パイプ:[9143432])がlvscan呼び出しでリークしました。 親PID 5423:bash ACTIVE '/ dev / vm-db-vg / root' [741.17 GiB]継承 ACTIVE '/ dev / vm-db-vg / swap_1' [58.59 GiB]継承 root @ vm-db:/ sys / block / vda / device#lvextend / dev / vm-db-vg / root -l + 100%FREE ファイル記述子7(パイプ:[9143432])がlvextendの呼び出しでリークしました。 親PID 5423:bash 論理ボリュームルートを872.49 GiBに拡張 論理ボリュームルートのサイズ変更に成功しました root @ vm-db:/ sys / block / vda / device#resize2fs / dev / vm-db-vg / root resize2fs 1.42.9(4-Feb-2014) / dev / vm-db-vg / rootのファイルシステムは/にマウントされます; オンラインでサイズ変更が必要 old_desc_blocks = 47、new_desc_blocks = 55 / dev / vm-db-vg / root上のファイルシステムの長さは228718592ブロックになりました。 ルート@ vm-db:/ sys / block / vda / device#df -h 使用されるファイルシステムサイズAvail Use%Mounted on / dev / mapper / vm-db-vg-root 859G 678G 140G 83%/ なし4.0K 0 4.0K 0%/ sys / fs / cgroup udev 29G 4.0K 29G 1%/ dev tmpfs 5.8G 364K 5.8G 1%/実行 なし5.0M 0 5.0M 0%/実行/ロック なし29G 0 29G 0%/実行/ shm なし100M 0 100M 0%/実行/ユーザー / dev / vda1 236M 95M 129M 43%/ブート
ログの数値に不正確さが含まれている可能性があることを警告したいので、それらを復元し、クリーンアップし、ゲストログを2つの仮想マシンから収集しました。
結論として、私は本当に必要な機会のヒントについてfarcallerに感謝します。