製品ドキュメント

Citrix Virtual Apps and Desktops

PDFを表示

Google Cloud Platformカタログの作成

September 24, 2024

寄稿者:

C C

「マシンカタログの作成」では、マシンカタログを作成するウィザードについて説明します。以下の情報は、Googleクラウド環境に固有の詳細について説明しています。

注：

Google Cloud Platform（GCP）カタログを作成する前に、GCPへの接続の作成を完了する必要があります。「Googleクラウド環境への接続」を参照してください。

マスター仮想マシンインスタンスと永続ディスクを準備する

ヒント：

永続ディスクは、仮想ディスクを表すGoogle Cloudの用語です。

マスター仮想マシンインスタンスを準備するには、計画されたマシンカタログの複製されたVDAインスタンスに必要な構成と一致するプロパティで仮想マシンインスタンスを作成して構成します。構成は、インスタンスのサイズとタイプのみに適用されるわけではありません。また、メタデータ、タグ、GPU割り当て、ネットワークタグ、サービスアカウントプロパティなどのインスタンス属性も含まれます。

マスタリングプロセスの一部として、MCSはマスターVMインスタンスを使用してGoogle Cloudインスタンステンプレートを作成します。次に、インスタンステンプレートを使用して、マシンカタログを構成する複製されたVDAインスタンスを作成します。複製されたインスタンスは、インスタンステンプレートが作成されたマスター仮想マシンインスタンスのプロパティ（VPC、サブネット、および永続ディスクのプロパティを除く）を継承します。

マスター仮想マシンインスタンスのプロパティを仕様に合わせて構成した後、インスタンスを起動し、インスタンスの永続ディスクを準備します。

ディスクのスナップショットを手動で作成することをお勧めします。これにより、意味のある命名規則を使用してバージョンを追跡でき、マスターイメージの以前のバージョンを管理するためのオプションが増え、マシンカタログの作成時間を節約できます。独自のスナップショットを作成しない場合、MCSが一時的なスナップショットを作成します（これはプロビジョニングプロセスの最後に削除されます）。

マシンカタログの作成

マシンカタログは次の2つの方法で作成できます。

Web Studioでのマシンカタログの作成

注：

マシンカタログを作成する前にリソースを作成してください。マシンカタログを構成するときは、Google Cloudで定められた命名規則を使用します。詳しくは、「バケットとオブジェクトの命名ガイドライン」を参照してください。

「マシンカタログの作成」のガイダンスに従ってください。次の説明は、Google Cloudのカタログに固有の説明です。

Web Studioにサインインし、左側のペインで ［マシンカタログ］ をクリックします。
操作バーで ［マシンカタログの作成］ を選択します。
［オペレーティングシステム］ ページで、［マルチセッションOS］ を選択してから ［次へ］ を選択します。
- Citrix Virtual Apps and DesktopsではシングルセッションOSもサポートしています。
［マシン管理］ ページで、［電源管理されているマシン］ および ［Citrix Machine Creation Services］ オプションを選択してから ［次へ］ を選択します。複数のリソースがある場合は、メニューから1つ選択してください。
［イメージ］ページで、必要に応じて次の手順を実行し、［次へ］をクリックします。
1. スナップショットまたはVMをマスターイメージとして選択します。単一テナント機能を使用する場合は、必ずノードグループプロパティが正しく構成されているイメージを選択してください。「ゾーン選択の有効化」を参照してください。
2. 既存のVMをマシンプロファイルとして使用するには、［マシンプロファイルを使用する］を選択し、VMを選択します。
  
  注：
  
  現在、このカタログ内のVMは、ディスク暗号化セットID、マシンサイズ、ストレージの種類、およびゾーン設定をマシンプロファイルから継承します。
3. カタログの最小機能レベルを選択します。単一テナント機能を使用する場合は、必ずノードグループプロパティが正しく構成されているイメージを選択してください。
［ストレージの種類］ ページで、このマシンカタログのオペレーティングシステムを格納するために使用するストレージの種類を選択します。次のストレージオプションにはそれぞれ、固有の価格とパフォーマンスの特性があります（IDディスクは、常にゾーン標準永続ディスクを使用して作成されます）。
- 標準永続ディスク
- バランス永続ディスク
- SSD永続ディスク
Google Cloudストレージオプションについて詳しくは、https://cloud.google.com/compute/docs/disks/を参照してください。
［仮想マシン］ ページで、作成するVMの数を指定し、VMの詳細な仕様を表示してから、［次へ］ を選択します。マシンカタログに単一テナントノードグループを使用する場合は、予約済み単一テナントノードが使用可能なゾーンのみを選択するようにしてください。「ゾーン選択の有効化」を参照してください。
［コンピューターアカウント］ ページで、Active Directoryアカウントを選択してから ［次へ］ を選択します。
- ［新しいActive Directoryアカウントを作成する］ を選択する場合、ドメインを選択してからActive Directoryで作成されたプロビジョニング済みのVMコンピューターアカウントで名前付けスキームに対応した文字列を入力します。アカウント名前付けスキームに指定できる文字数は1～64文字であり、空白スペース、非ASCII文字、および特殊文字を含めることはできません。
- ［既存のActive Directoryアカウントを使用する］ を選択した場合、［参照］ を選択し、選択したマシンの既存のActive Directoryコンピューターアカウントに移動します。
［ドメイン資格情報］ ページで、［資格情報の入力］ を選択し、ユーザー名とパスワードを入力し、［保存］ を選択してから ［次へ］ を選択します。
- 入力する資格情報には、Active Directoryアカウント操作を実行する権限が必要です。
［概要］ ページで、情報を確認し、カタログの名前を指定してから、［完了］ を選択します。
注：

バージョン2402以降、GCPカタログ名は次の規則に準拠する必要があります：
- 小文字で始めます。
- 小文字（a～z）、数字、ハイフンのみを含めます。
- 小文字または数字で終わります。
これらの規則に準拠していない既存のGCPカタログの名前を変更しようとすると、エラーメッセージが表示され、更新された規則に従って名前を変更するように指示されます。

マシンカタログの作成が完了するまでに時間がかかる場合があります。ターゲットノードグループにマシンが作成されていることを確認するには、Google Cloudコンソールに移動します。

手動で作成したGoogle Cloudマシンのインポート

Google Cloudへの接続を作成してから、Google Cloudマシンを含むカタログを作成できます。次に、Citrix Virtual Apps and Desktopsを使用して、Google Cloudマシンの電源を手動で再投入できます。この機能により、次のことが可能になります：

