관리 API 서버의 kubeconfig 파일 경로를 사용하여 이 안내의 MANAGEMENT_API_SERVER를 바꿉니다.
권한 및 액세스 요청
이 페이지에 나열된 작업을 수행하려면 프로젝트 VirtualMachine 관리자 역할이 있어야 합니다. 단계를 따라 VM이 있는 프로젝트의 네임스페이스에 프로젝트 VirtualMachine 관리자 (project-vm-admin) 역할이 있는지 확인합니다.
디스크 연결 유지
VM이 시작되면 VM의 노드에서 VM의 디스크로 연결을 시작하는 데 몇 초가 걸립니다. VM이 더 빨리 시작되도록 하려면 VM이 종료될 때 디스크 연결이 유지되어야 합니다. 그래야 후속 VM 시작 시 디스크 연결이 다시 시작되지 않습니다. 이를 위해 디스크 연결 유지 기능을 사용 설정하는 명령어를 실행하면 시스템에서 VM의 모든 디스크를 마운트하는 더미 포드를 자동으로 만듭니다.
디스크 연결 유지 사용 설정
PROJECT 프로젝트에서 VM_NAME라는 VM의 디스크 연결을 유지하려면 다음 명령어를 실행합니다. 이렇게 하면 시스템에서 더미 포드를 자동으로 만듭니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eMinimizing VM start time is a preview feature not recommended for production, and doing so increases resource consumption and the security surface.\u003c/p\u003e\n"],["\u003cp\u003eTo speed up VM start times, enable disk connection keep-alive, which involves running a command that creates a dummy pod to maintain the VM's disk connections.\u003c/p\u003e\n"],["\u003cp\u003eConfigure inter-VM affinity between the VM and the keep-alive pod to increase the likelihood the VM restarts on the same node.\u003c/p\u003e\n"],["\u003cp\u003eFor faster start times, use BIOS firmware instead of UEFI, though this means secure boot will not be supported.\u003c/p\u003e\n"],["\u003cp\u003eUsing a boot disk of 500 GB or greater can help minimize the VM start time.\u003c/p\u003e\n"]]],[],null,["# Minimize the VM start time\n\n| **Preview:** Minimize the VM start time is a Preview feature that is available as-is and is not recommended for production environments. Google provides no Service-Level agreements (SLA) or technical support commitments for Preview features. For more information, see Google Distributed Cloud (GDC) air-gapped [feature stages](/distributed-cloud/hosted/docs/latest/gdch/resources/feature-stages).\n\nIf you require your VMs to boot as quickly as possible, minimize your virtual\nmachine (VM) start time with the instructions on this page. Minimizing the start\ntime comes at the cost of resource efficiency---your project consumes additional\nresources, and has an increased security surface.\n\nBefore you begin\n----------------\n\nTo use `gdcloud` command-line interface (CLI) commands, ensure that you have downloaded, installed,\nand configured the [`gdcloud` CLI](/distributed-cloud/hosted/docs/latest/gdch/resources/gdcloud-overview).\nAll commands for Distributed Cloud use the `gdcloud` or\n`kubectl` CLI, and require an operating system (OS) environment.\n\n### Get the kubeconfig file path\n\nTo run commands against the Management API server, ensure you have the following\nresources:\n\n1. [Sign in and generate](/distributed-cloud/hosted/docs/latest/gdch/application/ao-user/iam/sign-in#cli) the\n kubeconfig file for the Management API server if you don't have one.\n\n2. Use the path to the kubeconfig file of the Management API server to replace\n \u003cvar translate=\"no\"\u003eMANAGEMENT_API_SERVER\u003c/var\u003e in these instructions.\n\n### Request permissions and access\n\nTo perform the tasks listed in this page, you must have the Project\nVirtualMachine Admin role. Follow the steps to\n[verify](/distributed-cloud/hosted/docs/latest/gdch/application/ao-user/vms/preparation#verify-user-access)\nthat you have the Project VirtualMachine Admin (`project-vm-admin`) role in the namespace\nof the project where the VM resides.\n\nKeep disk connections alive\n---------------------------\n\nWhen a VM starts, initiating a connection from the VM's node to the VM's disk\ntakes a few seconds. To make the VM start up faster, the disk connection must be\nkept alive when the VM is shut down so that the disk connection doesn't\nreinitiate on subsequent VM starts. To achieve this, when you [run the command](#enable-keep-alive)\nto enable disk connection keep-alive the system automatically creates a dummy pod\nthat mounts all the VM's disks.\n\n### Enable disk connection keep-alive\n\nTo keep disk connections alive for a VM called \u003cvar translate=\"no\"\u003eVM_NAME\u003c/var\u003e\nin the project \u003cvar translate=\"no\"\u003ePROJECT\u003c/var\u003e, run\nthe following command. When you do, the system automatically creates the dummy\npod: \n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eMANAGEMENT_API_SERVER\u003c/var\u003e patch virtualmachines.virtualmachine.gdc.goog \u003cvar translate=\"no\"\u003eVM_NAME\u003c/var\u003e -n \u003cvar translate=\"no\"\u003ePROJECT\u003c/var\u003e --type merge --patch $'\n metadata:\n annotations:\n disk.virtualmachine.gdc.goog/enable-connection-keep-alive: \"true\"\n '\n\nReplace the variables throughout these instructions, using the following\ndefinitions.\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nWhen the disk connection keep-alive is enabled, a pod named\n`disk-connection-keep-alive-`\u003cvar translate=\"no\"\u003eVM_NAME\u003c/var\u003e is created in the same\nproject as the VM. The next VM restart is faster, as are subsequent start times,\nbecause the VM's disk connections are kept alive by the pod.\n\n### Set up disk connection keep-alive affinity\n\nThe Kubernetes scheduler might select a different node for the VM when it restarts.\nTo reduce the chances of that happening, configure an\ninter-VM affinity rule between the VM and the keep-alive pod. Configure this to happen automatically: \n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eMANAGEMENT_API_SERVER\u003c/var\u003e patch virtualmachines.virtualmachine.gdc.goog \u003cvar translate=\"no\"\u003eVM_NAME\u003c/var\u003e -n \u003cvar translate=\"no\"\u003ePROJECT\u003c/var\u003e --type merge --patch $'\n metadata:\n annotations:\n disk.virtualmachine.gdc.goog/add-connection-keep-alive-affinity: \"true\"\n '\n\nThis adds a preferred-affinity setting on the VM to the keep-alive pod.\n\n### Caveats\n\nThere are two caveats to keeping disk connections alive:\n\n- The keep-alive pod incurs additional resource usage:\n - It counts towards the limit of the number of pods per node.\n - It uses an additional IP address that is assigned by Kubernetes.\n - It uses a negligible additional amount of CPU and memory.\n- The security surface increases, because the node where the keep-alive pod is present always has the VM's disks attached, even when the VM is shut down.\n\nUse BIOS firmware\n-----------------\n\nIn GDC, starting a VM with Unified Extensible\nFirmware Interface (UEFI) firmware is slower than starting a VM with BIOS\nfirmware.\n\n1. To ensure that the start time is minimal, set the VM's firmware type to\n BIOS:\n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eMANAGEMENT_API_SERVER\u003c/var\u003e patch virtualmachines.virtualmachine.gdc.goog \u003cvar translate=\"no\"\u003eVM_NAME\u003c/var\u003e -n \u003cvar translate=\"no\"\u003ePROJECT\u003c/var\u003e --type merge --patch $'\n spec:\n firmware:\n type: bios\n enableSecureBoot:\n '\n\n2. If the VM is running, restart it using the instructions to\n [restart the VM](/distributed-cloud/hosted/docs/latest/gdch/application/ao-user/vms/manage-vms/operations-and-lifecycle/start-and-stop-vm#restart-a-vm).\n\n### Caveats\n\nThe caveat to using BIOS firmware is that it doesn't support [secure boot](/distributed-cloud/hosted/docs/latest/gdch/application/ao-user/vms/manage-vms/secure-vms/secure-boot).\n\nUse a large boot disk\n---------------------\n\nTo minimize the VM start time, attach a boot disk with a size of 500 GB or\ngreater to the VM."]]
