STACKIT VM Target Sizing and Storage Selection

Purpose

Use this guide to define the initial STACKIT compute and storage profile for VMware workloads that will be relocated as virtual machines. It converts measured demand into an explicit target mapping without copying provisioned vCPU, memory, or datastore capacity one to one.

Initial target sizing protects the migration and cutover. It is not the final optimization decision. Review the profile again after the workload has produced representative telemetry on STACKIT.

Required evidence

Collect measurements over a period that includes normal operation, peak windows, batch processing, backup activity, month-end or seasonal events, and known incidents.

• CPU: Capture consumed CPU, peak and p95 demand, ready or contention time, and sustained load duration. Do not use provisioned vCPU count as the sole input.
• Memory: Capture active and consumed memory, working-set peaks, ballooning, swapping, and cache behavior. Do not assume allocated VMware memory is continuously required.
• Storage capacity: Capture used capacity, growth rate, retention, snapshot, backup, and temporary workspace needs. Do not migrate abandoned snapshots or unused disks without review.
• Storage performance: Capture read and write IOPS, throughput, latency, queue depth, block size, and peak duration per disk. Do not select a class from capacity or average IOPS alone.
• Network: Capture ingress, egress, connection count, burst profile, latency, and packet-loss sensitivity. Include backup and replication traffic.
• Availability: Capture recovery objectives, failure-domain requirements, maintenance tolerance, and restart behavior. Do not treat a larger VM as an availability design.

Document the source, time range, percentile, missing samples, growth assumptions, and confidence for every measurement. Apply a named safety margin where the evidence is incomplete instead of hiding uncertainty in an oversized target.

Select a STACKIT machine type

STACKIT machine types are predefined hardware configurations. Individual vCPU and RAM combinations cannot be assembled beyond the offered variants, so selection is a two-dimensional fit rather than a direct conversion of the VMware configuration.

Understand the type name

From the STACKIT docsMachine types - EU01 › Machine type namesSource updated 24.07.2026 · copied 05.10.2026

Example of a machine type name: c1a.8d

The first part of the name, e.g. “c1a.8d”, is the variant of a machine type. Currently, there are the following variants:

Swipe sideways to see the whole table

Variant	Description
t	Smaller instances with smaller CPU and less RAM
s	Processor-optimized instances with a CPU/RAM-ratio of 1:1
c	Processor-optimized instances with a CPU/RAM-ratio of 1:2
g	General instances with a CPU/RAM-ratio of 1:4
m	Memory-optimized instances with a CPU/RAM-ratio of 1:8
b	Large, memory-optimized instances with CPU/RAM-ratio of 1:16 or higher
n	Instances with NVIDIA GPUs

What is this?

This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.

The generation, processor architecture, available sizes, and exact memory values vary by region and can change over time. Resolve the current catalog in the target region before approving a wave.

Selection method

1. Convert CPU measurements into required target cores for the design load, then add explicit peak, growth, and measurement-confidence headroom.
2. Convert the observed memory working set into required RAM and add headroom for guest overhead, cache behavior, growth, and cutover uncertainty.
3. Identify the machine-type family whose CPU-to-memory ratio wastes the least capacity while meeting both requirements.
4. Select the smallest current type in that family that satisfies CPU and RAM simultaneously; record which dimension determines the size.
5. Decide explicitly between CPU-overprovisioned and d types. Prefer a non-overprovisioned type when sustained CPU demand, latency sensitivity, or observed contention makes predictable CPU access a requirement.
6. Validate processor architecture, operating-system support, licensing, availability-zone placement, quotas, and maintenance behavior.
7. Test the selected type with a representative pilot and preserve the next larger and smaller valid types for rollback and later rightsizing decisions.

Do not infer equivalent performance from vCPU count alone. Processor generation, overprovisioning, guest drivers, workload concurrency, and source contention all influence the observed result.

Select Block Storage

Treat storage capacity, performance, and availability as separate decisions.

Capacity and placement