手動で作成したGoogle CloudマルチセッションOSマシンをCitrix Virtual Apps and Desktopsマシンカタログにインポートします。
手動で作成したGoogle CloudマルチセッションOSマシンをCitrix Virtual Apps and Desktopsカタログから削除します。
既存のCitrix Virtual Apps and Desktopsの電源管理機能を使用して、Google Cloud WindowsマルチセッションOSマシンの電源管理を行います。たとえば、これらのマシンの再起動スケジュールを設定します。

この機能には、Citrix Virtual Apps and Desktopsの既存のプロビジョニングワークフローの変更や、既存機能の削除は必要はありません。手動で作成されたGoogle Cloudマシンをインポートする代わりに、MCSを使用してWeb Studioでマシンをプロビジョニングすることをお勧めします。

共有仮想プライベートクラウド

共有仮想プライベートクラウド（VPC）は、共有サブネットが使用可能なホストプロジェクトと、リソースを使用する1つ以上のサービスプロジェクトで構成されます。共有VPCは、企業の共有Google Cloudリソースの制御、使用、管理を一元的に行うため、大規模なインストールでは望ましいオプションです。詳しくは、Googleのドキュメントのサイトを参照してください。

この機能により、Machine Creation Services（MCS）は、共有VPCに展開されたマシンカタログのプロビジョニングと管理をサポートします。このサポートは、現在ローカルVPCで提供されているサポートと同等の機能ですが、次の2つの点が異なります：

ホスト接続の作成に使用するサービスアカウントに追加の権限を付与する必要があります。このプロセスにより、MCSは共有VPCリソースにアクセスして使用できるようになります。
受信用と送信用の2つのファイアウォール規則を作成する必要があります。これらのファイアウォール規則は、イメージのマスタリングプロセスで使用されます。

新しい権限が必要

ホスト接続を作成するときは、特定の権限を持つGoogle Cloudサービスアカウントが必要です。これらの追加の権限は、VPCベースのホスト接続を作成するために使用されるすべてのサービスアカウントに付与する必要があります。

ヒント：

これらの追加権限は、Citrix Virtual Apps and Desktopsでは新しい権限ではありません。これらは、ローカルVPCの実装を容易にするために使用されます。共有VPCの場合、これらの追加権限により、共有VPCリソースへのアクセスが許可されます。

共有VPCをサポートするには、ホスト接続に関連付けられたサービスアカウントに追加の権限を最大4つ付与する必要があります：

compute.firewalls.list - この権限は必須です。これにより、MCSは共有VPCに存在するファイアウォール規則のリストを取得できます。
compute.networks.list - この権限は必須です。これにより、MCSがサービスアカウントで使用可能な共有VPCネットワークを識別できます。
compute.subnetworks.list – この権限は、VPCの使用方法に応じてオプションとなります。これにより、MCSは可視の共有VPC内のサブネットを識別できます。この権限は、ローカルVPCを使用する場合は既に必須ですが、共有VPCホストプロジェクトでも割り当てる必要があります。
compute.subnetworks.use - この権限は、VPCの使用方法に応じてオプションとなります。プロビジョニングされたマシンカタログでは、サブネットリソースを使用する必要があります。この権限は、ローカルVPCを使用する場合は既に必須ですが、共有VPCホストプロジェクトでも割り当てる必要があります。

これらの権限を使用する場合は、マシンカタログの作成に使用する権限の種類によって方法が異なることを考慮してください：

プロジェクトレベルの権限：
- ホストプロジェクト内のすべての共有VPCへのアクセスを許可します。
- 権限#3と#4をサービスアカウントに割り当てる必要があります。
サブネットレベルの権限：
- 共有VPC内の特定のサブネットへのアクセスを許可します。
- 権限#3と#4は、サブネットレベルの割り当てに組み込まれているため、サービスアカウントに直接割り当てる必要はありません。

組織のニーズとセキュリティ基準に合ったアプローチを選択します。

ヒント：

プロジェクトレベルとサブネットレベルの権限の違いについて詳しくは、Google Cloudのドキュメントを参照してください。

ファイアウォール規則

マシンカタログの準備中に、カタログのマスターイメージシステムディスクとして機能するマシンイメージが準備されます。このプロセスが発生すると、ディスクは一時的に仮想マシンに接続されます。このVMは、すべての受信および送信ネットワークトラフィックが禁止された、分離された環境で実行する必要があります。これは、2つのdeny-allファイアウォール規則によって実現されます：1つは受信トラフィック用で、もう1つは送信トラフィック用です。Google CloudローカルVCPを使用する場合、MCSはこのファイアウォールをローカルネットワーク上に作成し、マスタリングのためにマシンに適用します。マスタリングが完了すると、ファイアウォール規則がイメージから削除されます。

Shared VPCを使用するために必要な新しい権限の数は最小限に抑えることを推奨します。共有VPCは、より高レベルの企業リソースであり、通常はより厳格なセキュリティプロトコルを採用しています。このため、共有VPCリソース上のホストプロジェクトに2つのファイアウォール規則を作成します。1つは受信用、もう1つは送信用です。それらに最も高い優先度を割り当てます。次の値を使用して、これらの各規則に新しいターゲットタグを適用します：

citrix-provisioning-quarantine-firewall

MCSは、マシンカタログを作成または更新するときに、このターゲットタグを含むファイアウォール規則を検索します。次に、規則が正しいかを調べ、カタログのマスターイメージの準備で使用されたマシンにそれを適用します。ファイアウォール規則が見つからない場合、または規則は見つかったが規則やその優先度が正しくない場合には、次のようなメッセージが表示されます：

"Unable to find valid INGRESS and EGRESS quarantine firewall rules for VPC <name> in project <project>. " Please ensure you have created 'deny all' firewall rules with the network tag 'citrix-provisioning-quarantine-firewall' and proper priority." "Refer to Citrix Documentation for details."

共有VPCの構成

Web Studioで共有VPCをホスト接続として追加する前に、次の手順を実行して、プロビジョニングするプロジェクトのサービスアカウントを追加します：

IAM役割を作成します。
CVADホスト接続の作成に使用するサービスアカウントを、共有VPCホストプロジェクトIAM役割に追加します。
プロビジョニングするプロジェクトのCloud Buildサービスアカウントを、共有VPCホストプロジェクトIAM役割に追加します。
ファイアウォール規則を作成します。

IAM役割を作成する

役割のアクセスレベル（プロジェクトレベルのアクセスか、またはサブネットレベルのアクセスを使用する、より制限されたモデル）を決定します。

IAM役割のプロジェクトレベルのアクセス。プロジェクトレベルのIAM役割には、次の権限を含めます：

