私たちの究極の目標は、今後いつでもパーティションのディスク容量を簡単に増やすことです。より多くのスペースが必要なシステムドライブか、/ varのようなものか
ディスクパーティショニングに使用する最良の方法を調べているところで、次の記事を見つけました。 https://docs.microsoft.com/en-us/azure/virtual-machines/linux/configure-lvm
「LVMは仮想マシンに接続されているすべてのディスクに構成できますが、ほとんどのクラウドイメージはデフォルトでオペレーティングシステムディスクにLVMを構成しません。これは、オペレーティングシステムディスクが一度占有されたときの問題を回避するためです。問題同じ展開と種類の異なる仮想マシンに接続する（つまり、回復シナリオ中）、データディスクでのみLVMを使用することをお勧めします。
ただし、システム（非データディスク）でもLVMを使用していない場合はVMコンソールにアクセスできないため、必要に応じてこのディスクパーティションを拡張しますか？
たとえば、最近のオンプレミス環境（Azureではない）には、LVMをまったく使用せずに中間パーティションを拡張する必要があるVMがありました。私たちが見つけた唯一の解決策は、ブートディスクから仮想マシンを起動し、GPARTEDを使用することでした。このオプションは Azure では使用できません。
同じ状況が発生した場合、どのように処理するか、Azure VMで処理するための推奨事項は何ですか? （中間パーティションに余分なスペースが必要な場合はLVMではなくディスク上）、主に将来のこれらの問題を回避するためにLinux VMを構築する方法を計画したいと思います。
ベストアンサー1
同じ状況が発生した場合、どのように処理するか、Azure VMで処理するための推奨事項は何ですか? （中間パーティションに余分なスペースが必要な場合は、LVMではなくディスク上）
検索結果を見ると、Azureはこれを行わないことをお勧めします。
提供されたクラウドイメージは、ディスクの最後にルートパーティションを配置するように見えます。私の考えでは、データパーティションを別々のディスクに置くのがアイデアのようです。
たとえば、このリンクはAzure Marketplaceにこの形式のCentOSイメージを表示し、同じプロセスがUbuntuイメージを使用してテストされたことを示しています。また、fdisk実行中のシステムからオペレーティングシステムのパーティションを削除して再作成して、新しい空き容量を反映できることを説明しています。つまり、GPARTEDディスクから起動する必要はありません。その後、パーティション内のファイルシステムのサイズを変更する前に再起動する必要があります。これを行う他の方法があります。