Azure Stack Hub の既知の問題

この記事では、Azure Stack Hub のリリースにおける既知の問題の一覧を示します。 新しい問題が特定されると、この一覧は更新されます。

別のバージョンの既知の問題にアクセスするには、左側の目次の上部にあるバージョン セレクターのドロップダウンを使用します。

重要

更新プログラムを適用する前に、このセクションを確認してください。

重要

お使いの Azure Stack Hub インスタンスが 2 つ前の更新プログラムより古い場合、コンプライアンスに対応していないとみなされます。 サポートを受けるためには、少なくともサポートされる最小バージョンまで更新する必要があります。

更新

Azure Stack Hub の更新に関する既知の問題については、Azure Stack Hub の更新プログラムに関するトラブルシューティングに関する記事を参照してください。

AKS/ACR の更新前のチェック中に 2102 への更新が失敗する

  • 適用先: この問題は、Azure Kubernetes Service (AKS) と Azure Container Registry (ACR) プライベート プレビューのお客様に適用されます。
  • 修復: 2102 に更新する前に、AKS と ACR をアンインストールする必要があります。 これらのサービスをアンインストールした後、更新プログラムを再起動してください。
  • 発生頻度: ACR または AKS がインストールされているすべてのスタンプで、このエラーが発生します。

ネットワーキング

仮想ネットワーク ゲートウェイ

Load Balancer

[フロントエンド IP アドレスの追加] に [IPv6] ボタンが表示される

  • 適用先: この問題は 2008 以降のリリースに適用されます。
  • 原因: ロード バランサー上の [フロントエンド IP アドレスの追加] オプションに [IPv6] ボタンが表示されます。 これらのボタンは無効で、選択できません。
  • 発生頻度: 共通

フローティング IP が有効な場合のバックエンド ポートとフロントエンド ポート

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因:フローティング IP が有効になっている場合は、負荷分散規則でフロントエンド ポートとバックエンド ポートの両方が同じである必要があります。 これは仕様です。
  • 発生頻度: 共通

Compute

Syslog パイプライン内にアラートがない

  • 適用先: この問題は、リリース 2102 に適用されます。
  • 原因: このリリースでは、お客様用のアラート モジュールは、アラートの Syslog に応じて無効になっています。 このリリースの正常性と監視のパイプラインは、依存関係とサービス要件の数を減らすために変更されました。 このため、新しいサービスは Syslog パイプラインに対してアラートを生成しません。
  • 修復: [なし] :
  • 発生頻度: 共通

使用

インフラストラクチャ バックアップ上の状態が間違っている

  • 適用先: この問題は、リリース 2102 に適用されます。
  • 原因: 状態自体の更新中、インフラストラクチャ バックアップ ジョブによって間違った状態 (失敗または成功) が表示されることがあります。 これはバックアップ データの整合性には影響しませんが、実際に障害が発生すると、混乱が生じる可能性があります。
  • 修復: この問題は 2102 用の次の修正プログラムで修正されます。

更新

Azure Stack Hub の更新に関する既知の問題については、Azure Stack Hub の更新プログラムに関するトラブルシューティングに関する記事を参照してください。

更新による CA VM へのパッケージ Microsoft.AzureStack.Compute.Installer のインストールに失敗しました

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因:更新中、CA VM にコピーする必要がある新しいコンテンツで、プロセスがロックを取得します。 更新が失敗すると、ロックは解除されます。
  • 修復: 更新プログラムを再開します。
  • 発生頻度: 珍しい

ポータル

管理サブスクリプション

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因: バージョン 1804 で導入された 2 つの管理サブスクリプションは使用しないでください。 このサブスクリプションの種類は Metering サブスクリプションと Consumption サブスクリプションです。
  • 修復: これら 2 つのサブスクリプション上でリソースが実行されている場合は、ユーザー サブスクリプションで再作成してください。
  • 発生頻度: 共通

ネットワーク

ネットワーク セキュリティ グループ

DenyAllOutbound 規則が原因で VM のデプロイが失敗する

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。

  • 原因: VM の作成中は、インターネットに対する明示的な DenyAllOutbound 規則を NSG に作成することはできません。VM のデプロイを完了するために必要な通信が妨げられるためです。 また、VM をデプロイするために必要な次の 2 つの重要な IP も拒否されます:DHCP IP:169.254.169.254 および DNS IP:168.63.129.16

  • 修復: VM の作成中はインターネットのアウトバウンド トラフィックを許可しておき、VM の作成後に、必要なトラフィックをブロックするよう NSG を変更してください。

  • 発生頻度: 共通