compute.firewalls.list
compute.networks.list
compute.subnetworks.list
compute.subnetworks.use

プロジェクトレベルのIAM役割を作成するには、次の手順を実行します：

Google Cloudコンソールで、［IAM & admin］>［Roles］ の順に選択します。
［Roles］ ページで、［CREATE ROLE］ を選択します。
［Create Role］ ページで、役割名を指定します。［ADD PERMISSIONS］ を選択します。
1. ［Add permissions］ ページで、役割に権限を個別に追加します。権限を追加するには、［Filter table］ フィールドで権限の名前を入力します。権限を選択し、［ADD］ を選択します。
2. ［CREATE］ を選択します。

サブネットレベルのIAM役割。この役割では、［CREATE ROLE］ を選択した後、権限compute.subnetworks.listとcompute.subnetworks.useの追加が省略されます。このIAMアクセスレベルでは、新しい役割に権限compute.firewalls.listとcompute.networks.listを適用する必要があります。

サブネットレベルのIAM役割を作成するには、次の手順を実行します：

Google Cloudコンソールで、［VPC network］>［Shared VPC］ に移動します。［Shared VPC］ ページが開き、ホストプロジェクトに含まれる共有VPCネットワークのサブネットが表示されます。
［Shared VPC］ ページで、アクセスするサブネットを選択します。
右上隅にある ［ADD MEMBER］ を選択して、サービスアカウントを追加します。
［Add members］ ページで、次の手順を実行します：
1. ［New members］ フィールドにサービスアカウントの名前を入力し、メニューでサービスアカウントを選択します。
2. ［Select a role］ フィールドを選択し、［Compute Network User］ を選択します。
3. ［SAVE］ を選択します。
Google Cloudコンソールで、［IAM & admin］>［Roles］ の順に選択します。
［Roles］ ページで、［CREATE ROLE］ を選択します。
［Create Role］ ページで、役割名を指定します。［ADD PERMISSIONS］ を選択します。
1. ［Add permissions］ ページで、役割に権限を個別に追加します。権限を追加するには、［Filter table］ フィールドで権限の名前を入力します。権限を選択し、［ADD］ を選択します。
2. ［CREATE］ を選択します。

ホストプロジェクトのIAM役割にサービスアカウントを追加する

IAM役割を作成した後、次の手順を実行して、ホストプロジェクトのサービスアカウントを追加します：

Google Cloudコンソールでホストプロジェクトに移動し、［IAM & admin］>［IAM］ の順に選択します。
［IAM］ ページで、［ADD］ を選択してサービスアカウントを追加します。
［Add members］ ページで、次の操作を行います：
1. ［New members］ フィールドにサービスアカウントの名前を入力し、メニューでサービスアカウントを選択します。
2. 役割のフィールドを選択し、作成したIAM役割を入力して、メニューでその役割を選択します。
3. ［SAVE］ を選択します。

これで、ホストプロジェクト用のサービスアカウントが構成されました。

Cloud Buildサービスアカウントを共有VPCに追加する

すべてのGoogle Cloudサブスクリプションは、プロジェクトID番号の後にサービスアカウントが指定され、その後にcloudbuild.gserviceaccountが続きます。例：705794712345@cloudbuild.gserviceaccount。

プロジェクトのプロジェクトID番号を確認するには、Google Cloudコンソールで ［Home］ と ［Dashboard］ を選択します：

Google Cloudコンソールのナビゲーションペイン

画面の ［Project Info］ 領域でプロジェクト番号を探します。

Cloud Buildサービスアカウントを共有VPCに追加するには、次の手順を実行します：

Google Cloudコンソールでホストプロジェクトに移動し、［IAM & admin］>［IAM］の順に選択します。
［Permissions］ ページで、［ADD］を選択してアカウントを追加します。
［Add members］ ページで、次の手順を実行します：
1. ［New members］ フィールドにCloud Buildサービスアカウントの名前を入力し、メニューでサービスアカウントを選択します。
2. ［Select a role］ フィールドを選択し、Computer Network Userを入力して、メニューで役割を選択します。
3. ［SAVE］ を選択します。

ファイアウォール規則の作成

マスタリングプロセスの一部として、MCSは選択されたマシンイメージをコピーし、それを使用してカタログ用のマスターイメージシステムディスクを準備します。マスタリングでは、MCSがディスクを一次仮想マシンに接続し、そこで準備スクリプトが実行されます。このVMは、すべての受信および送信ネットワークトラフィックが禁止された、分離された環境で実行する必要があります。分離された環境を作成するには、MCSに2つのdeny allファイアウォール規則（受信規則と送信規則）が必要です。したがって、ホストプロジェクトに次のように2つのファイアウォール規則を作成します：

Google Cloudコンソールでホストプロジェクトに移動し、［VPC network］>［Firewall］ の順に選択します。
［Firewall］ ページで、［CREATE FIREWALL RULE］ を選択します。
［Create a firewall rule］ ページで、次の操作を行います：
- 名前。規則名を入力します。
- Network：受信ファイアウォール規則を適用する共有VPCネットワークを選択します。
- Priority：値が小さいほど、規則の優先度は高くなります。小さい値（10など）を指定することをお勧めします。
- Direction of traffic：［Ingress］ を選択します。
- Action on match：［Deny］ を選択します。
- Targets：デフォルトの ［Specified target tags］ を使用します。
- Target tags：「citrix-provisioning-quarantine-firewall」と入力します。
- Source filter：デフォルトの ［IP ranges］ を使用します。
- Source IP ranges：すべてのトラフィックに一致する範囲を入力します。「0.0.0.0/0」と入力します。
- Protocols and ports：［Deny all］ を選択します。
［CREATE］ を選択して規則を作成します。
さらに規則を作成するには、手順1～4を繰り返します。［Direction of traffic］ で、［Egress］を選択します。

接続の追加

Googleクラウド環境への接続を追加します。「接続の追加」を参照してください。

ゾーン選択の有効化

Citrix Virtual Apps and Desktopsでは、ゾーン選択をサポートしています。ゾーン選択では、VMを作成するゾーンを指定します。ゾーン選択により、管理者は選択したゾーン間に単一のテナントノードを配置できます。単一テナントを構成するには、Google Cloudで次の手順を実行する必要があります：

Google Cloudの単一テナントノードを予約する
VDAマスターイメージを作成する

Google Cloudの単一テナントノードを予約する

単一テナントノードを予約するには、Google Cloudのドキュメントを参照してください。

重要：

