For the complete documentation index, see llms.txt. This page is also available as Markdown.

Create a Confidential VM

Once your image is uploaded, creating a Confidential VM is a standard server-create call with two Confidential VM-specific rules. This topic describes how to create a Confidential VM using the IONOS CLOUD API, understand immutable properties after creation, and learn how restart behavior differs from standard VMs.

Both the mentioned parameters are derived from the image's launch-config.json. After creation, the platform begins a hardware-enforced startup and encrypts VM memory from the start. Key properties, such as cores, ram, cpuFamily, and availabilityZone, are immutable after creation. Restart behaviour also differs from standard VMs: an in-guest restart terminates the VM rather than restarts it. You can use the API to restart it.

Prerequisites:

  • Ensure your Confidential VM image is uploaded.

  • You must have access to the IONOS CLOUD API.

How to create a Confidential VM

1

Create a Confidential VM using the Cloud API

Create an ENTERPRISE-type server with a volume that uses your uploaded Confidential VM image. An image is confidential if SEV-SNP appears in its requiredFeatures, which is set automatically at upload; that is what routes the server to Confidential VM-capable hardware.

POST /cloudapi/v6/datacenters/{datacenterId}/servers
{
  "properties": {
    "name": "my-cc-vm",
    "type": "ENTERPRISE",
    "ram": 8192
  },
  "entities": {
    "volumes": {
      "items": [
        { "properties": { "image": "YOUR_UPLOADED_IMAGE_ID", "size": 20 } }
      ]
    }
  }
}

After creation, cores, ram, cpuFamily, and availabilityZone are immutable, preventing configuration changes after the initial start. You can change the startup volume.

However, you can update these artifacts if your attestation stack supports re-attestation or if you use SNPGuard. For more information, see IONOS CLOUD API documentation.

2

Understand Confidential VM startup behavior

The platform reads the LAUNCH_ARTIFACTS and begins the hardware-enforced startup. Your VM's memory is encrypted by the CPU from the start, with or without attestation. If you configured an attestation service, the initrd contacts it during startup to obtain the disk-unlock key. If you did not, your initrd is responsible for unlocking the root filesystem on its own. For more information about what attestation does and does not cover, see Attest a Confidential VM.

Last updated

Was this helpful?