Virtual Network ゲートウェイ

Load Balancer

Load Balancer が特定のシナリオでトラフィックを 1 つのバックエンド VM に送信する

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因: ロード バランサーで セッション アフィニティ を有効にすると、2 タプル ハッシュで、VM に割り当てられたプライベート IP ではなく、PA IP (物理アドレス IP) が使用されます。 ロード バランサーに送信されるトラフィックが VPN 経由で到着する、またはすべてのクライアント VM (ソース IP) が同じノード上に存在し、セッション アフィニティが有効になっているシナリオでは、すべてのトラフィックが 1 つのバックエンド VM に送信されます。
  • 発生頻度: 共通

[フロントエンド IP アドレスの追加] に [IPv6] ボタンが表示される

  • 適用先:この問題は 2008 リリースに適用されます。
  • 原因:IPv6 ボタンは、パブリック ロード バランサーのフロントエンド IP 構成が作成されるときに表示され、有効になります。 これはポータルの表面的な問題です。 IPv6 は Azure Stack Hub ではサポートされていません。
  • 発生頻度: 共通

フローティング IP が有効になっている場合は、バックエンド ポートとフロントエンド ポートが同じである必要があります

  • 適用先:この問題はすべてのリリースに適用されます。
  • 原因:フローティング IP が有効になっている場合は、負荷分散規則でフロントエンド ポートとバックエンド ポートの両方が同じである必要があります。 これは仕様です。
  • 発生頻度: 共通

Compute

VM の停止と割り当て解除を行うと MTU 構成が削除される

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因: VM で 停止、割り当て解除 を実行すると、VM の MTU 構成が削除されます。 この動作は Azure と矛盾しています。
  • 発生頻度: 共通

更新

Azure Stack Hub の更新に関する既知の問題については、Azure Stack Hub の更新プログラムに関するトラブルシューティングに関する記事を参照してください。

更新による CA VM へのパッケージ Microsoft.AzureStack.Compute.Installer のインストールに失敗しました

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因:更新中、CA VM にコピーする必要がある新しいコンテンツで、プロセスがロックを取得します。 更新が失敗すると、ロックは解除されます。
  • 修復: 更新プログラムを再開します。
  • 発生頻度: 珍しい

ポータル

管理サブスクリプション

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因: バージョン 1804 で導入された 2 つの管理サブスクリプションは使用しないでください。 このサブスクリプションの種類は Metering サブスクリプションと Consumption サブスクリプションです。
  • 修復: これら 2 つのサブスクリプション上でリソースが実行されている場合は、ユーザー サブスクリプションで再作成してください。
  • 発生頻度: 共通

ネットワーク

ネットワーク セキュリティ グループ

実行中の VM に NIC が接続されていない場合、NSG を削除できない

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因: NSG と、実行中の VM に接続されていない NIC の関連付けを解除すると、そのオブジェクトの更新 (PUT) 操作がネットワーク コントローラー レイヤーで失敗します。 NSG はネットワーク リソース プロバイダー レイヤーで更新されますが、ネットワーク コントローラー上では更新されないため、NSG はエラー状態に移行します。
  • 修復: 削除する必要がある NSG に関連付けられている NIC を、実行中の VM に接続し、NSG の関連付けを解除するか、NSG に関連付けられている NIC をすべて削除します。
  • 発生頻度: 共通

DenyAllOutbound 規則が原因で VM のデプロイが失敗する

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因: VM の作成中は、インターネットに対する明示的な DenyAllOutbound 規則を NSG に作成することはできません。VM のデプロイを完了するために必要な通信が妨げられるためです。
  • 修復: VM の作成中はインターネットのアウトバウンド トラフィックを許可しておき、VM の作成後に、必要なトラフィックをブロックするよう NSG を変更してください。
  • 発生頻度: 共通

Virtual Network ゲートウェイ

Load Balancer

Load Balancer が特定のシナリオでトラフィックを 1 つのバックエンド VM に送信する

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因: ロード バランサーで セッション アフィニティ を有効にすると、2 タプル ハッシュで、VM に割り当てられたプライベート IP ではなく、PA IP (物理アドレス IP) が使用されます。 ロード バランサーに送信されるトラフィックが VPN 経由で到着する、またはすべてのクライアント VM (ソース IP) が同じノード上に存在し、セッション アフィニティが有効になっているシナリオでは、すべてのトラフィックが 1 つのバックエンド VM に送信されます。
  • 発生頻度: 共通