ノードテンプレートは、ノードグループで予約されているシステムのパフォーマンス特性を示すために使用されます。これらの特性には、vGPUの数、ノードに割り当てられたメモリの量、ノード上に作成されたマシンに使用されるマシンの種類が含まれます。詳しくは、Google Cloudのドキュメントを参照してください。

VDAマスターイメージを作成する

単一テナントノードにマシンを正常に展開するには、マスターVMイメージの作成時に追加の手順を実行する必要があります。Google Cloud上のマシンインスタンスには、ノードアフィニティラベルと呼ばれるプロパティがあります。単一テナントノードに展開されたカタログのマスターイメージとして使用されるインスタンスには、ターゲットノードグループの名前と一致するノードアフィニティラベルが必要です。これを実現するには、次の点に注意してください：

新しいインスタンスの場合は、インスタンスの作成時にGoogle Cloudコンソールでラベルを設定します。詳しくは、「インスタンスの作成時にノードアフィニティラベルを設定する」を参照してください。
既存のインスタンスの場合は、gcloudコマンドラインを使用してラベルを設定します。詳しくは、「既存のインスタンスのノードアフィニティラベルを設定する」を参照してください。

注：

共有VPCで単一テナントを使用する場合は、「共有仮想プライベートクラウド」を参照してください。

インスタンスの作成時にノードアフィニティラベルを設定する

ノードアフィニティラベルを設定するには、次の手順に従います：

Google Cloudコンソールで、［Compute Engine］>［VM instances］ に移動します。
［VM instances］ ページで、［Create instance］ を選択します。
［Instance creation］ ページで、必要な情報を入力または設定し、［management］、［security］、［disks］、［networking］、［sole tenancy］ の順に選択して設定パネルを開きます。
［Sole tenancy］ タブで、［Browse］ を選択して、現在のプロジェクトで使用可能なノードグループを表示します。［Sole-tenant node］ ページが開き、使用可能なノードグループのリストが表示されます。
［Sole-tenant node］ ページで、リストから該当するノードグループを選択し、［Select］ を選択して ［Sole tenancy］ タブに戻ります。［node affinity labels］フィールドに、選択した情報が入力されます。この設定により、インスタンスから作成されたマシンカタログが、選択したノードグループに展開されます。
［Create］ を選択してインスタンスを作成します。

既存のインスタンスのノードアフィニティラベルを設定する

ノードアフィニティラベルを設定するには、次の手順に従います：

Google Cloud Shell端末ウィンドウで、gcloud compute instancesコマンドを使用してノードアフィニティラベルを設定します。gcloudコマンドに次の情報を含めます：
- 仮想マシンの名前。たとえば、「s*2019-vda-base」という名前の既存のVMを使用します。*
- ノードグループの名前。以前に作成したノードグループ名を使用します。例：mh-sole-tenant-node-group-1。
- インスタンスが存在するゾーン。たとえば、仮想マシンは*us-east-1b* zoneにあります。
たとえば、端末ウィンドウで次のコマンドを入力します：
- gcloud compute instances set-scheduling "s2019-vda-base" --node-group="mh-sole-tenant-node-group-1" --zone="us-east1-b"
gcloud compute instancesコマンドについて詳しくは、Googleデベロッパーツールのドキュメント（https://cloud.google.com/sdk/gcloud/reference/beta/compute/instances/set-scheduling）を参照してください。
インスタンスの ［VM instance details］ ページに移動し、［Node Affinities］ フィールドにラベルが入力されていることを確認します。

マシンカタログの作成

ノードアフィニティラベルを設定した後、マシンカタログを構成します。

顧客管理暗号キー（CMEK）

MCSカタログでは、顧客管理暗号キー（CMEK：Customer Managed Encryption Keys）を使用できます。この機能を使用する場合は、Google Cloudキー管理サービスのCryptoKey Encrypter/Decrypter役割をCompute Engineサービスエージェントに割り当てます。Citrix Virtual Apps and Desktopsのアカウントには、キーが保存されているプロジェクトでの適切な権限が必要です。詳しくは、「Cloud KMS鍵を使用してリソースを保護する」を参照してください。

Compute Engineサービスエージェントの形式は次のとおりです：service-<Project _Number>@compute-system.iam.gserviceaccount.com。この形式は、デフォルトのCompute Engineサービスアカウントとは異なります。

注：

このCompute Engineサービスアカウントは、Googleコンソールの ［IAM Permissions］ 画面に表示されないことがあります。このような場合は、「Cloud KMS鍵を使用してリソースを保護する」で説明されているgcloudコマンドを使用します。

Citrix Virtual Apps and Desktopsアカウントへの権限の割り当て

Google Cloud KMSの権限はさまざまな方法で設定できます。プロジェクトレベルのKMS権限、またはリソースレベルのKMS権限のいずれかを指定できます。詳しくは、「権限と役割」を参照してください。

プロジェクトレベルの権限

1つのオプションは、Citrix Virtual Apps and DesktopsアカウントにCloud KMSリソースを参照するためのプロジェクトレベルの権限を提供することです。これを行うには、カスタム役割を作成し、次の権限を追加します：

cloudkms.keyRings.list
cloudkms.keyRings.get
cloudkms.cryptokeys.list
cloudkms.cryptokeys.get

Citrix Virtual Apps and Desktopsにこのカスタム役割を割り当てます。これにより、インベントリ内の関連プロジェクトの地域キーを参照できます。

リソースレベルの権限

もう1つのオプションであるリソースレベルの権限の場合、Google Cloudコンソールで、MCSプロビジョニングに使用するcryptoKeyを参照します。Citrix Virtual Apps and Desktopsアカウントを、カタログプロビジョニングに使用するキーリングまたはキーに追加します。

ヒント：

このオプションを使用すると、Citrix Virtual Apps and DesktopsアカウントにCloud KMSリソースに対するプロジェクトレベルのリスト権限がないため、インベントリ内のプロジェクトの地域キーを参照できません。ただし、以下で説明するProvSchemeカスタムプロパティで正しいcryptoKeyIdを指定することにより、CMEKを使用してカタログをプロビジョニングできます。

カスタムプロパティを使用したCMEKによるプロビジョニング

PowerShellでプロビジョニングスキームを作成するときは、ProvScheme CustomPropertiesでCryptoKeyIdプロパティを指定します。例：

'<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Property xsi:type="StringProperty" Name="CryptoKeyId" Value="<yourCryptoKeyId>" />
</CustomProperties>'
<!--NeedCopy-->

cryptoKeyIdは次の形式で指定する必要があります：

projectId:location:keyRingName:cryptoKeyName

