Johan Burati’s Blog

Linuxリカバリ：FSTABエラーのためにLinux VMにSSHできません。

Johan_Burati — Mon, 25 Dec 2017 17:06:52 GMT

fstabの構文が正しくない場合、およびデータディスクが欠落している（VMに接続されていない）場合やその他の理由で、VMが正常に起動しなくなることがあります。 Linuxでは、通常、fstabで次のフォーマットを使用してscsiデバイスをマウントできます。 / dev / sdc1 / data ext4デフォルト0 0 しかし、クラウド環境では毎回同じscsi IDを保証する方法がないため、UUIDを使用して確実にディスクをマウントすることが最善の方法です。フォーマットは次のように近いでしょう。 UUID = "8be9efc9-61e7-4cc7-806s6-2d014745ae99" / data ext4デフォルト0 0 Linux VMにデータディスクを正しく追加する方法の詳細については、次の記事を参照してください。 Linux仮想マシンにデータディスクを接続する方法ブートしていないLinux VMからブート診断を調べた後、 V 仮想マシン> VMNAME>すべての設定>ブート診断 以下の4つの例に似たメッセージが表示されます。 （1）UUIDの代わりにscsi idでマウントされていたディスクの例： [K [[1; 31m TIME [0m]デバイスdev-incorrect.deviceを待ってタイムアウトしました。 [[1; 33mDEPEND [0m] / dataの依存関係が失敗しました。 [[1; 33mDEPEND [0m]ローカルファイルシステムの依存関係が失敗しました。 ... 緊急モードへようこそ！ログイン後、 "journalctl -xb"をビューシステムのログに、 "systemctl reboot"を再起動する、 "systemctl default"を入力してデフォルトモードに再起動します。保守のためのrootパスワードを与える（またはControl + Dキーを押して続行します）。 （2）CentOS上のデバイスが見つからない場合の例 ファイルシステムのチェック中... util-linuxからのfsck 2.19.1 すべてのファイルシステムをチェックしています。 / dev / sdc1：存在しないデバイス（このデバイスをスキップするために "nofail" fstabオプションを使用することができます） / dev / sdd1：存在しないデバイス（このデバイスをスキップするために "nofail" fstabオプションを使用することができます） / dev / sde1：存在しないデバイス（このデバイスをスキップするために "nofail" fstabオプションを使用することができます） [/sbin/fsck.ext3（1） - / CODE] sck.ext3 -a / dev / sdc1 fsck.ext3：/ dev / sdc1を開こうとしている間、そのようなファイルやディレクトリはありません / dev / sdc1：スーパーブロックを読み取ることができなかったか、正しいext2を記述していませんファイルシステム。デバイスが有効で、本当にext2が含まれている場合ファイルシステム（スワップやufsなど）ではなく、スーパーブロック壊れていて、代わりのスーパーブロックでe2fsckを実行しようとするかもしれません： e2fsck -b 8193 [/sbin/fsck.xfs（1） - / GLUSTERDISK] fsck.xfs -a / dev / sdd1 /sbin/fsck.xfs：/ dev / sdd1は存在しません。 [/sbin/fsck.ext3（1） - / DATATEMP] fsck.ext3 -a / dev / sde1 fsck.ext3：/ dev / sde1を開こうとしているときにそのようなファイルやディレクトリがありません （3）fstabの設定ミスやVMがもはやVMに接続されていないためにVMが起動できないことを示す例 / var / lib / mysqlのディスクドライブがまだ準備されていないか、存在しません。待つか、Sキーを押してマウントをスキップするか、Mキーを押して手動リカバリを実行します （4）不正なUUIDを示すシリアルログの例 ファイルシステムの確認すべてのファイルシステムをチェックしています。 [/sbin/fsck.ext4（1） - /] fsck.ext4 -a / dev / sda1 / dev / sda1：クリーン、70442/1905008ファイル、800094/7608064ブロック [/sbin/fsck.ext4（1） - / datadrive] fsck.ext4 -a UUID = "85171d07-215e-4fc7-a50a-bf09c7f2d2d9" fsck.ext4： 'UUID = "85171d07-215e-4fc7-a50a-bf09c7f2d2d9"を解決できません [FAILED ***ファイルシステムチェック中にエラーが発生しました。 ***あなたをシェルに落とす。システムが再起動します。 ***あなたがシェルを離れるとき。 ***警告 - SELinuxはアクティブです ***システム回復のためのセキュリティ実施を無効にする。 *** 'setenforce 1'を実行して再び有効にします。タイプ= 1404監査（1428047455.949：4）：強制= 0 old_enforcing = 1 auid = 4294967295 ses = 4294967295 保守のためのrootパスワードを与える（またはControl + Dキーを押して続行します）。 VMを通常の状態に戻すには、アクセスできないVMを削除し、OSDiskを保持し、アクセスできないVMと同じLinuxディストリビューションとバージョンを使用して新しいリカバリVMを配備する必要があります。注：回復プロセスの手順を実行する前に、アクセスできないVMからVHDのバックアップを作成することを強くお勧めします。https://storageexplorer.com で入手可能なMicrosoft Storage Explorerを使用してVHDのバックアップを作成できます。手順は以下のとおりです。 A =元のVM（アクセスできないVM） B =新しいVM（新しいリカバリVM）

Azure Portal経由でVM Aを停止する
Resource Manager VMでは、削除する前に現在のVM情報を保存することをお勧めします
- Azure CLI： azure vm show ResourceGroupName LinuxVmName> ORIGINAL_VM.txt
- Azure PowerShell： Get-AzureRmVM -ResourceGroupName $ rgName -Name $ vmName
VMを削除するが、「 接続されたディスクを保持する」を選択する注：アタッチされたディスクを保持するオプションは、従来のデプロイメントでのみ使用できます。リソースマネージャでは、VMを削除するとデフォルトでOSDiskが常に保持されます。
リースがクリアされたら、Azureポータル、仮想マシン、「 B 」、「 ディスクの接続 」を介して、 AからVM Bにデータディスクを接続します
VM " B "では、最終的にディスクが接続され、マウントすることができます。
VM " B "のマウントするドライブ名を探してください。それぞれのLinuxは少し異なります。
- grep SCSI /var/log/kern.log（ubuntu、debian ） grep SCSI / var / log / messages （centos、suse、oracle、redhat）
マウントされたディスクをmountpoint / rescueにマウントするdf -h mkdir /レスキューRed Hat 7.2+の場合 mount -o nouuid / dev / sdc2 / rescue CentOS 7.2以降 mount -o nouuid / dev / sdc1 / rescue Debian 8.2+、Ubuntu 16.04+、SUSE 12 SP4 + mount / dev / sdc1 / rescue
元のOSディスクが存在する/ etcディレクトリに移動する
- cd / rescue / etc / cp fstab fstab_orig
fstabのバックアップを作成したので、viやnano、お気に入りのテキストエディタを使って必要な変更を進めることができます。行の先頭に＃を付けてコメントアウトすることもできます。
- vi fstab cd / umount / rescue
Azureポータル経由でVM Bからディスクを切り離す
修復されたVHDから元のVM Aを再作成する

クラシックVMの場合：オリジナルのVM A （ ギャラリーを作成し、[ マイディスクを選択]）を再作成すると、VM Aを参照するディスクが表示されます。元のクラウドサービス名を選択します。 Resource Manager VMの場合、PowershellまたはAzure CLIツールを使用する必要があります。以下の記事では、元のVHDからVMを再作成する手順を示しています。

xRDPをGUIリモートアクセス用にLinuxにインストールする方法

Johan_Burati — Mon, 18 Dec 2017 16:10:20 GMT

Azure上のLinux VMに、リモートデスクトップまたは同様のツールを使用してGUIを使用してアクセスしたいとします。

サードパーティのツールのインストールと設定はAzure Linuxのサポートの対象外ですが、必要に応じてxRDPを有効にするための注意点とベストプラクティスがあります。

他のツールでも同様の結果を得るための他の方法があります。具体的にはxRDPについて説明します。

xRDPで標準構成を使用する場合、エンドポイント（クラシック）またはネットワークセキュリティグループ（リソースマネージャー）を使用して開く必要があるポートは、Microsoft Windowsリモートアクセスで使用される3389 TCPになります。

xRDPを有効にする際にはセキュリティ上の注意がいくつかありますが、この記事の最後にいくつかのベストプラクティスを取り上げます。

xRDPをインストールする手順を以下に示します。

Ubuntu / Debianの場合： sudo -i apt-get update apt-get install xrdp

Red Hat、CentOS、Oracleの場合： サードパーティのリポジトリ（EPEL）をインストールする必要がありますが、通常はベンダーによってサポートされていませんが、ここで詳細を見つけることができます： https://fedoraproject.org/wiki/EPEL

特定のバージョン（6.x / 7.x）用のものをインストールしてください。

リポジトリが正常にインストールされたら、以下の手順に進むことができます。

Red Hat / CentOSおよびOracleバージョン7.x： sudo -i yum install xrdp tigervnc-server xterm systemctl enable xrdp systemctl enable xrdp-sesman

Red Hat / CentOSとOracleバージョン6.x sudo -i yum install xrdp tigervnc-server xterm サービスxrdp restart chkconfig xrdp on

xRDPを使用して接続し、xtermを開いたら、xclockを試すなど、必要なグラフィカルアプリケーションをテストすることができます。

セキュリティを向上させるためのベストプラクティス

A）SSHローカルトンネルを使用して余分なポートを開き、トラフィックを暗号化しないようにします。 SSH経由でxRDPアクセスをトンネリングすることで、すべてのトラフィックを暗号化するだけでなく、Linux VMとAzureネットワークトポロジで余分なポートを開くことも回避でき、xRDPデーモンは基本的にLinux VMのAzureのlocalhostインターフェースを聞くことができます。より安全なxRDP環境を設定するための基本的な手順は次のとおりです。 1）/etc/xrdp/xrdp.iniを編集し、以下を変更/追加してデーモンに127.0.0.1を聞かせ、さらに高い暗号化レベルを使用させます。 [グローバル] ビットマップ_キャッシュ=はい bitmap_ compression = yes ポート= 3389 crypt _level = high channel_code = 1 max_bpp = 24 ＃黒= 000000 ＃gray = d6d3ce ＃dark_grey = 808080 ＃青色= 08246b ＃dark_blue = 08246b ＃white = ffffff ＃red = ff0000 ＃緑= 00ff00 ＃background = 626c72 住所= 127.0.0.1 注記：デーモンを127.0.0.1に変更すると、SSHトンネルを実行するだけでアクセスできます。これは、以下の手順で行うことができます。 OSXおよびLinuxユーザの場合は、ターミナルウィンドウで実行できます。 ssh -N -p 22 USER @ VM _PUBLIC_ IP -L 3389：127.0.0.1：3389 上記の例では、基本的にローカルポート3389（ワークステーション/ラップトップ上）を使用し、Azure上のLinux VMへのトラフィックをポート3389上のlocalhostにトンネリングするので、xRDPを使用してVMに接続するには、あなたのワークステーションはポート3389に接続され、Azure上でVMに自動的にトンネリングされます。

一般にGUIはセキュリティ上の理由からLinuxサーバーではデフォルトで無効になっています。この種のアクセスを有効にする必要がある場合は、追加のポートを開く必要がないようにSSHキーとローカルトンネルを使用することを強くお勧めしますLinux VMに転送します。

Linuxのリカバリ：SSHデーモンが正しく起動していない

Johan_Burati — Mon, 11 Dec 2017 16:00:36 GMT

あなたは、Linux VMへのSSH接続を失ったことに気付きました。そして、ブート診断を調べた後、SSHD設定のエラーに関するメッセージが表示されます。無効な設定に関するエラーは単純に次のようなものです。 sshdの起動：[FAILED] SUSEとRed Hatにはいくつかのインスタンスがあり、権限の問題のためにエラーが表示されています。 SUSE： / var / lib / emptyはrootが所有し、グループやworld-writableは所有していなければなりません。 startproc：/ usr / sbin / sshdの親の終了ステータス：255 失敗 Red Hat： sshd：/ var / empty / sshdを起動するには、rootが所有していて、グループまたはworld-writableでなければなりません。 問題が構成上の問題であり、上記のようなアクセス権の問題ではない場合（別の記事で説明します）、SSHDの設定をデフォルトにリセットする問題を解決する方法がいくつかあります。 A）ClassicおよびResource Manager VMを使用する場合、SSHD設定をリセットできるオプションがポータルにあります。 クラシックVMの場合 仮想マシン（クラシック）> VMNAME> [概要]タブで[詳細]をクリックし、[リモートアクセスのリセット]をクリックします。次に[はい]をクリックして続行します。 リソースマネージャVMの場合 仮想マシン> VMNAME>パスワードのリセットを選択すると、使用可能なオプションが表示されます。問題に対してより適切なオプションを選択します。この場合は、「構成のリセットのみ」を選択します。 B） Azure CLIがインストールされている場合は、次の方法でSSHD設定ファイルをリセットすることもできます。 クラシックVMの場合 ＃このコンテンツを持つPrivateConf.jsonファイルを作成します： {"reset_ssh"： "True"} 次のコマンドはazure cliでログインし、configをasm（Classic）に設定してSSHD設定をリセットします。紺碧のログイン紺碧の設定モードasm azure vm拡張セット VMAccessForLinux Microsoft.OSTCExtensions 1. * -private-config-path PrivateConf.json 注記： Azure cliコマンドを実行しているフォルダと同じフォルダにPrivateConf.jsonファイルを作成するか、絶対パスを指定してください。 リソースマネージャVMの場合 紺碧のログイン紺碧の設定モードアーム azure vm reset-access -r

sysstatによるLinux VMの使用状況の監視

Johan_Burati — Mon, 04 Dec 2017 16:38:37 GMT

Sysstatは、パフォーマンスとディスクストレージを犠牲にすることなくシステム監視を可能にする非常に興味深いオプションです。いくつかのディストリビューションはインストールされていますが、デフォルトではディセーブルになっています。この記事で説明する手順を実行することで、sysstatを起動して実行することができ、パフォーマンスに関する問題が発生した場合に分析する履歴データを持つことができます。 Sysstatのインストール Debian / Ubuntu sudo apt-get sysstatをインストールする Redhat / CentOS / Oracle sudo yum install sysstat 統計収集を有効にする Debian / Ubuntu sudo vi / etc / default / sysstat ENABLED = "false"をENABLED = "true"に変更します。 Redhat / CentOS / Oracle sysstatは通常デフォルトで有効になっているため、特別な手順は必要ありません収集間隔を10分ごとから2分ごとに変更する sudo vi /etc/cron.d/sysstat デフォルトでは、次の設定が表示されます。 Debian / Ubuntu 5-55 / 10 * * * * rootコマンド-v debian -sa1> / dev / null && debian -sa1 1 1 Redhat / CentOS / Oracle * / 10 * * * * root / usr / lib64 / sa / sa1 1 1 2分ごとにデータを収集するように設定するには、次のように変更します。 Debian / Ubuntu * / 2 * * * * rootコマンド-v debian -sa1> / dev / null && debian-sa1 1 1 Redhat / CentOS / Oracle * / 2 * * * * root / usr / lib64 / sa / sa1 1 1 sysstatの再起動 Debian / Ubuntu sudoサービスsysstat restart Redhat / CentOS / Oracle sudo systemctl restart sysstatまたはsudoサービスsysstat restart

RHEL 6.8仮想マシンでProxy を経由してAzure Backup 実行に必要な事前作業

Johan_Burati — Fri, 01 Dec 2017 15:36:21 GMT

RHEL 6.8仮想マシンでProxy を経由してAzure Backup 実行に必要な事前作業配下の通りです。 1. yum,wget,waagentの proxy 設定 2. python2.6.6 から 2.7.11 にアップデート 3. yum の修正 4. pip のインストール 5. WALinuxAgent-2.2.18 のインストール以下、各手順の詳細でございます。 1. yum,wget,waagentの proxy 設定 ■/etc/yum.conf proxy=https://:<ポート番号> ■/etc/wgetrc https_proxy=https://:<ポート番号> ■/etc/waagent.conf HttpProxy.Host= HttpProxy.Port=<ポート番号>

■/etc/environment

export http_proxy=https://:<ポート番号>

export https_proxy=https://:<ポート番号>

2. python2.6.6 から 2.7.11 にアップデート $ sudo -i # wget https://www.python.org/ftp/python/2.7.11/Python-2.7.11.tgz # tar xzf Python-2.7.11.tgz # cd Python-2.7.11 # yum install -y gcc zlib-devel openssl-devel # ./configure --with-threads --enable-shared # make && make altinstall # ln -s /usr/local/lib/libpython2.7.so.1.0 /usr/lib64/libpython2.7.so.1.0 # ln -sf /usr/local/bin/python2.7 /usr/bin/python # python -V Python 2.7.11 3. yum の修正 # sed -i '1c#!/usr/bin/python2.6' /usr/bin/yum 4. pip のインストール # wget https://bootstrap.pypa.io/get-pip.py # python get-pip.py 5. WALinuxAgent-2.2.18 のインストール # service waagent stop # wget https://github.com/Azure/WALinuxAgent/archive/v2.2.18.zip # unzip v2.2.18.zip # cd WALinuxAgent-2.2.18/ # python setup.py install # service waagent start # waagent --version WALinuxAgent-2.2.18 running on redhat 6.8 Python: 2.7.11 Goal state agent: 2.2.18

Linuxのリカバリ：カーネルの問題に関連するブート以外の問題の手動修正

Johan_Burati — Mon, 20 Nov 2017 16:53:44 GMT

カーネルのアップグレードなどカーネルの変更が最近適用されたLinux VMがあり、起動プロセス中のカーネルエラーのために適切に起動しなくなりました。カーネルのメッセージはさまざまです。いくつかの例があります：

ルートデバイスが見つかりませんでした。
カーネルのタイムアウト、
ヌルポインタ、
カーネルパニックエラー。

ほとんどの場合、リカバリ手順は類似しているため、新しいカーネルをインストールするか、以前のバージョンに手動でロールバックする必要があります。 あなたが見ることができるエラーメッセージの例 A）ルートデバイスが見つかりません dracut警告：ルートデバイスがありません "ブロック：/ dev / disk / by-uuid / 6d089360-3e14-401d-91d0-378f3fd09332"が見つかりました dracut警告：ブートに失敗しました。この問題をデバッグするには、カーネルコマンドラインに "rdshell"を追加します。 dracut警告：シグナルが検出されました！カーネルパニック - 同期していない：initを強制終了しようとしました！ Pid：1、通信：init汚れていない2.6.32-504.12.2.el6.x86_64＃1 コールトレース： []？パニック+ 0xa7 / 0x16f []？ do_exit + 0x862 / 0x870 []？ fput + 0x25 / 0x30 []？ do_group_exit + 0x58 / 0xd0 []？ sys_exit_group + 0x17 / 0x20 []？ system_call_fastpath + 0x16 / 0x1b B）カーネルタイムアウトエラーの例 情報：タスクスワッパー：1は120秒以上ブロックされました。汚染されていない2.6.32-504.8.1.el6.x86_64＃1 "echo 0> / proc / sys / kernel / hung_task_timeout_secs"はこのメッセージを無効にします。スワッパD 0000000000000000 0 1 0 0x00000000 ffff88010f64fde0 0000000000000046 ffff88010f64fd50 ffffffff81074f95 0000000000005c2f ffffffff8100bb8e ffff88010f64fe50 0000000000100000 0000000000000002 00000000fffb73e0 ffff88010f64dab8 ffff88010f64ffd8 コールトレース： []？ __call_console_drivers + 0x75 / 0x90 []ですか？ apic_timer_interrupt + 0xe / 0x20 []ですか？ vprintk + 0x251 / 0x560 [] schedule_timeout + 0x192 / 0x2e0 []？ process_timeout + 0x0 / 0x10 [] schedule_timeout_uninterruptible + 0x1e / 0x20 [] msleep + 0x20 / 0x30 [] prepare_namespace + 0x30 / 0x1a9 [] kernel_init + 0x2e1 / 0x2f7 [] child_rip + 0xa / 0x20 []？ kernel_init + 0x0 / 0x2f7 []？ child_rip + 0x0 / 0x20 C）カーネルのヌルポイントエラーの例 Pid：242、通信：非同期/ 1汚染されていない2.6.32-504.12.2.el6.x86_64＃1 コールトレース： []？ kmem_cache_create + 0x538 / 0x5a0 []？ mutex_lock + 0x1e / 0x50 []？ attribute_container_add_device + 0x104 / 0x150 []？ storvsc_device_alloc + 0x4e / 0xa0 [hv_storvsc] []？ scsi_alloc_sdev + 0x1fc / 0x280 []？ scsi_probe_and_add_lun + 0x4d9 / 0xe10 []？ kobject_set_name_vargs + 0x6d / 0x70 []？ mutex_lock + 0x1e / 0x50 []？ attribute_container_add_device + 0x104 / 0x150 []？ get_device + 0x19 / 0x20 []？ scsi_alloc_target + 0x2d0 / 0x300 []？ __scsi_scan_target + 0x121 / 0x740 []？ scsi_scan_channel + 0x87 / 0xb0 []？ scsi_scan_host_selected + 0xb0 / 0x190 []？ do_scsi_scan_host + 0x91 / 0xa0 []？ do_scan_async + 0x1c / 0x150 []ですか？ async_thread + 0x116 / 0x2e0 []？ default_wake_function + 0x0 / 0x20 []？ async_thread + 0x0 / 0x2e0 []？ kthread + 0x9e / 0xc0 []？ child_rip + 0xa / 0x20 []？ kthread + 0x0 / 0xc0 []？ child_rip + 0x0 / 0x20 BUG：0000000000000008でカーネルNULLポインターdereferenceを処理することができません。 IP：[] storvsc_device_destroy + 0x20 / 0x50 [hv_storvsc] PGD 0 D）カーネルパニックエラーの例 無効なオペコード：0000 [＃2] [11427.908676] - 終了トレース61a458bb863d7f0f] - カーネルパニック - 同期していない：アイドルタスクを強制終了しようとしました！ これらの問題からの回復 どのような場合でも、影響を受けるLinux VMを削除し、そのOSDディスクを保持し、影響を受けたVMと同じバージョンを実行する新しいVMにマウントするか、少なくとも同じ配分にしてから、問題に応じて下記の2つの修理オプションがあります。 1）設定ファイルを編集してカーネルをロールバックし、以前の動作設定から起動するだけで、Linuxブートローダは通常、ブートに使用するカーネルを定義する複数のエントリを持ちます。新しいインストールされたカーネル 2）影響を与えるVM OSDiskを一時的な新しいVMに接続し、既知のツール（apt-get / yum / zypper）を実行してカーネルをインストール/再インストールすることで、CHROOTプロセスを実行します。これは、手動でファイルを編集する必要がないので、修復するのが最も簡単で通常は最も速い方法です。たとえば、CentOS 6.6を実行しているLinux VMは2.6.32-504.16.2.el6.x86_64のカーネル・バージョンをロードしています。これは次のコマンドで確認できます。 uname -a Linux vfldev 2.6.32-504.16.2.el6.x86_64＃1 SMP Wed Apr 22 06:48:29 UTC 2015 x86_64 x86_64 x86_64 GNU / Linux ロードするカーネルバージョンを知っているブートローダ設定ファイル。CentOSの場合、ファイルは/boot/grub/grub.confで、新しいバージョンは/boot/grub2/grub.cfgです。 grub.confを見ると、現在ロードされているバージョンが青色で強調表示されている最初の4行で参照されていることがわかります。 1）タイトル>単にメニューに表示されるタイトル（クラウド環境には適用されません） 2）ルートディスク 3）ブート時にロードされるカーネルコマンドラインとそのパラメータ 4）ブートにロードされ、通常はカーネルにも一致するinitrdファイルのパス 4つのLinuxバージョンを参照するgrub.confの例： タイトルCentOS（2.6.32-504.16.2.el6.x86_64） ルート（hd0,0）カーネル/boot/vmlinuz-2.6.32-504.16.2.el6.x86_64 roルート= UUID = 6d089360-3e14-401d-91d0-378f3fd09332 rd_NO_LUKS rd_NO_LVM LANG = en_US.UTF-8 rd_NO_MD SYSFONT = latarcyrheb-sun16 KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM numa = offコンソール= ttyS0 earlyprintk = ttyS0 rootdelay = 300 crashkernel = auto initrd /boot/initramfs-2.6.32-504.16.2.el6.x86_64.img タイトルCentOS（2.6.32-504.12.2.el6.x86_64） ルート（hd0,0）カーネル/boot/vmlinuz-2.6.32-504.12.2.el6.x86_64 roルート= UUID = 6d089360-3e14-401d-91d0-378f3fd09332 rd_NO_LUKS rd_NO_LVM LANG = en_US.UTF-8 rd_NO_MD SYSFONT = latarcyrheb-sun16 KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM numa = offコンソール= ttyS0 earlyprintk = ttyS0 rootdelay = 300 crashkernel = auto initrd /boot/initramfs-2.6.32-504.12.2.el6.x86_64.img タイトルCentOS（2.6.32-504.8.1.el6.x86_64） ルート（hd0,0）カーネル/boot/vmlinuz-2.6.32-504.8.1.el6.x86_64 roルート= UUID = 6d089360-3e14-401d-91d0-378f3fd09332 rd_NO_LUKS rd_NO_LVM LANG = en_US.UTF-8 rd_NO_MD SYSFONT = latarcyrheb-sun16 KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM numa = offコンソール= ttyS0 earlyprintk = ttyS0 rootdelay = 300 crashkernel = auto initrd /boot/initramfs-2.6.32-504.8.1.el6.x86_64.img タイトルCentOS（2.6.32-431.29.2.el6.x86_64） ルート（hd0,0）カーネル/boot/vmlinuz-2.6.32-431.29.2.el6.x86_64 roルート= UUID = 6d089360-3e14-401d-91d0-378f3fd09332 rd_NO_LUKS rd_NO_LVM LANG = en_US.UTF-8 rd_NO_MD SYSFONT = latarcyrheb-sun16 KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM numa = offコンソール= ttyS0 earlyprintk = ttyS0 rootdelay = 300 initrd /boot/initramfs-2.6.32-431.29.2.el6.x86_64.img ブートローダ（grub.conf）を変更して強制的にLinux VMに別のカーネルをロードさせるには、手動による操作が必要です。その変更を行う手順を以下に示します。注：回復プロセスの手順を実行する前に、アクセスできないVMからVHDのバックアップを作成することを強くお勧めします。https://storageexplorer.comで入手可能なMicrosoft Storage Explorerを使用してVHDのバックアップを作成できます。 A =元のVM（アクセスできないVM） B =新しいVM（新しいリカバリVM）

Azure Portal経由でVM Aを停止する
Resource Manager VMでは、削除する前に現在のVM情報を保存することをお勧めします
- Azure CLI：azure vm show ResourceGroupName LinuxVmName> ORIGINAL_VM.txt
- Azure PowerShell：Get-AzureRmVM -ResourceGroupName $ rgName -Name $ vmName
VMを削除するが、「 接続されたディスクを保持する」を選択する注：アタッチされたディスクを保持するオプションは、従来のデプロイメントでのみ使用できます。リソースマネージャでは、VMを削除するとデフォルトでOSDiskが常に保持されます。
リースがクリアされたら、Azureポータル、仮想マシン、「 B 」、「 ディスクの接続 」を介して、 AからVM Bにデータディスクを接続します
VM " B "では、最終的にディスクが接続され、マウントすることができます。
VM " B "のマウントするドライブ名を探してください。それぞれのLinuxは少し異なります。
- grep SCSI /var/log/kern.log（ubuntu、debian ） grep SCSI / var / log / messages （centos、suse、oracle、redhat）
マウントされたディスクをmountpoint / rescueにマウントする df -h mkdir /レスキュー Red Hat 7.2+の場合 mount -o nouuid / dev / sdc2 / rescue CentOS 7.2以降 mount -o nouuid / dev / sdc1 / rescue Debian 8.2+、Ubuntu 16.04+、SUSE 12 SP4 + mount / dev / sdc1 / rescue
VM Bの / rescueにOSディスクをマウントし、/rescue/boot/grub.confファイルを変更します。 grub.confの変更

#title CentOS（2.6.32-504.16.2.el6.x86_64） #root（hd0,0） #kernel /boot/vmlinuz-2.6.32-504.16.2.el6.x86_64 roルート= UUID = 6d089360-3e14-401d-91d0-378f3fd09332 rd_NO_LUKS rd_NO_LVM LANG = en_US.UTF-8 rd_NO_MD SYSFONT = latarcyrheb-sun16 KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM numa = offコンソール= ttyS0 earlyprintk = ttyS0 rootdelay = 300 crashkernel = auto #initrd /boot/initramfs-2.6.32-504.16.2.el6.x86_64.img チェックする別の項目は、ブートローダーファイルのgrub.confにあるUUID値で指定されたデバイスが存在するかどうかです。 / rescueにマウントされたOSディスクの例を見て/ rescue / dev / disk / by-uuidを見てください grub.confファイルで参照されている対応するUUIDファイルがディスク上にピンク色で強調表示されていることがわかりますこのファイルは実際には属性lrwxrwxrwxの先頭でlで示され、OSDisk sda1を指しているシンボリックリンクですこのファイルがない場合でも、システムの起動時にシンボリックリンクの削除のテストが再作成されます。シンボリックリンクを手動で作成して、sda1がブートデバイスであるかどうか、および対応するUUIDを知る必要があります。 cd / rescue / dev / disk / by-uuid ln -s ../../sda1 6d089360-3e14-401d-91d0-378f3fd09332 sda1ファイルはls出力で見られるLinuxではブロックデバイスと呼ばれ、 brw-rw--属性でabで示されるか、fileコマンドを実行することで知られています。また、このファイルがcentos 6.5でテストされていることを確認することもできます。このファイルは、見つからない場合に再作成されます。 cd / rescue / dev / disk / by-uuid ls -ltr ../../da1 brw-rw-- 1ルートディスク8、1 Apr 30 14:37 ../../sda1 ファイル../../sda1 ../../sda1：ブロックスペシャル 2）前回のカーネルからブートしようとしたが、VMが起動しなかった場合、initramfsを再構築し、Linuxカーネルの新しい圧縮イメージをコピーしようとする可能性があります。これはgrubファイルの例にあります。 Initramfsファイル initrd /boot/initramfs-2.6.32-504.16.2.el6.x86_64.img カーネルファイル /boot/vmlinuz-2.6.32-504.16.2.el6.x86_64 通常、オンプレミス環境では、リカバリCDからシステムをブートします。クラウド環境では、起動しないシナリオでシステムファイルを回復または操作するために、同じOSとバージョンの一時的なVMにOSディスクを接続する必要があります。これは、initramfsのコピーまたは再作成を試みる場合にはさらに強化されます。カーネルファイル OSディスクが一時的なVM on / rescueに接続されると（最初にOSディスクをコピーしてデータを保護する）最初のカーネルを参照してエントリをコメントアウトして、それらを再起動する場合は、以前に行ったgrub.confへの変更を元に戻してください。次に、initramfsを再構築します。 mv /rescue/boot/initramfs-2.6.32-504.8.1.el6.x86_64.img /rescue/boot/initramfs-2.6.32-504.8.1.el6.x86_64.old-img 一時的なCentOS 6.6 Linux VMでは、正確に同じinitramfsを見つけることができなかったため、一時的な最新バージョンのビルドと使用ができませんでした。 dracut /rescue/boot/initramfs-2.6.32-504.8.1.el6.x86_64.img 2.6.32-504.8.1.el6.x86_64 次に、関連するvmlinuzファイルを安全にコピーし、最後にgrub.confを更新して新しいカーネル値を反映させます。 ls -ltr / lib / modules / drwxr-xr-xです。 7ルートルート4096年4月14日2014 2.6.32-431.11.2.el6.x86_64 drwxr-xr-xです。 7ルートルート4096 6月4日2014 2.6.32-431.17.1.el6.x86_64 drwxr-xr-xです。 7ルートルート4096 2014年9月25日2.6.32-431.29.2.el6.x86_64 drwxr-xr-xです。 7ルートルート4096 Nov 18 18:54 2.6.32-504.1.3.el6.x86_64 drwxr-xr-xです。 7根根4096 Mar 25 19:28 2.6.32-504.12.2.el6.x86_64 dracut /rescue/boot/initramfs-2.6.32-504.12.2.el6.x86_64.img 2.6.32-504.12.2.el6.x86_64 ls -ltr /rescue/boot/initramfs-2.6.32-504.12.2.el6.x86_64.img -rw --- 1ルートルート19354168 5月6日15:39 /rescue/boot/initramfs-2.6.32-504.12.2.el6.x86_64.img cp /boot/vmlinuz-2.6.32-504.12.2.el6.x86_64 / rescue / boot / ls -ltr / rescue / boot / vmlinuz * -rwxr-xr-x。 1ルートルート4128368 Nov 22 2013 /rescue/boot/vmlinuz-2.6.32-431.el6.x86_64 -rwxr-xr-x。 1ルートルート4128688 2013年1月3日/rescue/boot/vmlinuz-2.6.32-431.3.1.el6.x86_64 -rwxr-xr-x。 1ルートルート4129872 2014年5月7日/rescue/boot/vmlinuz-2.6.32-431.17.1.el6.x86_64 -rwxr-xr-x。 1ルートルート4131984 2014年9月9日/rescue/boot/vmlinuz-2.6.32-431.29.2.el6.x86_64 -rwxr-xr-x。 1ルートルート4153008 Jan 28 21:40 /rescue/boot/vmlinuz-2.6.32-504.8.1.el6.x86_64 -rwxr-xr-x。 1ルートルート4152720 5月6日15:44 /rescue/boot/vmlinuz-2.6.32-504.12.2.el6.x86_64 vi /rescue/boot/grub/grub.conf タイトルCentOS（2.6.32-504.12.2.el6.x86_64）ルート（hd0,0）カーネル/boot/vmlinuz-2.6.32-504.12.2.el6.x86_64 roルート= UUID = 6d089360-3e14-401d-91d0-378f3fd09332 rd_NO_LUKS rd_NO_LVM LANG = en_US.UTF-8 rd_NO_MD SYSFONT = latarcyrheb-sun16 crashkernel = auto KEYBOARDTYPE = pc KEYTABLE = us rd_NO_DM rhgb quiet numa =オフconsole = ttyS0 earlyprintk = ttyS0 rootdelay = 300 initrd /boot/initramfs-2.6.32-504.12.2.el6.x86_64.img cd / umount / rescue

Azureポータル経由でVM Bからディスクを切り離す
修復されたVHDから元のVM Aを再作成する

Linuxのリカバリ：chrootを使用してブートできないカーネルの問題の解決方法

Johan_Burati — Fri, 17 Nov 2017 15:52:20 GMT

前回の記事では、Linux VMを適切に起動させないカーネル関連の問題を手動で修正する方法について説明しました。また、 CHROOTを使用するための手順を使用できるオプションもあります。手動でファイルを編集する必要はなく、ツールを使用してこれらの同じ問題を自動的に修正します。この記事に記載されている手順に進むと、システムが準備されていることを前提としています。つまり、一連の手順を完了し、最終的に実行したことを意味します。 chroot / rescue 簡単な例として、CentOS 7.2でカーネルをバージョンアップした後で、起動しないシナリオがあるとします。 3.10.0-327.36.1.el7.x86_64 次のコマンドを実行することで、インストール済みのカーネルをすばやく確認できます。 cd / rescue / boot / grub2 / grep -i linux16 grub.cfg 出力は次のようになります。 linux16 / boot / vmlinuz-3.10.0-327.36.1.el7.x86_64 root = UUID = 3b5d406c-7fa6-458f-815c-9684bb9fe148 roコンソール= tty1コンソール= ttyS0,115200n8 earlyprintk = ttyS0,115200 rootdelay = 300 net.ifnames = 0 LANG = en_US.UTF-8 linux16 / boot / vmlinuz-3.10.0-327.18.2.el7.x86_64 root = UUID = 3b5d406c-7fa6-458f-815c-9684bb9fe148 roコンソール= tty1コンソール= ttyS0,115200n8 earlyprintk = ttyS0,115200 rootdelay = 300 net.ifnames = 0 つまり、現在の36.1と18.2がインストールされていることを意味します。次のコマンドを実行すると、簡単に18.2にロールバックできます。 grep -i menuentry grub.cfg 出力は次のようになります。 menuentry ' CentOS Linux（3.10.0-327.36.1.el7.x86_64）7（コア） ' -class centos -class gnu-linux -class gnu -class os -unrestricted $ menuentry_id_option 'gnulinux-3.10.0-327.18.2 .el7.x86_64-advanced-3b5d406c-7fa6-458f-815c-9684bb9fe148 '{ menuentry ' CentOS Linux（3.10.0-327.18.2.el7.x86_64）7（コア） ' -class centos -class gnu-linux -class gnu -class os -unrestricted $ menuentry_id_option 'gnulinux-3.10.0-327.18.2 .el7.x86_64-advanced-3b5d406c-7fa6-458f-815c-9684bb9fe148 '{ これで、次のことを実行できます。 grub2-editenvリスト次のように表示されます： saved_entry = CentOS Linux（3.10.0-327.36.1.el7.x86_64）7（コア） grub2-set-default "CentOS Linux（3.10.0-327.18.2.el7.x86_64）7（コア）" これはカーネルを18.2に戻します。この後、CHROOT環境を終了するための最終ステップを安全に行うことができます： chroot環境を終了し、すべてをアンマウントする手順は次のとおりです。出口 cd / umount / rescue / proc / umount / rescue / sys / umount /レスキュー/ dev / pts umount /レスキュー/ dev / DebianとUbuntuのディストリビューションでは、アンマウント（実行）する必要があります： umount / rescue / run / umount / rescue 最後に、ディスクを切り離して、PowerShellまたはAzure CLIのいずれかを使用して、記事を使用してVMを再構築することができます。 Azure PowerShell：VHDからVMを削除して再展開する方法 Azure CLI：VHDからVMを削除して再展開する方法

Azure Linux Extensions：Linux用カスタムスクリプト

Johan_Burati — Wed, 15 Nov 2017 16:14:42 GMT

あなたはおそらく、Azureで利用可能ないくつかの拡張を見てきました。それらのいくつかはここにリストされ/文書化されています： Azure Linux拡張機能この記事では、「Linux用カスタムスクリプト」拡張機能で使用できるいくつかの例について説明します。この拡張機能は基本的にLinux VM内でスクリプトを実行できるようにするため、Linuxエージェント（WAAGENT）が正常に機能している限り問題なくこの拡張機能を使用できるはずです。この拡張機能はポータルから実行できます。そのため、Azure Resource Manager（ARM）VMでは、次の項目をクリックしてアクセスできます。 VM名>拡張機能>追加>「Linux用カスタムスクリプト」を選択>作成 その後、実行したいスクリプトをアップロードし、 "Command"行を適切なものに変更してそのファイルを実行するだけでよいので、この場合はadduser.shというbashスクリプトを作成していますコマンドラインは次のスクリーンショットのようにbash adduser.shに変更されます： [ OK]をクリックすると、Linux VM内でスクリプトのデプロイと実行が開始されます。ほとんどの場合、Linuxのシェルスクリプトに精通している必要があります。また、スクリプトを実行する前に広範にテストすることを強くお勧めします。プロンプトや質問を処理するスクリプトを作成することに留意してください。それが実行されている間にアクセスします。いくつかの簡単な例として、これらの問題のいずれかに対処したいとします。 1）VMへのアクセスをブロックしているUbuntu Linux VM上でUFWファイアウォールを無効にする 2）特定のVMにログインすることを許可していないSSHホスト鍵に対する誤った許可を修正する 3）ポータルを使用しているときにVMに新しいアカウントを手動で追加することが何らかの理由で正しく機能しない 1）Ubuntu Linux VM上でUFWファイアウォールを無効にする "disableufw.sh"と呼ばれる空のテキストファイルを作成し、次の行を追加します。 ＃！/ bin / bash ufwを無効にする ロガー "カスタムスクリプトによって無効にされたufw" このスクリプトは基本的にufw disableコマンドを実行し、Ubuntuファイアウォールを無効にし、loggerコマンドを使用してシステムログに "ufwがカスタムスクリプトによって無効になっている"というメッセージを記録します。 2）SSHホスト鍵ファイルの誤った許可を修正する 空のテキストファイル "fixsshkeys.sh"を作成し、次の行を追加します。 ＃！/ bin / bash chmod 640 / etc / ssh / ssh_host_ecdsa_key ssh_host_ed25519_key chmod 644 /etc/ssh/ssh_host_ecdsa_key.pub ssh_host_ed25519_key.pub ssh_host_rsa_key.pub chmod 600 / etc / ssh / ssh_host_rsa_key ロガー "SSH鍵のアクセス権を正常にリセット" このスクリプトは、上記の指定されたファイルに対するファイルのパーミッションをデフォルトにリセットします。 3）sudoアクセスとSSH鍵で新しいアカウントを手動で追加する。 空のテキストファイル "adduser.sh"を作成し、次の行を追加します。 CentOS / RHELおよびOracleディストリビューションの場合 ＃！/ bin / bash ＃ユーザ名が小文字であることを確認してください。 USERNAME = " レスキュー " ＃提供された名前を使用してユーザーアカウントを作成します useradd -m $ USERNAME ロガー "Azureカスタムスクリプト - $ USERNAMEを追加" ＃ユーザ用のSSH設定フォルダを作成します。 mkdir -p /home/$USERNAME/.ssh logger "Azureカスタムスクリプト - SSH設定フォルダの作成" ＃指定されたユーザのauthorized_keysファイルにSSH鍵データを追加する。 ＃コンテンツ "SSH-PUBLIC-KEY"をユーザの公開鍵で置き換えます echo " SSH-PUBLIC-KEY " >> /home/$USERNAME/.ssh/authorized_keys logger "Azureカスタムスクリプト - ユーザー$ USERNAMEのSSHキーの追加" ＃sudoersにユーザアカウントを追加する echo "$ USERNAME ALL =（ALL）ALL"> /etc/sudoers.d/$USERNAME SUSEディストリビューションの場合 ＃！/ bin / bash ＃あなたの望むパスワードを入力します。＃小文字のユーザ名を使用していることを確認します。 USERNAME = " レスキュー " ＃提供された名前を使用してユーザーアカウントを作成します useradd -m $ USERNAME -G users ロガー "Azureカスタムスクリプト - $ USERNAMEを追加" ＃ユーザ用のSSH設定フォルダを作成します。 mkdir -p /home/$USERNAME/.ssh logger "Azureカスタムスクリプト - SSH設定フォルダの作成" ＃与えられたユーザのauthorized_keysファイルへのSSH鍵データの追加 ＃コンテンツ "SSH-PUBLIC-KEY"をユーザの公開鍵で置き換えます echo " SSH-PUBLIC-KEY " >> /home/$USERNAME/.ssh/authorized_keys logger "Azureカスタムスクリプト - ユーザー$ USERNAMEのSSHキーの追加" ＃sudoersにユーザアカウントを追加する echo "$ USERNAME ALL =（ALL）NOPASSWD：ALL"> /etc/sudoers.d/$USERNAME logger "Azureカスタムスクリプト - $ USERNAME sudoersファイルの作成" Ubuntu / Debianディストリビューションの場合 ＃！/ bin / bash ＃ユーザ名が小文字であることを確認してください。 USERNAME = " レスキュー " ＃提供された名前を使用してユーザーアカウントを作成します useradd -m -G sudo $ USERNAME ロガー "Azureカスタムスクリプト - $ USERNAMEを追加" ＃ユーザ用のSSH設定フォルダを作成します。 mkdir -p /home/$USERNAME/.ssh logger "Azureカスタムスクリプト - SSH設定フォルダの作成" ＃指定されたユーザのauthorized_keysファイルにSSH鍵データを追加する。 ＃コンテンツ "SSH-PUBLIC-KEY"をユーザの公開鍵で置き換えます echo " SSH-PUBLIC-KEY " >> /home/$USERNAME/.ssh/authorized_keys logger "Azureカスタムスクリプト - ユーザー$ USERNAMEのSSHキーの追加" 上記のスクリプトは基本的に "rescue"という名前のアカウントを作成し、ログインに追加されたSSH公開鍵を使用します。 "SSH-PUBLIC-KEY"フィールドをSSH公開鍵の内容に置き換えてください。 Azure PowerShellやAzure CLIなどの拡張機能やその他の実行方法についての詳細は、次のページを参照してください。 Linux用カスタムスクリプト

AzureでLinux osDiskパーティションのサイズを変更する

Johan_Burati — Mon, 13 Nov 2017 17:48:21 GMT

Azure上のほとんどのLinuxイメージは、デフォルトでosDiskのサイズが30GBになります。これは、サイズを変更して前方に移動したい場合があります。パーティションのサイズを変更する作業はAzureではとても簡単です。次の手順で行うことができます。 a）ポータルまたはAzure CLI / PowerShell上のVMの停止と割り当て解除。 b）ポータル上のディスクを編集し、サイズを希望の値に設定する。 c）Linux OS内のパーティション情報を更新します。これはパーティションや配布によって多少異なりますが、基本的にはルートパーティションを削除して再作成するという概念は非常に似ています。注：手順の前にVHDのバックアップを作成することを強くお勧めします。http: //storageexplorer.comまたはAZCopyを使用すると、VMの割り当てが解除されます。必要なパーティション変更を行う手順は、ディストリビューションごとに以下に記載されており、特定のリリースでテストされています。 Red Hat 7.3 / CentOS 7.3およびOracle 7.3の場合：

1）SSHを使用してVMにログインすると、以下を使用してディスクのサイズを確認できます。 sudo dmesg | grep -i sda

次のような出力が表示されるはずです（ディスクのポータルでサイズを100GBに変更したと仮定します）。 [3.100914] sd 2：0：0：0：[sda] 209715200 512バイトの論理ブロック：（107 GB / 100 GiB ） 2）パーティションのサイズ変更を続行するには、以下を使用します。 sudo fdisk / dev / sda

タイプ： p これは基本的にパーティション1とパーティション2である/ dev / sda1と/ dev / sda2の両方のパーティションを表示します

次のように入力します。d = 2 （パーティション2を削除する）次のように入力します。nとp 、 2 （パーティション2を再作成する場合）デフォルト値次のように入力します。w （新しいパーティションを保存する）次のように入力します。q （fdiskを終了する） sudo reboot （パーティションを更新するようにVMをリブートする）

3）リサイズを終了するには、再起動後に次のコマンドを実行します。

Red Hat 7.3およびCentOS 7.3の場合： sudo xfs_growfs / dev / sda2

Oracle 7.3の場合： sudo btrfsファイルシステムのサイズを変更するmax /

4） df -hコマンドを使用して、サイズを確認します。使用されるファイルシステムのサイズ使用可能マウント％ / dev / sda2 100G 1.6G 98G 2％/

Ubuntu 16.04 LTSの場合： 特別な手順は必要ありません。単純にVMの割り当てを解除し、ポータルのサイズを変更してVMバックアップを開始します。VMの起動後にサイズを確認するには、次のコマンドを使用します。 df -h 使用されるファイルシステムのサイズ使用可能マウント％ / dev / sda1 97G 1.4G 96G 2％/ Debian 8の場合：

1）SSHを使用してVMにログインすると、以下を使用してディスクのサイズを確認できます。 sudo dmesg | grep -i sda

次のような出力が表示されるはずです（ディスクのポータルでサイズを100GBに変更したと仮定します）。 [3.100914] sd 2：0：0：0：[sda] 209715200 512バイトの論理ブロック：（107 GB / 100 GiB ）

2）パーティションのサイズ変更を続行するには、以下を使用します。 sudo fdisk / dev / sda

タイプ： p パーティション/ dev / sda1が表示されます

タイプ： d 次のように入力します。nとp 、 1 （パーティション1を再作成する場合）デフォルト値次のように入力します。w （新しいパーティションを保存する）次のように入力します。q （fdiskを終了する） sudo reboot （パーティションを更新するようにVMをリブートする） 3）リサイズを終了するには、再起動後に次のコマンドを実行します。 resize2fs / dev / sda1 4） df -h コマンドを使用して、サイズを確認します。使用されるファイルシステムのサイズ使用可能マウント％ / dev / sda1 99G 698M 94G 1％/ SUSE 12 SP2（Premium）の場合：

1）SSHを使用してVMにログインすると、以下を使用してディスクのサイズを確認できます。 sudo dmesg | grep -i sda

2）パーティションのサイズ変更を続行するには、以下を使用します。 sudo fdisk / dev / sda タイプ： p これは基本的にパーティション1とパーティション2である/ dev / sda1と/ dev / sda2の両方のパーティションを表示します

3）リサイズを終了するには、再起動後に次のコマンドを実行します。 resize2fs / dev / sda2

4） df -hコマンドを使用して、サイズを確認します。使用されるファイルシステムのサイズ使用可能マウント％ / dev / sda2 98G 1.2G 92G 2％/

CoreOS（安定版）の場合： 特別な手順は必要ありません。単純にVMの割り当てを解除し、ポータルのサイズを変更してVMバックアップを開始します。CoreOSにはいくつかの追加のパーティションがあり、余分なスペースがルートパーティション（通常は/ dev / sda9）に追加されます。

Azure上のLinux VMにSWAPを追加する

Johan_Burati — Fri, 10 Nov 2017 16:47:26 GMT

Azureのすべての仮想マシン（VM）には、一時的な記憶域としてのみ使用されることが推奨され、再起動または保存時に利用可能でなくてもよいSWAPファイルやデータが含まれている一時的な（短命の）このドライブに保存されているデータは失われます。 ResourceDisk.MountPoint パラメーターで定義されているディレクトリーにスワップ・ファイルを作成するには、以下の3つのパラメーターを設定して /etc/waagent.conf ファイルを更新します。 ResourceDisk.Format = y ResourceDisk.EnableSwap = y ResourceDisk.SwapSizeMB = xx サイズがMBの場合、たとえば、4GBのスワップファイルを作成するには、次の行を使用します。 ResourceDisk.Format = y ResourceDisk.EnableSwap = y ResourceDisk.SwapSizeMB = 4096 WAAgentを使用してSWAPファイルを作成する前に、一時的なディスクの空き容量を確認することをお勧めします。このリンクをクリックすると、VMの各カテゴリで使用可能なローカルSSDまたはローカルHDDストレージが表示されます。参考文献： Linux Azure仮想マシンにスワップファイルを追加する方法 AzureでLinux VMを最適化する