パブリック IP が失敗状態にある

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因: ロード バランサーに関連付けられているパブリック IP の IdleTimeoutInMinutes 値は変更できません。 この操作により、パブリック IP は失敗状態になります。
  • 修復: パブリック IP を正常な状態に戻すには、パブリック IP を参照するロード バランサー規則の IdleTimeoutInMinutes 値を元の値に戻します (既定値は 4 分です)。
  • 発生頻度: 共通

Compute

VM の停止、割り当て解除を行うと、MTU 構成になる

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因: VM で 停止、割り当て解除 を実行すると、VM の MTU 構成が削除されます。 この動作は Azure と矛盾しています。
  • 発生頻度: 共通

ポータルを使用した、Standard_DS2_v2 サイズでの仮想マシン スケール セットのデプロイに関する問題

  • 適用先:この問題は 2005 リリースに適用されます。
  • 原因:ポータルのバグにより、Standard_DS2_v2 サイズでのスケール セットの作成が失敗します。
  • 修復: PowerShell または CLI を使用して、仮想マシン スケール セットのこの VM サイズをデプロイします。

Ubuntu Server 20.04 での VM 拡張機能の使用に関する問題

  • 適用先:この問題は Ubuntu Server 20.04 LTS に適用されます。
  • 原因: 一部の Linux ディストリビューションは Python 3.8 に移行し、Python 用のレガシ /usr/bin/python エントリポイントは完全に削除されました。 Python 3.x に移行した Linux ディストリビューション ユーザーは、これらの拡張機能を VM にデプロイする前に、レガシ /usr/bin/python エントリポイントが確実に存在するようにする必要があります。 そうしないと、拡張機能のデプロイが失敗する可能性があります。
  • 修復: 「Python 3 対応 Linux Azure Virtual Machines システムでの VM 拡張機能の使用に関する問題」の解決手順に従います。ただし、Azure Stack Hub には 実行コマンド 機能がないため手順 2 はスキップします。

ポータル上の NVv4 VM のサイズ

  • 適用先:この問題は、2002 以降に適用されます。
  • 原因: VM の作成エクスペリエンスを実行すると、次の VM サイズが表示されます:NV4as_v4。 AMD Mi25 ベースの Azure Stack Hub GPU プレビューに必要なハードウェアを所有しているお客様は、VM のデプロイを成功させることができます。 他のすべてのお客様は、この VM サイズでの VM のデプロイに失敗します。
  • 修復: Azure Stack Hub GPU プレビューの準備のための仕様です。

コンピューティング クォータの消費

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因: 新しい仮想マシンを作成すると、"This subscription is at capacity for Total Regional vCPUs on this location.This subscription is using all 50 Total Regional vCPUs available. " (このサブスクリプションはこの場所の [リージョンの vCPU の合計] の容量に達しています。このサブスクリプションは、[リージョンの vCPU の合計] の使用可能な 50 個をすべて使用しています。)" などのエラーを受け取ることがあります。 これは、使用可能な合計コア数のクォータに達したことを示します。
  • 修復: クォータを追加したアドオン プランをオペレーターに依頼してください。 現在のプランのクォータの編集では解決せず、クォータの増加は反映されません。
  • 発生頻度: 珍しい

VM の概要ブレードに正しいコンピューター名が表示されない

  • 適用先:この問題はすべてのリリースに適用されます。
  • 原因: 概要ブレードで VM の詳細を表示すると、コンピューター名に (使用できません) と表示されます。 これは、特殊なディスクまたはディスク スナップショットから作成された VM の設計によるもので、Marketplace イメージでも発生します。
  • 修復: [設定] の下にある [プロパティ] ブレードを確認します。

仮想マシン スケール セット

4 ノードの Azure Stack Hub 環境では修正プログラムや更新プログラムの適用中に作成が失敗する

  • 適用先:この問題は、サポートされているすべてのリリースに適用されます。
  • 原因: 4 ノードの Azure Stack Hub 環境では、障害ドメインが 3 つの可用性セット内での VM の作成および仮想マシン スケール セット インスタンスの作成が、更新プロセス中に FabricVmPlacementErrorUnsupportedFaultDomainSize エラーで失敗します。
  • 修復: 障害ドメインが 2 つの可用性セット内には 1 つの VM を正常に作成できます。 ただし、4 ノードの Azure Stack Hub のデプロイでは、依然として更新プロセス中にスケール セット インスタンスを作成することはできません。