たとえば、リージョンus-east1にあるキーリングmy-example-key-ringのキーmy-example-keyと、IDがmy-example-project-1のプロジェクトを使用する場合、ProvSchemeカスタム設定は次のようになります：

'<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Property xsi:type="StringProperty" Name="CryptoKeyId" Value="my-example-project-1:us-east1:my-example-key-ring:my-example-key" />
</CustomProperties>'
<!--NeedCopy-->

このプロビジョニングスキームに関連するすべてのMCSプロビジョニングされたディスクとイメージは、このCMEK（顧客管理暗号キー）を使用します。

ヒント：

グローバルキーを使用する場合、顧客プロパティの場所はリージョン名ではなくglobalである必要があります。上記の例では、us-east1です。例：<Property xsi:type="StringProperty" Name="CryptoKeyId" Value="my-example-project-1:global:my-example-key-ring:my-example-key" />。

顧客管理キーの交換

Google Cloudでは、既存の永続ディスクまたはイメージでのキーの交換をサポートしていません。マシンがプロビジョニングされると、作成時に使用されていたバージョンのキーに関連付けられます。ただし、新しいバージョンのキーを作成することはでき、その新しいキーは、カタログが新しいマスターイメージで更新されたときに作成される、新しくプロビジョニングされたマシンまたはリソースに使用されます。

キーリングに関する重要な注意事項

キーリングの名前を変更したり、削除したりすることはできません。また、構成時に予期しない料金が発生する場合があります。キーリングを削除すると、Google Cloudは次のエラーメッセージを表示します：

Sorry, you can't delete or rename keys or key rings. We were concerned about the security implications of allowing multiple keys or key versions over time to have the same resource name, so we decided to make names immutable. (And you can't delete them, because we wouldn't be able to do a true deletion--there would still have to be a tombstone tracking that this name had been used and couldn't be reused).
We're aware that this can make things untidy, but we have no immediate plans to change this.
If you want to avoid getting billed for a key or otherwise make it unavailable, you can do so by deleting all the key versions; neither keys nor key rings are billed for, just the active key versions within the keys.
<!--NeedCopy-->

ヒント：

詳しくは、「Editing or deleting a key ring from the console」を参照してください。

均一なバケットレベルのアクセスの互換性

Citrix Virtual Apps and Desktopsは、Google Cloudの均一なバケットレベルのアクセス制御ポリシーと互換性があります。この機能は、サービスアカウントにアクセス許可を付与して、ストレージバケットなどのリソースの操作を許可するIAMポリシーの使用を強化します。均一なバケットレベルのアクセス制御により、Citrix Virtual Apps and Desktopsでは、アクセス制御リスト（ACL）を使用して、ストレージバケットまたはそれらに格納されているオブジェクトへのアクセスを制御できます。Google Cloudの均一なバケットレベルのアクセスに関する概要情報については、「均一なバケットレベルのアクセス」を参照してください。構成情報については、「均一なバケットレベルのアクセス」を参照してください。

PowerShellを使用してマシンカタログを作成する

このセクションでは、PowerShellを使用してカタログを作成する方法について説明します。

永続的なライトバックキャッシュディスクのカタログを作成する
MCSIOによる起動パフォーマンスの向上
マシンプロファイルを使用してマシンカタログを作成する
インスタンステンプレートとしてマシンプロファイルを使用してマシンカタログを作成する
PowerShellを使用してシールドされた仮想マシンでカタログを作成する
単一テナントノードにWindows 11 VMを作成する

永続的なライトバックキャッシュディスクのカタログを作成する

永続的なライトバックキャッシュディスクのカタログを構成するには、PowerShellパラメーターNew-ProvScheme CustomPropertiesを使用します。

ヒント：

ここで、PowerShellパラメーターはクラウドベースのホスティング接続にのみ使用してください。オンプレミスソリューション（XenServerなど）で永続的なライトバックキャッシュディスクを使用してマシンをプロビジョニングする場合、ディスクは自動的に永続化されるため、PowerShellは必要ありません。

このパラメーターでは追加プロパティPersistWBCをサポートしており、これを使用することで、MCSでプロビジョニングされたマシンのライトバックキャッシュディスクを永続化させる方法を指定できます。PersistWBCプロパティは、UseWriteBackCacheパラメーターが指定され、WriteBackCacheDiskSizeパラメーターがディスクが作成されたことを示すよう設定された場合のみ使用されます。

注：

この動作は、電源を入れ直したときにデフォルトのMCSIOライトバックキャッシュディスクが削除されて再作成されるAzureおよびGCPの両方に適用されます。ディスクを永続化すると、MCSIOライトバックキャッシュディスクの削除と再作成を回避できます。

プロパティ［PersistWBC］を「true」に設定すると、Citrix Virtual Apps and Desktops管理者が管理インターフェイスでマシンをシャットダウンしたときに、ライトバックキャッシュディスクが消去されません。

プロパティ［PersistWBC］を「false」に設定すると、Citrix Virtual Apps and Desktops管理者が管理インターフェイスでマシンをシャットダウンしたときに、ライトバックキャッシュディスクが消去されます。

注：

プロパティ［PersistWBC］を省略すると、デフォルトが「false」になるので、管理インターフェイスでマシンをシャットダウンしたときにライトバックキャッシュが消去されます。

たとえば、CustomPropertiesパラメーターを使用して［PersistWBC］を「true」に設定する場合を考えましょう:

<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="UseManagedDisks" Value="true" />
<Property xsi:type="StringProperty" Name="StorageAccountType" Value="Premium_LRS" />
<Property xsi:type="StringProperty" Name="ResourceGroups" Value="benvaldev5RG3" />
<Property xsi:type="StringProperty" Name="PersistWBC" Value="true" />
</CustomProperties>
<!--NeedCopy-->

注：

PersistWBCプロパティは、New-ProvScheme PowerShellコマンドレットを使用してのみ設定できます。作成後にプロビジョニングスキームのCustomPropertiesを変更しようとしても、マシンがシャットダウンしたときにマシンカタログやライトバックキャッシュディスクの永続性は影響を受けません。

例：プロパティ［PersistWBC］を「true」に設定してライトバックキャッシュを使用するようにNew-ProvSchemeを設定すると、次のようになります：