1. Size each root and data volume from used data, expected growth, file-system needs, snapshots, backup behavior, and temporary migration workspace.
2. Keep disks separate where workload consistency, backup policy, performance isolation, or future growth requires independent control.
3. Choose Single AZ or Metro according to the workload’s failure-domain design. Metro volumes are mirrored across availability zones; this does not remove the need for backups or application-level recovery design.

Performance class

A STACKIT Block Storage performance class defines the maximum IOPS and throughput for the complete volume. The class is independent of volume size, and all consumers of that volume, including VM and backup reads, share its performance envelope.

1. Establish required read and write IOPS, throughput, latency, block-size distribution, and concurrency for each target volume.
2. Add explicit peak, backup, recovery, and growth headroom to IOPS and throughput independently.
3. Select the lowest current performance class that satisfies both limits. A class that passes IOPS but fails throughput, or the reverse, is not sufficient.
4. Validate the choice during replication and isolated test migration, when copy traffic may expose a different bottleneck from normal application operation.
5. Record observed latency, I/O wait, queue depth, IOPS, and throughput after cutover for the Optimize review.

From the STACKIT docsService plans › Currently available Service Plans (performance classes)Source updated 22.04.2026 · copied 05.10.2026

The following table lists currently available performance classes for the EU01 region:

Swipe sideways to see the whole table

Performance class	Name	Max. IOPS	Max. Throughput (MB/s)
Performance class 0	storage_premium_perf0	120	25
Performance class 1	storage_premium_perf1	500	50
Performance class 2	storage_premium_perf2	1000	100
Performance class 4	storage_premium_perf4	2000	150
Performance class 6	storage_premium_perf6	5000	200
Performance class 8	storage_premium_perf8	10000	250
Performance class 10	storage_premium_perf10	15000	300
Performance class 12	storage_premium_perf12	20000	350
Performance class 13	storage_premium_perf13	20000	700
Performance class 14	storage_premium_perf14	25000	400
Performance class 15	storage_premium_perf15	25000	800
Performance class 16	storage_premium_perf16	30000	450
Performance class 17	storage_premium_perf17	30000	900
Performance class 18	storage_premium_perf18	35000	500
Performance class 19	storage_premium_perf19	35000	1000
Performance class 20	storage_premium_perf20	40000	550
Performance class 21	storage_premium_perf21	40000	1100
Performance class 29	storage_premium_perf29	60000	1500

IOPS - Input/Output Operations per second

Throughput - Throughput in Megabytes per second

Thus, the classes used can be distinguished in detail based on the naming. Example: “Block Storage Premium - Performance Class 2” corresponds to SSD hard disks with max. 1000 IOPS and max. 100 Mbyte/s throughput.

What is this?

This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.

The table shows the EU01 catalog. Always resolve the current values for the target region.

Target mapping record

Create one version-controlled mapping row per VM and volume.

• Source VM and workload: Stable inventory identifier and application mapping.
• Target region and placement: Region, availability zone or Metro requirement, and quota result.
• Machine type: Exact type, CPU and RAM requirement, governing dimension, headroom, and overprovisioning decision.
• Root volume: Capacity, performance class, boot assumptions, and recovery assumptions.
• Data volumes: Source-to-target disk mapping, capacity, performance class, and consistency group.
• Network: Target network, addresses, security groups, DNS, and bandwidth expectation.
• Validation thresholds: CPU, memory, latency, IOPS, throughput, application SLO, and observation window.
• Adjustment options: Approved larger and smaller type, storage alternative, change method, and rollback condition.

Approve the mapping only when the target profile, expected cost, quota, tool mapping, and acceptance thresholds are all known. Feed the exact mapping into the Coriolis or Acura test migration rather than choosing target resources during cutover.

Primary references

STACKIT documentation docs.stackit.cloud STACKIT Server machine types Open the documentation STACKIT documentation docs.stackit.cloud STACKIT Block Storage service plans Open the documentation STACKIT documentation docs.stackit.cloud Manage a STACKIT Server Open the documentation