ストレージ

保持期間が 0 に戻る

  • 適用先:この問題は、リリース 2002 および 2005 に適用されます。
  • 原因: 保持期間の設定で 0 以外の期間を指定した場合は、2002 または 2005 の更新中に 0 (この設定の既定値) に戻ります。 0 日の設定は、更新が完了した直後に有効になります。これにより、削除された既存のストレージ アカウントと今後新たに削除されるストレージ アカウントはすべて、すぐに保持期間外となり、定期的なガベージ コレクション (1 時間ごとに実行) のマークが付けられます。
  • 修復: 保持期間を正しい期間に手動で指定してください。 新しい保持期間が指定される前に既にガベージ コレクションされているストレージ アカウントは回復できません。

リソース プロバイダー

SQL/MySQL

  • 適用先:この問題は、リリース 2002 に適用されます。
  • 原因: スタンプに SQL リソースプロバイダー (RP) バージョン 1.1.33.0 以前が含まれている場合は、スタンプの更新時に SQL または MySQL のブレードが読み込まれません。
  • 修復: RP をバージョン 1.1.47.0 に更新します。

App Service

  • 適用先:この問題は、リリース 2002 に適用されます。
  • 原因: スタンプに App Service リソース プロバイダー (RP) バージョン 1.7 以前が含まれている場合は、スタンプの更新時に App Service のブレードが読み込まれません。
  • 修復: RP をバージョン 2002 Q2 に更新します。

PowerShell

Az モジュールをインストールすると、エラーがスローされる

  • 適用先:この問題は、2002 以降に適用されます。
  • 原因:モジュールをインストールすると、エラーがスローされます。 エラー メッセージは次の文字列で始まります。Register-PacakgeSource : A parameter cannot be found that matches parameter name. 'PackageManagementProvider'.。または、エラー メッセージに次のテキストが含まれている可能性があります。PackageManagement\Install-Package : Cannot convert value "2.0.1-preview" to type "System.Version". Error: "Input string was not in a correct format."
  • 修復: 同じセッションで、次のコマンドレットを実行します。
    Install-Module PowershellGet -MinimumumVersion 2.3.0 -Force
    セッションを閉じ、新しい管理者特権の PowerShell セッションを開始します。
  • 発生頻度: 共通

Az モジュールをインストールすると、管理者権限が必要であるというエラーが間違ってスローされる

  • 適用先:この問題は、2002 以降に適用されます。
  • 原因:管理者特権のプロンプトからモジュールをインストールすると、エラーがスローされます。 エラーは Administrator rights required と表示されます。
  • 修復: セッションを閉じ、新しい管理者特権で PowerShell セッションを開始します。 既存の Az が存在しないことを確認します。 アカウント モジュールがセッションに読み込まれました。
  • 発生頻度: 共通

アーカイブ

アーカイブされた、以前のバージョンの既知の問題にアクセスするには、左側の目次の上部にあるバージョン セレクターのドロップダウンを使用して、表示するバージョンを選択します。

次のステップ

2002 アーカイブされた既知の問題

1910 アーカイブされた既知の問題

1908 アーカイブされた既知の問題

1907 アーカイブされた既知の問題

1906 アーカイブされた既知の問題

1905 アーカイブされた既知の問題

1904 アーカイブされた既知の問題

1903 アーカイブされた既知の問題

1902 アーカイブされた既知の問題

1901 アーカイブされた既知の問題

1811 アーカイブされた既知の問題

1809 アーカイブされた既知の問題

1808 アーカイブされた既知の問題

1807 アーカイブされた既知の問題

1805 アーカイブされた既知の問題

1804 アーカイブされた既知の問題

1803 アーカイブされた既知の問題

1802 アーカイブされた既知の問題

以前のバージョンの Azure Stack Hub の既知の問題には、左側の目次の [リソース] > [リリース ノートのアーカイブ] からアクセスできます。 左上の [バージョン セレクター] ドロップダウンで、目的のアーカイブ済みのバージョンを選択します。 これらのアーカイブされた記事は、参照のみを目的に提供されており、これらのバージョンのサポートを意味しているわけではありません。 Azure Stack のサポートについては、「Azure Stack Hub サービス ポリシー」を参照してください。 さらにサポートが必要な場合は、Microsoft カスタマー サポート サービスにお問い合わせください。