New-ProvScheme
-CleanOnBoot
-CustomProperties "<CustomProperties xmlns=`"http://schemas.citrix.com/2014/xd/machinecreation`" xmlns:xsi=`"http://www.w3.org/2001/XMLSchema-instance`"><Property xsi:type=`"StringProperty`" Name=`"UseManagedDisks`" Value=`"true`" /><Property xsi:type=`"StringProperty`" Name=`"StorageAccountType`" Value=`"Premium_LRS`" /><Property xsi:type=`"StringProperty`" Name=`"ResourceGroups`" Value=`"benvaldev5RG3`" /><Property xsi:type=`"StringProperty`" Name=`"PersistWBC`" Value=`"true`" /></CustomProperties>"
-HostingUnitName "adSubnetScale1"
-IdentityPoolName "BV-WBC1-CAT1"
-MasterImageVM "XDHyp:\HostingUnits\adSubnetScale1\image.folder\GoldImages.resourcegroup\W10MCSIO-01_OsDisk_1_a940e6f5bab349019d57ccef65d2c7e3.manageddisk"
-NetworkMapping @{"0"="XDHyp:\HostingUnits\adSubnetScale1\virtualprivatecloud.folder\CloudScale02.resourcegroup\adVNET.virtualprivatecloud\adSubnetScale1.network"}
-ProvisioningSchemeName "BV-WBC1-CAT1"
-ServiceOffering "XDHyp:\HostingUnits\adSubnetScale1\serviceoffering.folder\Standard_D2s_v3.serviceoffering"
-UseWriteBackCache
-WriteBackCacheDiskSize 127
-WriteBackCacheMemorySize 256
<!--NeedCopy-->

MCSIOによる起動パフォーマンスの向上

MCSIOが有効な場合、AzureやGCPの管理対象ディスクの起動パフォーマンスを向上させることができます。New-ProvSchemeコマンドでPowerShellカスタムプロパティPersistOSDiskを使用してこの機能を構成します。New-ProvSchemeに関連するオプションは次のとおりです：

<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="UseManagedDisks" Value="true" />
<Property xsi:type="StringProperty" Name="StorageAccountType" Value="Premium_LRS" />
<Property xsi:type="StringProperty" Name="Resource <!--NeedCopy-->
``````<!--NeedCopy-->
<!--NeedCopy-->
````````Groups" Value="benvaldev5RG3" />
<Property xsi:type="StringProperty" Name="PersistOsDisk" Value="true" />
</CustomProperties>
<!--NeedCopy-->

この機能を有効にするには、カスタムプロパティ［PersistOSDisk］を「true」に設定します。例：

New-ProvScheme
-CleanOnBoot
-CustomProperties "<CustomProperties xmlns=`"http://schemas.citrix.com/2014/xd/machinecreation`" xmlns:xsi=`"http://www.w3.org/2001/XMLSchema-instance`"><Property xsi:type=`"StringProperty`" Name=`"UseManagedDisks`" Value=`"true`" /><Property xsi:type=`"StringProperty`" Name=`"StorageAccountType`" Value=`"Premium_LRS`" /><Property xsi:type=`"StringProperty`" Name=`"ResourceGroups`" Value=`"benvaldev5RG3`" /><Property xsi:type=`"StringProperty`" Name=`"PersistOsDisk`" Value=`"true`" /></CustomProperties>"
-HostingUnitName "adSubnetScale1"
-IdentityPoolName "BV-WBC1-CAT1"
-MasterImageVM "XDHyp:\HostingUnits\adSubnetScale1\image.folder\GoldImages.resourcegroup\W10MCSIO-01_OsDisk_1_a940e6f5bab349019d57ccef65d2c7e3.manageddisk"
-NetworkMapping @{"0"="XDHyp:\HostingUnits\adSubnetScale1\virtualprivatecloud.folder\CloudScale02.resourcegroup\adVNET.virtualprivatecloud\adSubnetScale1.network"}
-ProvisioningSchemeName "BV-WBC1-CAT1"
-ServiceOffering "XDHyp:\HostingUnits\adSubnetScale1\serviceoffering.folder\Standard_D2s_v3.serviceoffering"
-UseWriteBackCache
-WriteBackCacheDiskSize 127
-WriteBackCacheMemorySize 256
<!--NeedCopy-->

マシンプロファイルを使用してマシンカタログを作成する

Machine Creation Services（MCS）を使用してマシンをプロビジョニングするためのカタログを作成する場合、マシンプロファイルを使用して、仮想マシンからハードウェアプロパティをキャプチャし、カタログで新しくプロビジョニングされたVMに適用できます。MachineProfileパラメーターが使用されていない場合、ハードウェアプロパティはマスターイメージVMまたはスナップショットからキャプチャされます。明示的に定義する一部のプロパティ（StorageType、CatalogZones、CryptoKeyIsなど）は、マシンプロファイルから無視されます。

マシンプロファイルを含むカタログを作成するには、New-ProvSchemeコマンドを使用します。例：New-ProvScheme –MachineProfile "path to VM"。MachineProfileパラメーターを指定しない場合、ハードウェアプロパティはマスターイメージVM からキャプチャされます。
新しいマシンプロファイルでカタログを更新するには、Set-ProvSchemeコマンドを使用します。例：Set-ProvScheme –MachineProfile "path to new VM"。このコマンドは、カタログ内の既存VMのマシンプロファイルを変更しません。新しいマシンプロファイルは、カタログに追加された新しく作成されたVMのみにあります。
マスターイメージを更新することもできますが、マスターイメージを更新しても、ハードウェアプロパティは更新されません。ハードウェアプロパティを更新する場合は、Set-ProvSchemeコマンドを使用してマシンプロファイルを更新する必要があります。これらの変更は、カタログ内の新しいマシンにのみ適用されます。既存マシンのハードウェアプロパティを更新する場合、-StartsNowおよび-DurationInMinutes -1パラメーターを指定したSet-ProvVMUpdateTimeWindowコマンドを使用できます。
注：
- StartsNowは、スケジュールの開始時刻が現在時刻であることを指定します。
- 負の数（-1など）のDurationInMinutesは、スケジュールの期間に上限がないことを示します。

インスタンステンプレートとしてマシンプロファイルを使用してマシンカタログを作成する

マシンプロファイルの入力としてGCPインスタンステンプレートを選択できます。インスタンステンプレートはGCPのライトウェイトリソースであるため、費用対効果が非常に高くなります。

インスタンステンプレートとしてマシンプロファイルを使用して新しいマシンカタログを作成する

PowerShellウィンドウを開きます。
asnp citrix*を実行し、Citrix固有のPowerShellモジュールをロードします。
次のコマンドを使用して、GCPプロジェクトでインスタンステンプレートを見つけます：
```
cd XDHyp:\HostingUnits<HostingUnitName>\instanceTemplates.folder

```
NewProvSchemeコマンドを使用して、インスタンステンプレートとしてマシンプロファイルを使用して新しいマシンカタログを作成します：
```
New-ProvScheme -ProvisioningSchemeName <CatalogName>  -HostingUnitName <HostingUnitName> -IdentityPoolName <identity pool name> -MasterImageVM
XDHyp:\HostingUnits<HostingUnitName> \Base.vm\Base.snapshot -MachineProfile XDHyp:\HostingUnits<HostingUnitName>\instanceTemplates.folder\mytemplate.template

```
New-ProvSchemeコマンドについて詳しくは、「https://developer-docs.citrix.com/projects/citrix-daas-sdk/en/latest/MachineCreation/New-ProvScheme/」を参照してください。
PowerShellコマンドを使用して、マシンカタログの作成を完了します。Remote PowerShell SDKを使用してカタログを作成する方法については、https://developer-docs.citrix.com/projects/citrix-virtual-apps-desktops-sdk/en/latest/creating-a-catalog/を参照してください。

インスタンステンプレートを既存のマシンカタログのマシンプロファイルに変更する

インスタンステンプレートを既存のマシンカタログのマシンプロファイルに変更する詳細な手順は、次のとおりです：

PowerShellウィンドウを開きます。
asnp citrix*を実行し、Citrix固有のPowerShellモジュールをロードします。
次のコマンドを実行します：
```
Set-ProvScheme -ProvisioningSchemeName  <CatalogName> -MachineProfile XDHyp:\HostingUnits<HostingUnitName>\instanceTemplates.folder<TemplateName>.template

```
Set-ProvSchemeコマンドについて詳しくは、「https://developer-docs.citrix.com/projects/citrix-daas-sdk/en/latest/MachineCreation/Set-ProvScheme/」を参照してください。

PowerShellを使用してシールドされた仮想マシンでカタログを作成する

シールドされた仮想マシンプロパティを使用してMCSマシンカタログを作成できます。シールドされた仮想マシンは、セキュアブート、仮想トラステッドプラットフォームモジュール、UEFIファームウェア、整合性監視などの高度なプラットフォームセキュリティ機能を使用して、Compute Engineインスタンスの検証可能な整合性を提供する一連のセキュリティ制御によって強化されます。

MCSは、マシンプロファイルワークフローを使用したカタログの作成をサポートしています。マシンプロファイルワークフローを使用する場合は、仮想マシンインスタンスのシールドされた仮想マシンプロパティを有効にする必要があります。その後、この仮想マシンインスタンスをマシンプロファイルの入力で使用できます。

マシンプロファイルワークフローを使用して、シールドされた仮想マシンでMCSマシンカタログを作成するには、次の手順に従います。

Google Cloudコンソールで仮想マシンインスタンスのシールドされた仮想マシンオプションを有効にします。「クイックスタート：Shielded VMオプションを有効にする」を参照してください。
仮想マシンインスタンスを使用して、マシンプロファイルワークフローでMCSマシンカタログを作成します。
1. PowerShellウィンドウを開きます。
2. asnp citrix*を実行し、Citrix固有のPowerShellモジュールをロードします。
3. IDプールをまだ作成していない場合は作成します。
4. New-ProvSchemeコマンドを実行します。例：
```
New-ProvScheme -ProvisioningSchemeName <catalog-name>
-HostingUnitName gcp-hostint-unit
-MasterImageVM XDHyp:\HostingUnits\gcp-hostint-unit\catalog-vda.vm
-MachineProfile XDHyp:\HostingUnits\gcp-hostint-unit\catalog-machine.vm

```
マシンカタログの作成を完了します。

新しいマシンプロファイルでマシンカタログを更新するには、次の手順を実行します：

Set-ProvSchemeコマンドを実行します。例：

Set-ProvScheme -ProvisioningSchemeName <catalog-name>
-MasterImageVM XDHyp:\HostingUnits<hostin-unit>\catalog-vda.vm
-MachineProfile "DHyp:\HostingUnits<hostin-unit>\catalog-machine.vm
<!--NeedCopy-->

Set-ProvSchemeで行った変更を既存の仮想マシンに適用するには、Set-ProvVMUpdateTimeWindowコマンドを実行します。

Set-ProvVMUpdateTimeWindowコマンドを実行します。例：

Set-ProvVMUpdateTimeWindow -ProvisioningSchemeName my-catalog -VMName <List-Of-Vm-Names> -StartsNow -DurationInMinutes -1
<!--NeedCopy-->

VMを再起動します。

単一テナントノードにWindows 11 VMを作成する

GCPでWindows 11 VMを作成できます。ただし、マスターイメージにWindows 11をインストールする場合は、マスターイメージの作成プロセス中にvTPMを有効にする必要があります。また、マシンプロファイルソース（VMまたはインスタンステンプレート）でvTPMを有効にする必要があります。

単一テナントノードにWindows 11 VMを作成するための主な手順は次のとおりです：

Google Cloud仮想化環境をセットアップします。詳しくは、「Google Cloud環境」を参照してください。
VDAのインストール。「VDAのインストール」を参照してください。
Googleクラウド環境への接続を作成します。詳しくは、「Googleクラウド環境への接続」を参照してください。
Windows 11のライセンス持ち込み（BYOL）マスターイメージを作成し、そのイメージをGoogle Cloudにインポートします。「Windows 11 BYOLマスターイメージを作成する」を参照してください。
マシンプロファイルソースを作成します。単一テナントノードでVMをプロビジョニングし、ソースマシンプロファイルのvTPMを有効にします。「単一テナントノードにVMをプロビジョニングする」を参照してください。
vTPMが有効になっているWindows 11マシンプロファイルソースを使用して、MCSマシンカタログを作成します。マシンプロファイルソースは、単一テナントノードで説明されているものと同じインスタンスの種類である必要があります。「Windows 11マシンプロファイルソースを使用してMCSマシンカタログを作成する」を参照してください。

Windows 11 BYOLマスターイメージを作成する

Windows 11 BYOLマスターイメージを作成し、そのマスターイメージをGoogle Cloudにインポートするには、次の2つのオプションがあります：

Google Cloud Cloud Buildツールを使用する
他のハイパーバイザー上にマスターイメージを作成する

Google Cloud Cloud Buildツールを使用する

Windows 11 ISO、GCP SDK、.NETフレームワーク、PowerShellインストーラーファイルをGCPストレージバケットにアップロードします。
Cloud Build .yamlファイル内のファイルの場所をパラメーターとして指定します。
最終的なWindows 11イメージを構築するには、コマンドラインから次のCloud Buildを実行します。GCPは、GCPのDaisyワークフローを使用して、選択したプロジェクトでマスターイメージをブートストラップして作成し、マスターイメージをGCPにインポートします。
```
gcloud compute instances import INSTANCE-NAME--source-uri=gs://BUCKET/IMAGE-OVF-FILE.ovf --guest-os-features=UEFI_COMPATIBLE --byol --machine-type=MACHINE-TYPE --zone=ZONE

```
注：

すべての大文字のテキストを実際のリソースの詳細に置き換えます。

詳しくは、「カスタムWindows BYOLイメージを作成する」を参照してください。

他のハイパーバイザー上にマスターイメージを作成する

他のハイパーバイザーを使用してWindows 11マスターイメージを作成します。
マスターイメージをOVF形式でローカルマシンにエクスポートします。
ローカルgcloud CLIを使用して、OVFファイルをGCPストレージバケットにアップロードします。
```
gsutil cp LOCAL_IMAGE_PATH_OVF_FILES gs://BUCKET_NAME/

```
最終的なWindows 11イメージを構築するには、コマンドラインから次のCloud Buildを実行します。GCPは、GCPのDaisyワークフローを使用して、選択したプロジェクトでマスターイメージをブートストラップして作成し、マスターイメージをGCPにインポートします。
```
gcloud compute instances import INSTANCE-NAME --source-uri=gs://BUCKET/IMAGE-OVF-FILE.ovf --guest-os-features=UEFI_COMPATIBLE --byol --machine-type=MACHINE-TYPE --zone=ZONE

```
注：

すべての大文字のテキストを実際のリソースの詳細に置き換えます。

単一テナントノードにVMをプロビジョニングする

単一テナントノードを使用すると、VMを他のプロジェクトのVMから物理的に分離したり、同じホストハードウェア上でVMをグループ化したりできます。単一テナントノードについて詳しくは、GCPドキュメントの「単一手ナンシーの概要」を参照してください。

単一テナントノードでVM（マシンプロファイルソース）をプロビジョニングする方法については、GCPドキュメントの「単一テナントノードにVMをプロビジョニングする」を参照してください。

注：

ノードグループと同じインスタンスの種類とリージョンを選択します。

Shielded VMセクションでvTPMを有効にします。詳しくは、「クイックスタート：Shielded VMオプションを有効にする」を参照してください。

ソースVM上のBitlockerを無効にします。

Windows 11マシンプロファイルソースを使用してMCSマシンカタログを作成する

Web StudioまたはPowerShellコマンドを使用して、MCSマシンカタログを作成し、Windows 11 VMを作成できます。

注：

マスターイメージには、Windows 11スナップショットまたはVMを選択します。

マシンプロファイルソースには、マシンプロファイルとしてWindows 11 VMを選択します。マシンプロファイルソースは、単一テナントノードで説明されているものと同じインスタンスの種類である必要があります。

Web Studioの使用について詳しくは、「Web Studioでのマシンカタログの作成」を参照してください。

PowerShellコマンドについて詳しくは、「マシンプロファイルを使用してマシンカタログを作成する」を参照してください

カタログを作成してVMの電源をオンにすると、Google Cloudコンソールの単一テナントノードで実行されているWindows 11 VMを確認できます。

Google Cloud Marketplace

Google Cloud MarketplaceでCitrix提供イメージを参照して選択することで、マシンカタログを作成できます。現在、MCSはこの機能でマシンプロファイルワークフローのみをサポートします。

Google Cloud MarketplaceでCitrix VDA VM製品を検索するには、https://console.cloud.google.com/marketplaceにアクセスしてください。

カスタムイメージ、またはGoogle Cloud MarketplaceのCitrix Readyイメージを使用して、マシンカタログのイメージを更新できます。

注：

マシンプロファイルにストレージの種類の情報が含まれていない場合、値はカスタムプロパティから取得されます。

サポートされているGoogle Cloud Marketplaceイメージは次のとおりです：

Windows 2019シングルセッション
Windows 2019マルチセッション
Ubuntu

マシンカタログを作成するためのソースとしてCitrix Readyイメージを使用する例：

New-ProvScheme -ProvisioningSchemeName GCPCatalog \
-HostingUnitName GcpHu -IdentityPoolName gcpPool -CleanOnBoot \
-MasterImageVM XDHyp:\HostingUnits\GcpHu\images.folder\citrix-daas-win2019-single-vda-v20220819.publicimage \
-MachineProfile XDHyp:\HostingUnits\GcpHu\Base.vm
<!--NeedCopy-->

次の手順

最初のカタログを作成すると、Web Studioではデリバリーグループを作成する手順が表示されます。
構成プロセス全体を確認するには、「インストールと構成」を参照してください
カタログを管理するには、「マシンカタログの管理」と「Google Cloud Platformカタログの管理」を参照してください。

追加情報

このコンテンツの正式なバージョンは英語で提供されています。Cloud Software Groupドキュメントのコンテンツの一部は、お客様の利便性のみを目的として機械翻訳されています。Cloud Software Groupは機械翻訳されたコンテンツを管理していないため、誤り、不正確な情報、不適切な用語が含まれる場合があります。英語の原文から他言語への翻訳について、精度、信頼性、適合性、正確性、またはお使いのCloud Software Group製品またはサービスと機械翻訳されたコンテンツとの整合性に関する保証、該当するライセンス契約書またはサービス利用規約、あるいはCloud Software Groupとのその他すべての契約に基づき提供される保証、および製品またはサービスのドキュメントとの一致に関する保証は、明示的か黙示的かを問わず、かかるドキュメントの機械翻訳された範囲には適用されないものとします。機械翻訳されたコンテンツの使用に起因する損害または問題について、Cloud Software Groupは責任を負わないものとします。

この情報は役に立ちましたか?

Google Cloud Platformカタログの作成

September 24, 2024

寄稿者:

C C

September 24, 2024

寄稿者:

C C

この記事の概要

マスター仮想マシンインスタンスと永続ディスクを準備する
マシンカタログの作成
手動で作成したGoogle Cloudマシンのインポート
共有仮想プライベートクラウド
ゾーン選択の有効化
顧客管理暗号キー（CMEK）
均一なバケットレベルのアクセスの互換性
PowerShellを使用してマシンカタログを作成する
永続的なライトバックキャッシュディスクのカタログを作成する
MCSIOによる起動パフォーマンスの向上
マシンプロファイルを使用してマシンカタログを作成する
インスタンステンプレートとしてマシンプロファイルを使用してマシンカタログを作成する
PowerShellを使用してシールドされた仮想マシンでカタログを作成する
単一テナントノードにWindows 11 VMを作成する
Google Cloud Marketplace
次の手順
追加情報

この情報は役に立ちましたか?